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