Alright, quick update on this. At this point, I have servlet context and a username running off the main tomcat http threads (quartz job)
> StandardContext tomcat;////load from reflection from ApplicationContext from > ServletContext as ApplicationContextFacade > Realm realm = tomcat.getRealm() At this point, realm is a LockoutRealm that contains two child realms, the JNDI Realm and the standard UserDatabaseRealm > Principal user = realm.authenticate(username); At this point, the user object is populated and appears to have the roles attached to it (they are listed in the to String method). > realm.hasRole(new StandardWrapper(), user, role); This part returns false, if and only if the ldap membership matches exactly. Mapped roles via servlet/security-role-ref/role-link and role-name do not appear to be effect. I think this may have something to do with the Principal object not having a login context. Normally, this is available via a servlet, but this it is not. I think the root cause might be this line. https://github.com/apache/tomcat/blob/TOMCAT_7_0_42/java/org/apache/catalina/realm/RealmBase.java#L933 Which probably does the translation from the LDAP defined group or role into what the application is expecting. Am I on the right path here? On Sun, Jul 16, 2017 at 6:18 PM, Alex O'Ree <alexo...@apache.org> wrote: > bugger, this time replying with the correct reply address. Not sure > if the previous reply went through. > > Awesome thanks for the pointer. > > For the reflection mechanism. I think i have a working solution, so > long as the tomcat dev's don't change the name of the private context > variables in ApplicationContextFacade and ApplicationContext > > I'll also further investigate the JMX/Mbean method with JNDI as it > will probably be more sustainable in the long run > > On Sun, Jul 16, 2017 at 3:55 PM, Mark Thomas <ma...@apache.org> wrote: >> On 16/07/17 15:31, Alex O'Ree wrote: >>> Thanks for the clarification. To add to my description.... >>> >>> I'm running a task on the users behalf on a background thread with a >>> task scheduler. I need to get the roles when the task is ran in case >>> of a change in role membership between the time the task is scheduled >>> and when it is executed. >> >> Assuming that that thread is started by a web application, a better >> route might be: >> >> ServletContext -> ApplicationContext -> Context -> Realm >> >> but that requires casting to Tomcat specific classes and some reflection >> trickery since Tomcat deliberately tries to stop apps accessing its >> internals. >> >> >>> It looks like the Digester class loads server.xml and creates the >>> realms but it looks like it's almost entirely done with dynamic class >>> loading. I couldn't narrow down the point in code where Realms are >>> created. Perhaps there's a way to get a reference to the realm via >>> some static reference? I went through the code but could not find a >>> solution. I also tried extending the UserDatabaseRealm but was unable >>> to get it to fire up (new instance) due to the lack of the calling >>> infrastructure and requisite calls from higher up in the tomcat code >>> base. >> >> Not any more. It used to be possible the static reference essentially >> prevented multiple Tomcat instances from being embedded in the same >> application (a rare but valid use case) so we removed it. >> >>> Moving on, I was also poking around in JMX and found that the all >>> users are listed (and clear text passwords are available? not sure if >>> this is the case for digested or encrypt file stores). >> >> You have access to the UserDatabase (if configured) via JMX. It isn't >> intended for production use but even it it were, the passwords are not >> considered a security issue. JMX access is the equivalent of root access >> as far as Tomcat is concerned. Whatever is in the tomcat-users.xml file >> (clear text passwords, digested passwords, etc.) is also visible via JMX. >> >> Other Realms expose a lot less via JMX. >> >>> From this >>> approach, i was able to parse the output and eventually found >>> attributes that list all roles a given user account has (success!). >>> What isn't clear is if this approach will work for LDAP (JNDI) >>> connections or kerberos setups, SSO setups, etc. It may also be >>> version specific to tomcat (running 7.0.76 at the moment). I'd >>> appreciate any feedback on this. >> >> It will only work for the UserDatabaseRealm. It will work for any >> currently supported Tomcat version. >> >> JMX may be your best option here. If you search for objects that have >> "type=Realm" you'll be able to enumerate the Realms and hopefully find >> the one you need. >> >> Mark >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org >> For additional commands, e-mail: users-h...@tomcat.apache.org >> --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
