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