directory-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Perelman <mikhail_perel...@hotmail.com>
Subject RE: checking group membership during while binding
Date Mon, 23 Mar 2015 07:40:55 GMT
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...
> 
 		 	   		  
Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message