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: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
