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

Reply via email to