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