[security-dev 00377]: Re: JGSS/krb5: Too strict Krb5LoginModule options validation

Max (Weijun) Wang Weijun.Wang at Sun.COM
Mon Oct 27 22:13:38 PDT 2008

Hi Valerie

Sun JDK's impl is different (see inline vs IBM). For options in  
Krb5LoginModule, I think there're 3 rules:

1. No conflict. e.g. only use ccache but storeKey, obviously there's  
no key to store here
2. Useful. e.g. if useKeyTab=false, then keyTabName is useless so it  
shouldn't appear
3. Not impossible. there should be at least one way to get the  

Except for these, it seems every combination is OK. The options'  
meanings are already described quite clearly. We still need to  
document the preferred order:

    1. ccache
    2. keytab
    3. shared state
    4. prompt

Note that if any step is selected but fails, the next step will be  
tried. There's only one exception, it #3 fails and useFirstPass=true,  
#4 will not be tried.

Another thing needs to be mentioned is how to choose the username, the  
preferences order is:

     1. principal=XXX option
     2. name in ccache (if chosen)
     3. the name in shared state
     4. the name from callback

I'm writing codes to double check them, will add into Krb5LoginModule  


On Oct 28, 2008, at 8:15 AM, Valerie Peng wrote:

> You have "useTicketPass" instead of "useFirstPass" in the sample code.
> I noticed that IBM has additional description in their javadoc on  
> this, i.e.
> ===========
> 4) The keytab and ccache options take precedence over tryFirstPass.
>   If a keytab or ccache option is set in addition to tryFirstPass,
>   the keytab or ccache is used and the principal saved in the shared  
> state

only if storePass is true

>   if login is succesful. There will be no prompting for password if
>   the login fails.

prompting for password will be executed unless doNotPrompt=true &&  

> 5) The keytab and ccache options are incompatible with the
>   useFirstPass option; specifying useFirstPass in conjunction with
>   either a keytab or ccache option will cause an exception to be  
> thrown.

No, they can co-exist, shared state will be used when neither of the  
other 2 methods succeed.

> ===========
> Is this how our impl behave if either useFirstPass or tryFirstPass  
> is specified along with ccache or keytab?
> I think we need to think through all different combination of  
> options and document the behavior with this change.
> Thanks,
> Valerie
> On 10/21/08 20:08, Weijun Wang wrote:
>> Hi All
>> Currently we have this check inside Krb5LoginModule:
>>    private void validateConfiguration() throws LoginException {
>>        if (doNotPrompt && !useTicketCache && !useKeyTab)
>>            throw new LoginException
>>                ("Configuration Error"
>>                 + " - either doNotPrompt should be "
>>                 + " false or useTicketCache/useKeyTab "
>>                 + " should be true");
>>        .....
>> However, if the user has also provided tryFirstPass=true or
>> useFirstPass=true, it's possible to get the password from a shared
>> state. The restriction in the check is not necessary then. It can be
>> changed to:
>>        if (doNotPrompt && !useTicketCache && !useKeyTab &&
>>                !tryFirstPass && !useTicketPass)
>>            throw new LoginException
>>                ("Configuration Error"
>>                 + " - either doNotPrompt should be "
>>                 + " false or at least one of useTicketCache, "
>>                 + " useKeyTab, tryFirstPass and useTicketPass"
>>                 + " should be true");
>> I'll file a bug and fix it if you find it OK.
>> Thanks
>> Max

More information about the security-dev mailing list