You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by "Mark R. Diggory" <md...@latte.harvard.edu> on 2002/09/07 16:47:41 UTC
Problems getting roles in JNDI Realm
I'm trying to get a realm set up via JNDI to an Openldap server. Here is
my current server.xml config.
<Realm
className="org.apache.catalina.realm.JNDIRealm" debug="99"
connectionURL="ldap://vdc.fas.harvard.edu:389"
userPattern="uid={0},ou=vdcid,ou=hmdc,o=vdc"
roleBase="o=vdc"
roleSubtree="true"
roleName="vdcGroup"
roleSearch="(member={0})"
digest="SHA"
/>
I'm using "vdcGroup" entries to store unique member attributes named
'member'. I can do this search using straight JNDI in a Test Java
Application. But the realm will not return the vdcGroups that jadmin is
a member of. Is there something obvious I am missing?
-Mark
2002-09-07 10:40:51 JNDIRealm[Standalone]: Connecting to URL
ldap://vdc.fas.harvard.edu:389
2002-09-07 10:41:11 JNDIRealm[Standalone]: lookupUser(jadmin)
2002-09-07 10:41:11 JNDIRealm[Standalone]:
dn=uid=jadmin,ou=vdcid,ou=hmdc,o=vdc
2002-09-07 10:41:11 JNDIRealm[Standalone]: validating credentials by
binding as the user
2002-09-07 10:41:11 JNDIRealm[Standalone]: binding as
uid=jadmin,ou=vdcid,ou=hmdc,o=vdc
2002-09-07 10:41:11 JNDIRealm[Standalone]: Username jadmin successfully
authenticated
2002-09-07 10:41:11 JNDIRealm[Standalone]:
getRoles(uid=jadmin,ou=vdcid,ou=hmdc,o=vdc)
2002-09-07 10:41:11 JNDIRealm[Standalone]: Searching role base 'o=vdc'
for attribute 'vdcGroup'
2002-09-07 10:41:11 JNDIRealm[Standalone]: With filter expression
'(member=uid=jadmin,ou=vdcid,ou=hmdc,o=vdc)'
2002-09-07 10:41:11 JNDIRealm[Standalone]: Returning 0 roles
2002-09-07 10:41:12 JNDIRealm[Standalone]: Username jadmin does NOT have
role tomcat
2002-09-07 10:41:12 JNDIRealm[Standalone]: Username jadmin does NOT have
role role1
2002-09-07 10:41:12 JNDIRealm[Standalone]: Username jadmin does NOT have
role administrators
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Problems getting roles in JNDI Realm (This *IS* a problem.)
Posted by "Mark R. Diggory" <md...@latte.harvard.edu>.
John Holman wrote:
> Mark
>
>>>
>>> Looking up roles as the administrator (or anonymously if
>>> connectionName and connectionPassword are not specified) is a
>>> deliberate design decision.
>>>
>>> John.
>>
>>
>>
>> ?? But, if you've already established a connection with the users
>> principle and credentials, why would ever want to convert to a
>> diferent set of principle/credentials to do the role lookup as a
>> *rule*? This seems to be a *configuration* decision. It would be
>> benifical if the interface provided for this option by providing
>> something like a "bind-as-user='true|false'"
>> "query-as-user='true|false'" in the realm configuration.
>
>
>
> One reason for the decision was that users may not have the
> permissions to retrieve their own roles from the directory, at least
> when roles are represented as LDAP group entries. (Such permissions
> would enable a user to retrieve the roles of any other user, which may
> be considered a breach of privacy).
Depends on the ACL model the LDAP server is implementing.
> Another reason was that for efficiency reasons role information held
> as the value of an attribute in the user's entry is retrieved as an
> integral part of searching for that entry (when a user search is
> configured). That search must be carried out when bound as the
> administrator, since we don't yet know the user's dn, and so it seemed
> consistent to use the same credentials when retrieving role
> information held as group entries.
The users dn is know implicitly because you just bound to the ldap
server with it. In our model, users can only see the groups that they
are a member of.
>
>
> If you are worried about privacy you won't want to give users the
> ability to read the roles of others - so binding as the user to retrieve
> group-based role information won't work. And if you are not, just
> allow the roles to be read when bound anonymously. So I can't see it
> would add much (except to the complexity of the program!) to support a
> "query-as-user" option. Though I may be missing something ...
>
> John
I think it depends on the ACL model one is using. We are using a
hierarchical membership model.
We have Public, Researchers, Curators and Admins. Each of which has
progressively more rights than the last.
In our case, the administrators of a particular "subtree" of the LDAP
are decided based on thier being members of an "administrator group"
entry at that particular point in the LDAP server. So an administrator
has rights to alter the contents all members of the administrator group
and any "sub-groups" below the administrator, same goes for curators as
well, they can edit membership into the curators group, researchers
group or public group. Researchers and Public only have read access to
the groups they are a member of. In all cases a user stays logged into
the LDAP using the same principle/credentials that they bound with. The
LDAP servers ACL controlles their rights in the system. (Not the Client
JNDI Context, which could then be breached by rogue clients.)
Users all log in just the same and have thier "views" of the ldap
controlled by the ACL. Our ACL on our LDAP server restricts "Users" to
only see "group entries" of which they are a member of (so users can't
see who is a member of a "higher" group). Only administrators and
curators actually have the rights to edit their group/subgroup entries.
Users in the other groups do have rights to "view" thier
groups/subgroups, they have no view of groups higher than them in the
hierarchy.
In my eye's the JNDI realm *is* just another *LDAP Client* connecting to
the LDAP server. Its the server's job to restrict access appropriately
and not the client's. If the security of the Tomcat server were breached
and the someone was able to pull the administrative credentials from the
server.xml file, that would be bad. In our case we would need to put
them there because we don't allow annonymous lookup of our groups and
the greatest access group would be the administrators.
So the JNDI realm configurablity becomes an issue because I can do the
following.
bindAsUser / lookup roles Anonymously
bindAsUser / lookup roles as Administrator
but I can't do:
bindAsUser / lookup roles as User.
I dont' think its the *clients* job to restrict the way one can
communicate with the *server* in this case. The JNDI library itself
doesn't, why should Tomcat?
In our model, the users (admins,curators,researchers and public) are
responsable for thier credentials and the Tomcat Server is not a point
of security risk. Its just a client they are configuring. It doesn't
store any passwords in the server.xml file
-Mark
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Problems getting roles in JNDI Realm (This *IS* a problem.)
Posted by John Holman <j....@qmul.ac.uk>.
Mark
>>
>> Looking up roles as the administrator (or anonymously if
>> connectionName and connectionPassword are not specified) is a
>> deliberate design decision.
>>
>> John.
>
>
> ?? But, if you've already established a connection with the users
> principle and credentials, why would ever want to convert to a
> diferent set of principle/credentials to do the role lookup as a
> *rule*? This seems to be a *configuration* decision. It would be
> benifical if the interface provided for this option by providing
> something like a "bind-as-user='true|false'"
> "query-as-user='true|false'" in the realm configuration.
One reason for the decision was that users may not have the permissions
to retrieve their own roles from the directory, at least when roles are
represented as LDAP group entries. (Such permissions would enable a user
to retrieve the roles of any other user, which may be considered a
breach of privacy). Another reason was that for efficiency reasons role
information held as the value of an attribute in the user's entry is
retrieved as an integral part of searching for that entry (when a user
search is configured). That search must be carried out when bound as the
administrator, since we don't yet know the user's dn, and so it seemed
consistent to use the same credentials when retrieving role information
held as group entries.
If you are worried about privacy you won't want to give users the
ability to read the roles of others - so binding as the user to retrieve
group-based role information won't work. And if you are not, just allow
the roles to be read when bound anonymously. So I can't see it would add
much (except to the complexity of the program!) to support a
"query-as-user" option. Though I may be missing something ...
John
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
JAASRealm and JDK1.3.1_03
Posted by James Krygowski <ja...@shaws.com>.
Is anyone here able to get JAAS authentication working using the JAASRealm,
Tomcat 4.1.9, and JDK1.3.1_02??
I've been having lots of what look like classpath/classloader issues in
getting the default JAASMemoryLoginModule to work. I've read that the
jaas.jar located in Tomcat's server/lib must be removed due to some issues
regarding the server classloader. This class I've relocated to a different
directory and included on the Tomcat classpath via the setclasspath.bat
file. When I did this I was able to get the LoginModule to load (I can see
this because I'm JPDA stepping through the Tomcat source) but the whole
thing fails when I execute the login on the LoginModule. This is the point
at which the JAAS infrastructure loads the JAASMemoryLoginModule. I assume
that this fails because the classes loaded from the classpath can't "see"
the classes loaded by the system classloader (server/lib). As a fix, I
tried to jar up the relevant classes from the realm package and put them on
the classpath via setclasspath.bat. However, this caused Tomcat to fail to
start.
Any suggestions would be appreciated. Thanks!
jk
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Problems getting roles in JNDI Realm (This *IS* a problem.)
Posted by "Mark R. Diggory" <md...@latte.harvard.edu>.
Thank you for responding John,
John Holman wrote:
> Providing a connectionName and connectionPassword does *not* cause
> JNDIRealm to lookup the password. It will still authenticate by
> binding as the user unless you specify the userPassword configuration
> attribute.
I'm working with documentation for tomcat 4.0.4. It doesn't state any of
this information. I did look at the information in the documentation for
4.1 and it is there. Thank you.
I believe (through experimentation) that the 4.0.4 version of this does
switch over to the "connectionUser/connectionPassword" at least for the
role query, this because when I added them to my connection to a
non-anonymous LDAP server, it started returning the roles without the
presence of the userPassword attribute.
>
> Looking up roles as the administrator (or anonymously if
> connectionName and connectionPassword are not specified) is a
> deliberate design decision.
>
> John.
?? But, if you've already established a connection with the users
principle and credentials, why would ever want to convert to a diferent
set of principle/credentials to do the role lookup as a *rule*? This
seems to be a *configuration* decision. It would be benifical if the
interface provided for this option by providing something like a
"bind-as-user='true|false'" "query-as-user='true|false'" in the realm
configuration.
This is a great Realm interface to JNDI/LDAP. Thanks for writting it.
-Mark
>
>
> Mark R. Diggory wrote:
>
>> Looking over the JNDIRealm Code I notice that in the bindAsUser
>> method that the users principle and credentials are stripped out of
>> the context. It is after this point that the JNDI search request is
>> made to gather the roles from the ldap server. Shouldn't it be
>> *after* the search for the roles that the users principle and
>> credentials is removed from the DirContext?
>
>
>>
>>
>> This would mean that I can never *really* use bindAsUser(...)
>> strategy because I'd always have to provide a connectionUser and
>> connectionPassword to do the role lookup. Not good at all. This means
>> the configuration is impossible because if you provide the
>> connectionName and connectionPassword attributes, then it just looks
>> up the password on authentication instead of binding as the user.
>
>
>
>
>>
>>
>> -M.
>>
>> Mark R. Diggory wrote:
>>
>>> I know my request should work at the LDAP Server through JNDI
>>> because the following does work when I make a request to the LDAP
>>> server. I do get back the groups.
>>>
>>> <%
>>> Hashtable env = new Hashtable();
>>> env.put(DirContext.INITIAL_CONTEXT_FACTORY,"com.sun.jndi.ldap.LdapCtxFactory");
>>>
>>> env.put(DirContext.SECURITY_PRINCIPAL,"uid=jadmin,ou=vdcid,ou=hmdc,o=vdc");
>>>
>>> env.put(DirContext.SECURITY_CREDENTIALS,"******");
>>> env.put(DirContext.PROVIDER_URL,"ldap://vdc.fas.harvard.edu:389");
>>>
>>> DirContext ctx = new InitialDirContext(env);
>>>
>>> SearchControls controls = new SearchControls();
>>> controls.setSearchScope(SearchControls.SUBTREE_SCOPE);
>>> controls.setReturningAttributes(new String[] {"vdcGroup"});
>>>
>>> NamingEnumeration enum =
>>> ctx.search("o=vdc","(member=uid=jadmin,ou=vdcid,ou=hmdc,o=vdc)",controls);
>>>
>>> while(enum.hasMore()){
>>> SearchResult sr = (SearchResult)enum.next();
>>> out.print(sr.getAttributes().get("vdcGroup") + "<BR>");
>>> }
>>> %>
>>>
>>> is returning
>>> vdcGroup: public
>>> vdcGroup: researchers
>>> vdcGroup: curators
>>> vdcGroup: administrators
>>>
>>> -Mark
>>>
>>> Mark R. Diggory wrote:
>>>
>>>> I'm trying to get a realm set up via JNDI to an Openldap server.
>>>> Here is my current server.xml config.
>>>>
>>>> <Realm
>>>> className="org.apache.catalina.realm.JNDIRealm" debug="99"
>>>> connectionURL="ldap://vdc.fas.harvard.edu:389"
>>>> userPattern="uid={0},ou=vdcid,ou=hmdc,o=vdc"
>>>> roleBase="o=vdc"
>>>> roleSubtree="true"
>>>> roleName="vdcGroup"
>>>> roleSearch="(member={0})"
>>>> digest="SHA"
>>>> />
>>>>
>>>> I'm using "vdcGroup" entries to store unique member attributes
>>>> named 'member'. I can do this search using straight JNDI in a Test
>>>> Java Application. But the realm will not return the vdcGroups that
>>>> jadmin is a member of. Is there something obvious I am missing?
>>>>
>>>> -Mark
>>>>
>>>> 2002-09-07 10:40:51 JNDIRealm[Standalone]: Connecting to URL
>>>> ldap://vdc.fas.harvard.edu:389
>>>> 2002-09-07 10:41:11 JNDIRealm[Standalone]: lookupUser(jadmin)
>>>> 2002-09-07 10:41:11 JNDIRealm[Standalone]:
>>>> dn=uid=jadmin,ou=vdcid,ou=hmdc,o=vdc
>>>> 2002-09-07 10:41:11 JNDIRealm[Standalone]: validating credentials
>>>> by binding as the user
>>>> 2002-09-07 10:41:11 JNDIRealm[Standalone]: binding as
>>>> uid=jadmin,ou=vdcid,ou=hmdc,o=vdc
>>>> 2002-09-07 10:41:11 JNDIRealm[Standalone]: Username jadmin
>>>> successfully authenticated
>>>> 2002-09-07 10:41:11 JNDIRealm[Standalone]:
>>>> getRoles(uid=jadmin,ou=vdcid,ou=hmdc,o=vdc)
>>>> 2002-09-07 10:41:11 JNDIRealm[Standalone]: Searching role base
>>>> 'o=vdc' for attribute 'vdcGroup'
>>>> 2002-09-07 10:41:11 JNDIRealm[Standalone]: With filter expression
>>>> '(member=uid=jadmin,ou=vdcid,ou=hmdc,o=vdc)'
>>>> 2002-09-07 10:41:11 JNDIRealm[Standalone]: Returning 0 roles
>>>> 2002-09-07 10:41:12 JNDIRealm[Standalone]: Username jadmin does NOT
>>>> have role tomcat
>>>> 2002-09-07 10:41:12 JNDIRealm[Standalone]: Username jadmin does NOT
>>>> have role role1
>>>> 2002-09-07 10:41:12 JNDIRealm[Standalone]: Username jadmin does NOT
>>>> have role administrators
>>>>
>>>>
>>>> --
>>>> To unsubscribe, e-mail:
>>>> <ma...@jakarta.apache.org>
>>>> For additional commands, e-mail:
>>>> <ma...@jakarta.apache.org>
>>>>
>>>
>>>
>>>
>>>
>>> --
>>> To unsubscribe, e-mail:
>>> <ma...@jakarta.apache.org>
>>> For additional commands, e-mail:
>>> <ma...@jakarta.apache.org>
>>>
>>
>>
>>
>>
>> --
>> To unsubscribe, e-mail:
>> <ma...@jakarta.apache.org>
>> For additional commands, e-mail:
>> <ma...@jakarta.apache.org>
>>
>
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Problems getting roles in JNDI Realm (This *IS* a problem.)
Posted by John Holman <j....@qmul.ac.uk>.
Providing a connectionName and connectionPassword does *not* cause
JNDIRealm to lookup the password. It will still authenticate by binding
as the user unless you specify the userPassword configuration attribute.
Looking up roles as the administrator (or anonymously if connectionName
and connectionPassword are not specified) is a deliberate design decision.
John.
Mark R. Diggory wrote:
> Looking over the JNDIRealm Code I notice that in the bindAsUser method
> that the users principle and credentials are stripped out of the
> context. It is after this point that the JNDI search request is made
> to gather the roles from the ldap server. Shouldn't it be *after* the
> search for the roles that the users principle and credentials is
> removed from the DirContext?
>
>
> This would mean that I can never *really* use bindAsUser(...) strategy
> because I'd always have to provide a connectionUser and
> connectionPassword to do the role lookup. Not good at all. This means
> the configuration is impossible because if you provide the
> connectionName and connectionPassword attributes, then it just looks
> up the password on authentication instead of binding as the user.
>
>
> -M.
>
> Mark R. Diggory wrote:
>
>> I know my request should work at the LDAP Server through JNDI because
>> the following does work when I make a request to the LDAP server. I
>> do get back the groups.
>>
>> <%
>> Hashtable env = new Hashtable();
>> env.put(DirContext.INITIAL_CONTEXT_FACTORY,"com.sun.jndi.ldap.LdapCtxFactory");
>>
>> env.put(DirContext.SECURITY_PRINCIPAL,"uid=jadmin,ou=vdcid,ou=hmdc,o=vdc");
>>
>> env.put(DirContext.SECURITY_CREDENTIALS,"******");
>> env.put(DirContext.PROVIDER_URL,"ldap://vdc.fas.harvard.edu:389");
>>
>> DirContext ctx = new InitialDirContext(env);
>>
>> SearchControls controls = new SearchControls();
>> controls.setSearchScope(SearchControls.SUBTREE_SCOPE);
>> controls.setReturningAttributes(new String[] {"vdcGroup"});
>>
>> NamingEnumeration enum =
>> ctx.search("o=vdc","(member=uid=jadmin,ou=vdcid,ou=hmdc,o=vdc)",controls);
>>
>> while(enum.hasMore()){
>> SearchResult sr = (SearchResult)enum.next();
>> out.print(sr.getAttributes().get("vdcGroup") + "<BR>");
>> }
>> %>
>>
>> is returning
>> vdcGroup: public
>> vdcGroup: researchers
>> vdcGroup: curators
>> vdcGroup: administrators
>>
>> -Mark
>>
>> Mark R. Diggory wrote:
>>
>>> I'm trying to get a realm set up via JNDI to an Openldap server.
>>> Here is my current server.xml config.
>>>
>>> <Realm
>>> className="org.apache.catalina.realm.JNDIRealm" debug="99"
>>> connectionURL="ldap://vdc.fas.harvard.edu:389"
>>> userPattern="uid={0},ou=vdcid,ou=hmdc,o=vdc"
>>> roleBase="o=vdc"
>>> roleSubtree="true"
>>> roleName="vdcGroup"
>>> roleSearch="(member={0})"
>>> digest="SHA"
>>> />
>>>
>>> I'm using "vdcGroup" entries to store unique member attributes named
>>> 'member'. I can do this search using straight JNDI in a Test Java
>>> Application. But the realm will not return the vdcGroups that jadmin
>>> is a member of. Is there something obvious I am missing?
>>>
>>> -Mark
>>>
>>> 2002-09-07 10:40:51 JNDIRealm[Standalone]: Connecting to URL
>>> ldap://vdc.fas.harvard.edu:389
>>> 2002-09-07 10:41:11 JNDIRealm[Standalone]: lookupUser(jadmin)
>>> 2002-09-07 10:41:11 JNDIRealm[Standalone]:
>>> dn=uid=jadmin,ou=vdcid,ou=hmdc,o=vdc
>>> 2002-09-07 10:41:11 JNDIRealm[Standalone]: validating credentials
>>> by binding as the user
>>> 2002-09-07 10:41:11 JNDIRealm[Standalone]: binding as
>>> uid=jadmin,ou=vdcid,ou=hmdc,o=vdc
>>> 2002-09-07 10:41:11 JNDIRealm[Standalone]: Username jadmin
>>> successfully authenticated
>>> 2002-09-07 10:41:11 JNDIRealm[Standalone]:
>>> getRoles(uid=jadmin,ou=vdcid,ou=hmdc,o=vdc)
>>> 2002-09-07 10:41:11 JNDIRealm[Standalone]: Searching role base
>>> 'o=vdc' for attribute 'vdcGroup'
>>> 2002-09-07 10:41:11 JNDIRealm[Standalone]: With filter expression
>>> '(member=uid=jadmin,ou=vdcid,ou=hmdc,o=vdc)'
>>> 2002-09-07 10:41:11 JNDIRealm[Standalone]: Returning 0 roles
>>> 2002-09-07 10:41:12 JNDIRealm[Standalone]: Username jadmin does NOT
>>> have role tomcat
>>> 2002-09-07 10:41:12 JNDIRealm[Standalone]: Username jadmin does NOT
>>> have role role1
>>> 2002-09-07 10:41:12 JNDIRealm[Standalone]: Username jadmin does NOT
>>> have role administrators
>>>
>>>
>>> --
>>> To unsubscribe, e-mail:
>>> <ma...@jakarta.apache.org>
>>> For additional commands, e-mail:
>>> <ma...@jakarta.apache.org>
>>>
>>
>>
>>
>>
>> --
>> To unsubscribe, e-mail:
>> <ma...@jakarta.apache.org>
>> For additional commands, e-mail:
>> <ma...@jakarta.apache.org>
>>
>
>
>
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Problems getting roles in JNDI Realm (This *IS* a problem.)
Posted by "Mark R. Diggory" <md...@latte.harvard.edu>.
Looking over the JNDIRealm Code I notice that in the bindAsUser method
that the users principle and credentials are stripped out of the
context. It is after this point that the JNDI search request is made to
gather the roles from the ldap server. Shouldn't it be *after* the
search for the roles that the users principle and credentials is removed
from the DirContext?
This would mean that I can never *really* use bindAsUser(...) strategy
because I'd always have to provide a connectionUser
and connectionPassword to do the role lookup. Not good at all. This
means the configuration is impossible because if you provide the
connectionName and connectionPassword attributes, then it just looks up
the password on authentication instead of binding as the user.
-M.
Mark R. Diggory wrote:
> I know my request should work at the LDAP Server through JNDI because
> the following does work when I make a request to the LDAP server. I do
> get back the groups.
>
> <%
> Hashtable env = new Hashtable();
> env.put(DirContext.INITIAL_CONTEXT_FACTORY,"com.sun.jndi.ldap.LdapCtxFactory");
>
> env.put(DirContext.SECURITY_PRINCIPAL,"uid=jadmin,ou=vdcid,ou=hmdc,o=vdc");
>
> env.put(DirContext.SECURITY_CREDENTIALS,"******");
> env.put(DirContext.PROVIDER_URL,"ldap://vdc.fas.harvard.edu:389");
>
> DirContext ctx = new InitialDirContext(env);
>
> SearchControls controls = new SearchControls();
> controls.setSearchScope(SearchControls.SUBTREE_SCOPE);
> controls.setReturningAttributes(new String[] {"vdcGroup"});
>
> NamingEnumeration enum =
> ctx.search("o=vdc","(member=uid=jadmin,ou=vdcid,ou=hmdc,o=vdc)",controls);
>
> while(enum.hasMore()){
> SearchResult sr = (SearchResult)enum.next();
> out.print(sr.getAttributes().get("vdcGroup") + "<BR>");
> }
> %>
>
> is returning
> vdcGroup: public
> vdcGroup: researchers
> vdcGroup: curators
> vdcGroup: administrators
>
> -Mark
>
> Mark R. Diggory wrote:
>
>> I'm trying to get a realm set up via JNDI to an Openldap server. Here
>> is my current server.xml config.
>>
>> <Realm
>> className="org.apache.catalina.realm.JNDIRealm" debug="99"
>> connectionURL="ldap://vdc.fas.harvard.edu:389"
>> userPattern="uid={0},ou=vdcid,ou=hmdc,o=vdc"
>> roleBase="o=vdc"
>> roleSubtree="true"
>> roleName="vdcGroup"
>> roleSearch="(member={0})"
>> digest="SHA"
>> />
>>
>> I'm using "vdcGroup" entries to store unique member attributes named
>> 'member'. I can do this search using straight JNDI in a Test Java
>> Application. But the realm will not return the vdcGroups that jadmin
>> is a member of. Is there something obvious I am missing?
>>
>> -Mark
>>
>> 2002-09-07 10:40:51 JNDIRealm[Standalone]: Connecting to URL
>> ldap://vdc.fas.harvard.edu:389
>> 2002-09-07 10:41:11 JNDIRealm[Standalone]: lookupUser(jadmin)
>> 2002-09-07 10:41:11 JNDIRealm[Standalone]:
>> dn=uid=jadmin,ou=vdcid,ou=hmdc,o=vdc
>> 2002-09-07 10:41:11 JNDIRealm[Standalone]: validating credentials
>> by binding as the user
>> 2002-09-07 10:41:11 JNDIRealm[Standalone]: binding as
>> uid=jadmin,ou=vdcid,ou=hmdc,o=vdc
>> 2002-09-07 10:41:11 JNDIRealm[Standalone]: Username jadmin
>> successfully authenticated
>> 2002-09-07 10:41:11 JNDIRealm[Standalone]:
>> getRoles(uid=jadmin,ou=vdcid,ou=hmdc,o=vdc)
>> 2002-09-07 10:41:11 JNDIRealm[Standalone]: Searching role base
>> 'o=vdc' for attribute 'vdcGroup'
>> 2002-09-07 10:41:11 JNDIRealm[Standalone]: With filter expression
>> '(member=uid=jadmin,ou=vdcid,ou=hmdc,o=vdc)'
>> 2002-09-07 10:41:11 JNDIRealm[Standalone]: Returning 0 roles
>> 2002-09-07 10:41:12 JNDIRealm[Standalone]: Username jadmin does NOT
>> have role tomcat
>> 2002-09-07 10:41:12 JNDIRealm[Standalone]: Username jadmin does NOT
>> have role role1
>> 2002-09-07 10:41:12 JNDIRealm[Standalone]: Username jadmin does NOT
>> have role administrators
>>
>>
>> --
>> To unsubscribe, e-mail:
>> <ma...@jakarta.apache.org>
>> For additional commands, e-mail:
>> <ma...@jakarta.apache.org>
>>
>
>
>
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Problems getting roles in JNDI Realm (more info)
Posted by "Mark R. Diggory" <md...@latte.harvard.edu>.
I know my request should work at the LDAP Server through JNDI because
the following does work when I make a request to the LDAP server. I do
get back the groups.
<%
Hashtable env = new Hashtable();
env.put(DirContext.INITIAL_CONTEXT_FACTORY,"com.sun.jndi.ldap.LdapCtxFactory");
env.put(DirContext.SECURITY_PRINCIPAL,"uid=jadmin,ou=vdcid,ou=hmdc,o=vdc");
env.put(DirContext.SECURITY_CREDENTIALS,"******");
env.put(DirContext.PROVIDER_URL,"ldap://vdc.fas.harvard.edu:389");
DirContext ctx = new InitialDirContext(env);
SearchControls controls = new SearchControls();
controls.setSearchScope(SearchControls.SUBTREE_SCOPE);
controls.setReturningAttributes(new String[] {"vdcGroup"});
NamingEnumeration enum =
ctx.search("o=vdc","(member=uid=jadmin,ou=vdcid,ou=hmdc,o=vdc)",controls);
while(enum.hasMore()){
SearchResult sr = (SearchResult)enum.next();
out.print(sr.getAttributes().get("vdcGroup") + "<BR>");
}
%>
is returning
vdcGroup: public
vdcGroup: researchers
vdcGroup: curators
vdcGroup: administrators
-Mark
Mark R. Diggory wrote:
> I'm trying to get a realm set up via JNDI to an Openldap server. Here
> is my current server.xml config.
>
> <Realm
> className="org.apache.catalina.realm.JNDIRealm" debug="99"
> connectionURL="ldap://vdc.fas.harvard.edu:389"
> userPattern="uid={0},ou=vdcid,ou=hmdc,o=vdc"
> roleBase="o=vdc"
> roleSubtree="true"
> roleName="vdcGroup"
> roleSearch="(member={0})"
> digest="SHA"
> />
>
> I'm using "vdcGroup" entries to store unique member attributes named
> 'member'. I can do this search using straight JNDI in a Test Java
> Application. But the realm will not return the vdcGroups that jadmin
> is a member of. Is there something obvious I am missing?
>
> -Mark
>
> 2002-09-07 10:40:51 JNDIRealm[Standalone]: Connecting to URL
> ldap://vdc.fas.harvard.edu:389
> 2002-09-07 10:41:11 JNDIRealm[Standalone]: lookupUser(jadmin)
> 2002-09-07 10:41:11 JNDIRealm[Standalone]:
> dn=uid=jadmin,ou=vdcid,ou=hmdc,o=vdc
> 2002-09-07 10:41:11 JNDIRealm[Standalone]: validating credentials by
> binding as the user
> 2002-09-07 10:41:11 JNDIRealm[Standalone]: binding as
> uid=jadmin,ou=vdcid,ou=hmdc,o=vdc
> 2002-09-07 10:41:11 JNDIRealm[Standalone]: Username jadmin
> successfully authenticated
> 2002-09-07 10:41:11 JNDIRealm[Standalone]:
> getRoles(uid=jadmin,ou=vdcid,ou=hmdc,o=vdc)
> 2002-09-07 10:41:11 JNDIRealm[Standalone]: Searching role base
> 'o=vdc' for attribute 'vdcGroup'
> 2002-09-07 10:41:11 JNDIRealm[Standalone]: With filter expression
> '(member=uid=jadmin,ou=vdcid,ou=hmdc,o=vdc)'
> 2002-09-07 10:41:11 JNDIRealm[Standalone]: Returning 0 roles
> 2002-09-07 10:41:12 JNDIRealm[Standalone]: Username jadmin does NOT
> have role tomcat
> 2002-09-07 10:41:12 JNDIRealm[Standalone]: Username jadmin does NOT
> have role role1
> 2002-09-07 10:41:12 JNDIRealm[Standalone]: Username jadmin does NOT
> have role administrators
>
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>