chaos of JAAS with multiple login modules, for example, unbound krb5 login

[Sean Mullan]

On 11/08/2012 09:53 PM, Weijun Wang wrote:
> Hi All
>
> In JAAS where multiple login modules are required, after the login is
> successful, all principals, public and private creds are stuffed inside
> a subject with no order or pairing, and we have no clue to find out
> which creds belongs to which principal.
>
> I'm talking about this because I'm working on 8001104, which is the
> GSS/krb5 part of unbound SASL, and meet a problem.
>
> For example, support I have 2 Krb5LoginModules. In the first one,
> principal is *, and keytab contains keys for A,B. The second one's
> principal is C, and keytab contains keys for C, D, E. Therefore after
> the login, it would allow a JGSS acceptor to act as either A, B or C
> (unless keys dynamically appear in the first keytab later).
>
> After the login, the Subject will contain:
>
>     Principal: KerberosPrincipal(C)
>     KeyTab: KeyTab1 (with A,B), KeyTab2 (with C,D,E)
>
> Now, if a connection to D is coming, I cannot reject it.
>
> Even if I add a KerberosPrincipal(*) there, I don't know it's meant for
> A and B only.
>
> For this particular problem, I'm suggesting we add a new property to the
> KeyTab object that serves as a who-am-i-for so that the KeyTab is
> restricted to be used by someone. With this change, the KeyTab in the
> Subject will be
>
>     KeyTab: KeyTab1 (with A,B for *), KeyTab2 (with C,D,E for C)
>
> Then I'll know A and B are welcomed but not D and E.
>
> This would need two new APIs:
>
> class javax.security.auth.kerberos.KeyTab {
>     public static KeyTab getInstance(KerberosPrincipal princ, File file);
>     public static KeyTab getInstance(KerberosPrincipal princ);
> }
>
> If you think this is OK, I'll file a CCC.
>
> Of course, your opinion and suggestion on the generalized JAAS level are
> more welcomed.

Off-hand it seems fine to me. Wouldn't you also need a new KeyTab method 
to return the KerberosPrincipal?

--Sean