|Summary:||JNDIRealm.getPrincipal(context,username,gssCredential) corrupts realm context|
|Product:||Tomcat 7||Reporter:||Richard Begg <richard.begg>|
|Component:||Catalina||Assignee:||Tomcat Developers Mailing List <dev>|
|Attachments:||Patch to restore context params|
Description Richard Begg 2013-08-05 02:53:29 UTC
The getPrincipal(context,username,gssCredential) method in JNDIRealm is designed to allow delegated credentials to be applied to the directory server connection as part of SPNEGO authentication. This is done by manipulation of a number of the directory context's environment parameters. However, as currently implemented, these environment parameters are forcibly cleared after the getUser() call regardless of whether the values were even changed (i.e. if isUseDelegatedCredential() returned false). If the container realm is defined to use GSSAPI authentication, only the first SPNEGO authentication request will succeed. All subsequent requests will fail with this exception: javax.naming.NamingException: [LDAP: error code 1 - 000004DC: LdapErr: DSID-0C0906DC, comment: In order to perform this operation a successful bind must be completed on the connection., data 0, v1db0 The exception is due to the Context.SECURITY_AUTHENTICATION being cleared by getPrincipal() - resulting in a attempted "simple" bind with no username/password (i.e. anonymous). A workaround is to ensure that the connectionName and connectionPassword parameters are specified in the realm definition - however, if one is using GSSAPI - this shouldn't be necessary and certainly defeats the purpose of using GSSAPI in the first place. The code should preserve pre-existing environment parameters in the context before changing them, then restore those values afterwards - rather than just clearing the settings completely.
Comment 1 Richard Begg 2013-08-05 03:48:51 UTC
Created attachment 30671 [details] Patch to restore context params Here is a proposed patch for JNDIRealm.java which resolves the issue for me.
Comment 2 Violeta Georgieva 2013-08-16 06:00:23 UTC
Thanks for the report and the patch. Fixed in trunk and 7.0.x and will be included in 7.0.43 onwards.