checking group membership during while binding

[Michael Perelman <mi...@hotmail.com>]

While using Apache LDAP java APIs, is there a way to check for group membership during the binding process? Or is the only way to determine group membership is by doing a regular lookup, and only after binding? The latter approach may not work because the authenticated user may not have the access rights to perform any lookups, thereby forcing the use of an LDAP administrator. That means that its credentials need to be stored somewhere outside the LDAP server in order for the client code to use its account for the aforementioned lookup. What approach would you suggest?
 		 	   		  

RE: checking group membership during while binding

[Michael Perelman <mi...@hotmail.com>]

correct, right after user authentication i need to check which groups that user is a member of. if a user has access to its own attributes, would checking its "member" attribute do the trick?

> Date: Thu, 19 Mar 2015 07:29:20 +0100
> From: elecharny@gmail.com
> To: users@directory.apache.org
> Subject: Re: checking group membership during while binding
> 
> Le 19/03/15 00:50, Michael Perelman a écrit :
> > While using Apache LDAP java APIs, is there a way to check for group membership during the binding process? Or is the only way to determine group membership is by doing a regular lookup, and only after binding? The latter approach may not work because the authenticated user may not have the access rights to perform any lookups, thereby forcing the use of an LDAP administrator. That means that its credentials need to be stored somewhere outside the LDAP server in order for the client code to use its account for the aforementioned lookup. What approach would you suggest?
> >  		 	   		  
> I'm not sure what you want to do here. What is your "check for group
> membership" in LDPA terms ?
> 
> If you mean you want to look at the content of the 'member' attribute,
> then yes, a lookuo is the way. If you don't want to do that regularly,
> then using the persistentSearch contrl might be an option : you will be
> informed of any change done on this attribute.
> 
> Obviously, you will depend on yoru LDAP server settings to have access
> to this attribute. If your server does not allow operations to be done
> without any binding (yes, you can do a search without doing any bind,
> this is allowed by the protocol, but most generally forbidden by some
> server configuration), then depending on the authorization, you might
> also have to pick the right user to complete such a lookup.
> 
> All in all, it's really a server configuration problem...
> 
 		 	   		  

Re: checking group membership during while binding

[Emmanuel Lécharny <el...@gmail.com>]

Le 19/03/15 00:50, Michael Perelman a écrit :
> While using Apache LDAP java APIs, is there a way to check for group membership during the binding process? Or is the only way to determine group membership is by doing a regular lookup, and only after binding? The latter approach may not work because the authenticated user may not have the access rights to perform any lookups, thereby forcing the use of an LDAP administrator. That means that its credentials need to be stored somewhere outside the LDAP server in order for the client code to use its account for the aforementioned lookup. What approach would you suggest?
>  		 	   		  
I'm not sure what you want to do here. What is your "check for group
membership" in LDPA terms ?

If you mean you want to look at the content of the 'member' attribute,
then yes, a lookuo is the way. If you don't want to do that regularly,
then using the persistentSearch contrl might be an option : you will be
informed of any change done on this attribute.

Obviously, you will depend on yoru LDAP server settings to have access
to this attribute. If your server does not allow operations to be done
without any binding (yes, you can do a search without doing any bind,
this is allowed by the protocol, but most generally forbidden by some
server configuration), then depending on the authorization, you might
also have to pick the right user to complete such a lookup.

All in all, it's really a server configuration problem...