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