|
From: Neil A. W. <nei...@un...> - 2014-05-19 20:51:22
|
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. |