You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Alex O'Ree <sp...@gmail.com> on 2017/08/04 20:24:27 UTC
Re: Getting user role membership without context
Rehashing this. "Works" was working with the out of the box
tomcat-users.xml file. When incorporating a JNDI/Ldap setup, I'm not
getting the expected result.
Server.xml setup
Realm
- UserLockOutRealm
-- JDNIRealm
-- UserRoleRealm (paraphrasing here, this is the default xml file thing)
Consider the following ldap setup (MS active directory)
-LdapUserBob, memberOf=GroupAdmins,GroupNotRelevant objectclass=user
-GroupAdmins, objectclass=group
-GroupUsers, objectclass=group
-GroupNotRelevant, objectclass=group
In the war/WEB-INF/web.xml, i have the user constraint setup with
mappings from the ldap groups to application roles.
Everything works as expected when logging in as LdapUserBob. The
mapped roles resolve in this context and the application requires the
mapped role GroupAdmins. LdapUserBob can get in, no one else can
though (expected)
Using my hack job reflection solution and stepping through the code, I
can get a user object from the realm representing LdapUserBob and the
user object has exactly one role attached to it, GroupNotRelevant. I'm
a bit unclear as to why only the non relevant group is added to the
user role. When calling isUserInRole from the servlet context, it's
returning false. I'm assuming there's something wrong with the JNDI
realm configuration but since it works correctly under normal
circumstances and not using the reflection solution, I'm a bit puzzled
and am unsure how to proceed.
On Wed, Jul 19, 2017 at 11:20 AM, Alex O'Ree <sp...@gmail.com> wrote:
> Got it to work! Thanks Mark!
>
> On Wed, Jul 19, 2017 at 10:40 AM, Mark Thomas <ma...@apache.org> wrote:
>> On 19/07/17 15:34, Alex O'Ree wrote:
>>> Context.findChild and findChildren returns an instance of "Container".
>>> It looks like StandardWrapper extends Container, so I should be able
>>> to type cast it. The question is, is it always going to be an instance
>>> of StandardWrapper?
>>
>> For a Context, it should always be an instance of Wrapper so as long as
>> you cast to Wrapper, you should be fine.
>>
>> In a default Tomcat install it will always be StandardWrapper but better
>> to use the interface here since it has the method you need.
>>
>> Mark
>>
>>
>>>
>>> On Tue, Jul 18, 2017 at 6:40 PM, Mark Thomas <ma...@apache.org> wrote:
>>>> On 18/07/17 23:21, Alex O'Ree wrote:
>>>>> Nice, any idea which method I need to call?
>>>>
>>>> You already have the Context so you want
>>>>
>>>> Context.findChildren()
>>>>
>>>> for a list of all the Wrappers (and it is the wrapper object you need) or
>>>>
>>>> Context.findChild(String)
>>>>
>>>> for a specific Wrapper if you know the name. The name should be the name
>>>> used in web.xml to define the Servlet.
>>>>
>>>> Mark
>>>>
>>>>
>>>>>
>>>>> On Jul 18, 2017 3:54 PM, "Mark Thomas" <ma...@apache.org> wrote:
>>>>>
>>>>>> On 18/07/17 17:41, Alex O'Ree wrote:
>>>>>>> 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?
>>>>>>
>>>>>> Yes. If you check auth outside of a Servlet, the role mappings for the
>>>>>> Servlet won't apply. If you know which servlet to use for the role
>>>>>> mappings you can get that from the Context (Wrappers represent Servlets
>>>>>> and are children of the Context).
>>>>>>
>>>>>> Mark
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Getting user role membership without context
Posted by Alex O'Ree <al...@apache.org>.
Mark, spot on! My ldap setup was incorrect, the group/role i was
expecting was in an OU that was not included in the roleSearchBase.
After that was resolved, i'm good to go. Thanks for your help
On Tue, Aug 8, 2017 at 2:44 AM, Mark Thomas <ma...@apache.org> wrote:
> Personally, I'd step through the JNDIRealm with a debugger (I use
> Eclipse) to see exactly what is going on. If you aren't set up for that,
> enabling debug logging for the JNDIRealm should provide some insight but
> it might not answer everything.
>
> Mark
>
>
> On 04/08/17 21:24, Alex O'Ree wrote:
>> Rehashing this. "Works" was working with the out of the box
>> tomcat-users.xml file. When incorporating a JNDI/Ldap setup, I'm not
>> getting the expected result.
>>
>> Server.xml setup
>> Realm
>> - UserLockOutRealm
>> -- JDNIRealm
>> -- UserRoleRealm (paraphrasing here, this is the default xml file thing)
>>
>> Consider the following ldap setup (MS active directory)
>> -LdapUserBob, memberOf=GroupAdmins,GroupNotRelevant objectclass=user
>> -GroupAdmins, objectclass=group
>> -GroupUsers, objectclass=group
>> -GroupNotRelevant, objectclass=group
>>
>> In the war/WEB-INF/web.xml, i have the user constraint setup with
>> mappings from the ldap groups to application roles.
>> Everything works as expected when logging in as LdapUserBob. The
>> mapped roles resolve in this context and the application requires the
>> mapped role GroupAdmins. LdapUserBob can get in, no one else can
>> though (expected)
>>
>> Using my hack job reflection solution and stepping through the code, I
>> can get a user object from the realm representing LdapUserBob and the
>> user object has exactly one role attached to it, GroupNotRelevant. I'm
>> a bit unclear as to why only the non relevant group is added to the
>> user role. When calling isUserInRole from the servlet context, it's
>> returning false. I'm assuming there's something wrong with the JNDI
>> realm configuration but since it works correctly under normal
>> circumstances and not using the reflection solution, I'm a bit puzzled
>> and am unsure how to proceed.
>>
>>
>> On Wed, Jul 19, 2017 at 11:20 AM, Alex O'Ree <sp...@gmail.com> wrote:
>>> Got it to work! Thanks Mark!
>>>
>>> On Wed, Jul 19, 2017 at 10:40 AM, Mark Thomas <ma...@apache.org> wrote:
>>>> On 19/07/17 15:34, Alex O'Ree wrote:
>>>>> Context.findChild and findChildren returns an instance of "Container".
>>>>> It looks like StandardWrapper extends Container, so I should be able
>>>>> to type cast it. The question is, is it always going to be an instance
>>>>> of StandardWrapper?
>>>>
>>>> For a Context, it should always be an instance of Wrapper so as long as
>>>> you cast to Wrapper, you should be fine.
>>>>
>>>> In a default Tomcat install it will always be StandardWrapper but better
>>>> to use the interface here since it has the method you need.
>>>>
>>>> Mark
>>>>
>>>>
>>>>>
>>>>> On Tue, Jul 18, 2017 at 6:40 PM, Mark Thomas <ma...@apache.org> wrote:
>>>>>> On 18/07/17 23:21, Alex O'Ree wrote:
>>>>>>> Nice, any idea which method I need to call?
>>>>>>
>>>>>> You already have the Context so you want
>>>>>>
>>>>>> Context.findChildren()
>>>>>>
>>>>>> for a list of all the Wrappers (and it is the wrapper object you need) or
>>>>>>
>>>>>> Context.findChild(String)
>>>>>>
>>>>>> for a specific Wrapper if you know the name. The name should be the name
>>>>>> used in web.xml to define the Servlet.
>>>>>>
>>>>>> Mark
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> On Jul 18, 2017 3:54 PM, "Mark Thomas" <ma...@apache.org> wrote:
>>>>>>>
>>>>>>>> On 18/07/17 17:41, Alex O'Ree wrote:
>>>>>>>>> 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?
>>>>>>>>
>>>>>>>> Yes. If you check auth outside of a Servlet, the role mappings for the
>>>>>>>> Servlet won't apply. If you know which servlet to use for the role
>>>>>>>> mappings you can get that from the Context (Wrappers represent Servlets
>>>>>>>> and are children of the Context).
>>>>>>>>
>>>>>>>> Mark
>>>>>>>>
>>>>>>>> ---------------------------------------------------------------------
>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>>>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Getting user role membership without context
Posted by Mark Thomas <ma...@apache.org>.
Personally, I'd step through the JNDIRealm with a debugger (I use
Eclipse) to see exactly what is going on. If you aren't set up for that,
enabling debug logging for the JNDIRealm should provide some insight but
it might not answer everything.
Mark
On 04/08/17 21:24, Alex O'Ree wrote:
> Rehashing this. "Works" was working with the out of the box
> tomcat-users.xml file. When incorporating a JNDI/Ldap setup, I'm not
> getting the expected result.
>
> Server.xml setup
> Realm
> - UserLockOutRealm
> -- JDNIRealm
> -- UserRoleRealm (paraphrasing here, this is the default xml file thing)
>
> Consider the following ldap setup (MS active directory)
> -LdapUserBob, memberOf=GroupAdmins,GroupNotRelevant objectclass=user
> -GroupAdmins, objectclass=group
> -GroupUsers, objectclass=group
> -GroupNotRelevant, objectclass=group
>
> In the war/WEB-INF/web.xml, i have the user constraint setup with
> mappings from the ldap groups to application roles.
> Everything works as expected when logging in as LdapUserBob. The
> mapped roles resolve in this context and the application requires the
> mapped role GroupAdmins. LdapUserBob can get in, no one else can
> though (expected)
>
> Using my hack job reflection solution and stepping through the code, I
> can get a user object from the realm representing LdapUserBob and the
> user object has exactly one role attached to it, GroupNotRelevant. I'm
> a bit unclear as to why only the non relevant group is added to the
> user role. When calling isUserInRole from the servlet context, it's
> returning false. I'm assuming there's something wrong with the JNDI
> realm configuration but since it works correctly under normal
> circumstances and not using the reflection solution, I'm a bit puzzled
> and am unsure how to proceed.
>
>
> On Wed, Jul 19, 2017 at 11:20 AM, Alex O'Ree <sp...@gmail.com> wrote:
>> Got it to work! Thanks Mark!
>>
>> On Wed, Jul 19, 2017 at 10:40 AM, Mark Thomas <ma...@apache.org> wrote:
>>> On 19/07/17 15:34, Alex O'Ree wrote:
>>>> Context.findChild and findChildren returns an instance of "Container".
>>>> It looks like StandardWrapper extends Container, so I should be able
>>>> to type cast it. The question is, is it always going to be an instance
>>>> of StandardWrapper?
>>>
>>> For a Context, it should always be an instance of Wrapper so as long as
>>> you cast to Wrapper, you should be fine.
>>>
>>> In a default Tomcat install it will always be StandardWrapper but better
>>> to use the interface here since it has the method you need.
>>>
>>> Mark
>>>
>>>
>>>>
>>>> On Tue, Jul 18, 2017 at 6:40 PM, Mark Thomas <ma...@apache.org> wrote:
>>>>> On 18/07/17 23:21, Alex O'Ree wrote:
>>>>>> Nice, any idea which method I need to call?
>>>>>
>>>>> You already have the Context so you want
>>>>>
>>>>> Context.findChildren()
>>>>>
>>>>> for a list of all the Wrappers (and it is the wrapper object you need) or
>>>>>
>>>>> Context.findChild(String)
>>>>>
>>>>> for a specific Wrapper if you know the name. The name should be the name
>>>>> used in web.xml to define the Servlet.
>>>>>
>>>>> Mark
>>>>>
>>>>>
>>>>>>
>>>>>> On Jul 18, 2017 3:54 PM, "Mark Thomas" <ma...@apache.org> wrote:
>>>>>>
>>>>>>> On 18/07/17 17:41, Alex O'Ree wrote:
>>>>>>>> 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?
>>>>>>>
>>>>>>> Yes. If you check auth outside of a Servlet, the role mappings for the
>>>>>>> Servlet won't apply. If you know which servlet to use for the role
>>>>>>> mappings you can get that from the Context (Wrappers represent Servlets
>>>>>>> and are children of the Context).
>>>>>>>
>>>>>>> Mark
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org