[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: Extra output from ldap_search ?

Hi,

another idea: 
Define a private objectclass with a multi-valued attribute aceWriteAttrs
and add this objectclass to your users' objects.
Then fill the attribute with the names of the attributes that the user is 
allowed to write .
Now a small extension of the search and a bit program logic lets you do 
the right thing.

Maintaining this attribute is another story. But it might be automated using a 
script that parses slapd.conf and fills the values accordingly.

Peter

On Tuesday 21 October 2003 22:11, Ace Suares wrote:
> Thanks John and Peter for your help.
>
> However, it's possibly not entirely clear what I try to say.
>
> Lets' break this down:
>
> A. I got openldap 2.1.22, a whole bunch of ACL's that protect the entries
> in the directory depending on which user is bound (i.e. I don't use
> application-level authentication).
>
> B. my webinterface is in PHP/Apache, but that doesn't really matter now.
> I'll write pseudo code ;-)
>
> C. when userA logs in, I am doing
>
> entry = ldapsearch (connection, userA-DN, baseDN, (objectclass=*),
> all-attributes).
>
> This results in retrieving exactly 1 (one) entry, namely that of the user
> itself (in this exampel case).
>
> The attributes retrieved are only those userA has write access to OR read
> access to. All other attributes are hidden for userA, i.e. they will NOT be
> part of the search result. (That's how ldap_search works, isn't it ;-)
>
> Let's say the entry contains the following attributes:
> objectclass: mailuser
> cn: User A. Doe
> mail: usera@domain.com
> homedir: /maildir/domain.com/usera
> userpassword: abcdefgh
>
> Now, the ACL's that I use, give write access to 'cn' and 'userpassword'.
> They give also read access to 'mail' and 'homedir'. These are just
> examples, so don't come saying 'why don't you hide attibuteXYZ because
> there is no use in reading it while you can't write to it'. For the sake of
> the case, just assume it's usefull for userA to read some attributes that
> he or she can't write to ;-)
>
> Now my webinterface does something generic:
>
> for each attribute as (attribute_name,value)
> 	print 'attribute_name'
> 	print '<INPUT TYPE=TEXT NAME=attribute_name VALUE=value>
> end for
>
> This results in printing out a small HTML form with the attribute names
> followed by an input field that the user can change, but already has the
> value of the attribute in it. That would be a quite common part of any
> webinterface that reads records from a database and let's the user modify
> stuff ;-)
>
> However, the attributes 'mail' and 'homedir' are in fact immutable (for
> userA). It would be nicer to NOT have input controls for those attributes.
>
> Of course, I can do such:
>
> read_only_array = ('mail','homedir')
> for each attribute as (attribute_name, value)
> 	print 'attribute_name'
> 	if ( attribute_name in read_only_array)
> 		print value
> 	else
> 		print '<INPUT TYPE=TEXT NAME=attribute_name VALUE=value>
> 	endif
> end for
>
> But that leaves me with 'hardcoding' the 'forbidden' values in the
> application, which of course will be painfull when adding attributes to the
> schema or object. Not to speak that 'userA' is just one type of user on my
> system - I got an adminA, a superadminA, a serverA and so on. They would
> all need different lists of hardcoded forbidden attributes in their
> application and well, I'd like to make things generic ;-)
>
> So, if instead of attributes and values, ldap_search would also output the
> access level (rwscx, althoug for now r and w are imprtant), I could
> generically write:
>
> for each attribute as (attribute_name, value, access)
> 	print 'attribute_name'
> 	if ( access = 'w' )
> 		print '<INPUT TYPE=TEXT NAME=attribute_name VALUE=value>
> 	else
> 		print value
> 	endif
> end for
>
> Of course this would also greatly help when later inserting modified info
> into the directory - no use to try modifying attributes that have no
> 'access=w'.
>
> I hope I have made my point more clear, and that someone either has a
> generic solution for it or that some changes can be made in the way
> ldap_search works. Another solution would be the introduction of
> 'ldap_access' function, that determines the access level for a given DN
> and/or attributes (I posted a similar question earlier).
>
> Greetings,
> ace
>
> > Hi,
> >
> > On Tuesday 21 October 2003 18:51, Ace Suares wrote:
> > > this is hardly the solution I am looking for.
> > > I am not using ACI's at the moment and I don't see the need, really.
> > > Your solution might work but... well. Not elegant.
> > >
> > > I am sure you have webinterfaces to your directory. How do you make
> > > sure that you display 'the right thing' to users? Is it hardcoded in
> > > your app ?
> >
> > What do you exactly mean with "The Right Thing" (TM) ?
> > That clients can only read attributes they are allowed to read, write
> > only those they are allowed to write, .... ?
> >
> > This is not hard-coded in our clients but hard coded in our directory.
> > The directory enforces security, not the client.
> >
> > For a customer we have an application that checks in-directory ACIs
> > because there it was the only possible solution [Web-Application
> > with client certificates, access to the directory [Novell eDirectory]
> > using a special application account, directory rights depending on
> > group memberships of the user authenticating with his certificate.).
> > Unfortunately Novell eDirectory does not support proxy authentication
> > ;-((
> >
> > If your users login to the web app using username+password simply
> > use these credentials to bindto the directory server.
> > Now, the user can do what he/she is allowed to do and nothing more.
> > (of course proxy authentication is also possible)
> >
> > Peter

-- 
Peter Marschall
eMail: peter@adpm.de