https://bz.apache.org/bugzilla/show_bug.cgi?id=59839

            Bug ID: 59839
           Summary: roleSearchAsUser not applied to nested roles when
                    roleNested enabled
           Product: Tomcat 7
           Version: 7.0.68
          Hardware: All
                OS: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Catalina
          Assignee: dev@tomcat.apache.org
          Reporter: t...@twmacinta.com

When using a JNDIRealm to search for a user's roles recursively via the
'roleNested' option while also binding using that user's credentials via the
'roleSearchAsUser' option, only the first role search actually binds using the
user's credentials.  Subsequent searches of the nested roles revert to the
original security environment, which leads to a NamingException reporting that
a successful bind must be completed first (see below).

The cause is straightforward, from looking at the code.  I will refer to the
code for 7.0.68, as that is what I've tested against, but I also see the same
issue in the code for 7.0.70 and 8.5.3.  In "JNDIRealm.java" and the method
getRoles() (starting on line 1938), there are two calls to context.search(). 
The first call on line 2002 is wrapped in logic which adds the user's
credentials beforehand and removes them afterward, if 'roleSearchAsUser' was
specified.  The second call on line 2056 is not wrapped in the same logic, but
I'm guessing it should be.  This second call is only reached if 'roleNested' is
true, per the if-block starting on line 2039.

The net result is that when anonymous binding is not allowed, the first search
succeeds (assuming the user entered the correct credentials) and then the
second one fails with a stack trace like the following.  I've redacted the
company name and info:

javax.naming.NamingException: [LDAP: error code 1 - 000004DC: LdapErr:
DSID-0C0906E8, comment: In order to perform this operation a successful bind
must be completed on the connection., data 0, v1db1

-- 
You are receiving this mail because:
You are the assignee for the bug.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Reply via email to