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

Re: Extra output from ldap_search ?

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=*), 

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
		print '<INPUT TYPE=TEXT NAME=attribute_name VALUE=value>
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>
		print value
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).


> 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

Ace Suares' Internet Consultancy
NIEUW ADRES: Postbus 2599, 4800 CN Breda
telefoon: 06-244 33 608
fax en voicemail: 0848-707 705
website: http://www.suares.nl * http://www.qwikzite.nl