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

Reply via email to