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

[Weijun Wang]

A new getPrincipal() method is add. Here is the CCC:

    http://ccc.us.oracle.com/8001104

Please review it.

There is one style I am not sure of. Now it shows

     /*
      * ...
      * @throws NullPointerException if the {@code file} argument is null
      * @throws IllegalArgumentException if {@code princ} is null
      */
     public static KeyTab getInstance(KerberosPrincipal princ, File file);

So it throws different exceptions when either of the arguments is null. 
I don't want to change the old NPE for file, but it seems IAE is the 
correct behavior for this "optional" argument when there are overloaded 
methods.

Thanks
Max


On 11/13/2012 02:50 AM, Sean Mullan wrote:
> 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
>