Re: [ldap-sdk-discuss] GSSAPI

[Alon Bar-L. <alo...@gm...>]

On Mon, May 19, 2014 at 11:51 PM, Neil A. Wilson
<nei...@un...> wrote:
>
> On 05/18/2014 06:46 AM, Alon Bar-Lev wrote:
>>>>
>>>
>>> It is possible to leverage an existing authentication session through the use of a ticket cache.  I've tested this and verifies that it works on both Solaris and Linux.
>>
>>
>> So a custom jaas configuration must be provided, I will do that and
>> use (1) per profile, and declare several profiles with different
>> attributes.
>>
>> Thank you so much for the support!
>
>
> It shouldn't be necessary to use a custom JAAS configuration file in order to use a ticket cache -- the GSSAPIBindRequestProperties class allows you to control whether use of a ticket cache should be required or allowed.  In my testing involving use of an existing session, I didn't have to create a custom configuration file.  You do have to specify the user principal, but the cached ticket will be used instead of obtaining a new one.
>

This because you create the temporary sasl file if have no system
property set, which is what I need to avoid, as I need to run under
jboss for example and keep the current jaas support which is implicit
via classloader and not system properties.

>> Another issue:
>>
>> While reading the code, GSSAPIBindRequest I saw these:
>>
>>      System.setProperty(PROPERTY_CONFIG_FILE, configFilePath);
>>      System.setProperty(PROPERTY_SUBJECT_CREDS_ONLY, "true");
>>
>> There is no way to override these. If no system property is specified
>> then it creates its own temp file and sets the system property to use
>> the temp file. This conflicts with the way jboss is working[1] and may
>> be other application servers, virtually effecting the entire
>> application server without any way to override, and ignoring the their
>> settings.
>>
>> There should be a way to leave the jaas settings alone without setting
>> anything at jre level.
>>
>> This is true also for the DEFAULT_KDC_ADDRESS, PROPERTY_REALM,
>> removing the property if it was null at static context does not mean
>> that the web application did not set them during initialization,
>> although these can be easily overridden using the
>> GSSAPIBindRequestProperties, I think there should be a mode to not
>> change system state at all.
>>
>> What do you think?
>
>
> It is extremely unfortunate that the Java Kerberos support requires setting system properties.  This is an obviously bad design that has the potential for causing a lot of problems.  It's especially befuddling that they chose this approach when the SaslClient already takes a property map, and allowing these properties to be set there instead of as system properties would have solved all of these problems. Fortunately, it's pretty unusual to need multiple different Kerberos authentication sessions, especially concurrently, so for most practical purposes, many clients aren't horribly affected by this.
>

I fully agree, this was a bad design decisions... not the only ones in Java.

> Another unfortunate side effect of using system properties for settings is that you can't easily unset them.  So if you need a specific set of properties for one authentication, you can't easily revert to the former settings unless you keep track of what they were before and then set them back to that when you're done.
>
> At present, it seems like the biggest potential limitation is that there is no way to customize the use of the javax.security.auth.useSubjectCredsOnly property.  To address that, I've added a new set of methods to GSSAPIBindRequestProperties that allow you to customize its behavior rather than always using a hard-coded value of true.

I would like to avoid setting it completely, something like a variable:

   do.no.touch.my.system.state.I.know.what.I.am.doing = true

This should apply to any system state sdk may modify, at least:
- java.security.auth.login.config
- javax.security.auth.useSubjectCredsOnly
- java.security.krb5.kdc
- java.security.krb5.realm

As I wrote above, the java.security.auth.login.config is the very
important not to touch so jaas configuration will be taken from
container context, running GSSAPI within sdk virtually damage the
entire jboss security settings.

> If you're concerned about using the LDAP SDK's support for GSSAPI authentication could interfere with something else in the same JVM trying to interact with the same properties, then you're probably out of luck in terms of having a completely safe solution unless you can find some way to ensure that there is no way that these properties can't be used simultaneously by different threads in the same JVM.  However, it might be good enough for the common case if you were to simply get the values of the affected properties ahead of time, then make whatever changes are necessary for the operation you want to perform, and then immediately change the values back to what they were before.
>

Correct, and this is why I would like that the sdk will support of not
touching the system state, this can be optional setting, but is
important in cases that the sdk is used in "hostile" environment.

An option to instruct to skip system setting is sufficient and will be
fully forward/backward compatible.

Thanks!
Alon