Re: [ldap-sdk-discuss] GSSAPI

[Neil A. W. <nei...@un...>]

On 05/18/2014 06:46 AM, Alon Bar-Lev wrote:
>>> 2. There is no way to use system already authenticated GSSAPI, the
>>> implementation always uses the LoginContext overriding system
>>> credentials with credentials provided within the
>>> GSSAPIBindRequest/Properties. I am not sure that there is a workaround
>>> using current implementation.
>>>
>>> Please consider to support system credentials in case of GSSAPI as
>>> this is what kerberos mostly about. I believe it is basically it means
>>> to drop the LoginContext and the Subject.doAs(), calling the run
>>> directly if password is null or other property is set.
>>
>>
>> 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.



> 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.

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.

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.