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

Weijun Wang weijun.wang at oracle.com
Fri Nov 9 02:53:54 UTC 2012


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.

Thanks
Max



More information about the security-dev mailing list