[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: Extra output from ldap_search ?
> Hi,
>
> another idea:
Brilliant ;-)
But if I need to maintain stuff manually, I'd just as well do it inside the
application. I have an array now that couples read/write, input type (text,
textarea, password, select), single/multi, and even a function to modify
output.
It looks like this:
$attributes_attributes["objectclass"]["access"] = "read";
$attributes_attributes["objectclass"]["value_type"] = "multi";
$attributes_attributes["objectclass"]["type"] = "nodisplay";
$attributes_attributes["objectclass"]["function"] = "void";
$attributes_attributes["cn"]["access"] = "write";
$attributes_attributes["cn"]["value_type"] = "multi";
$attributes_attributes["cn"]["type"] = "text";
$attributes_attributes["cn"]["function"] = "void";
$attributes_attributes["uid"]["access"] = "write";
$attributes_attributes["uid"]["value_type"] = "single";
$attributes_attributes["uid"]["type"] = "text";
$attributes_attributes["uid"]["function"] = "void";
$attributes_attributes["qstatus"]["access"] = "write";
$attributes_attributes["qstatus"]["value_type"] = "single";
$attributes_attributes["qstatus"]["type"] = "dropdown{enabled,disabled}";
$attributes_attributes["qstatus"]["function"] = "translate";
$attributes_attributes["userpassword"]["access"] = "write";
$attributes_attributes["userpassword"]["value_type"] = "single";
$attributes_attributes["userpassword"]["type"] = "password";
$attributes_attributes["userpassword"]["function"] = "void";
$attributes_attributes["creatorsname"]["access"] = "read";
$attributes_attributes["creatorsname"]["value_type"] = "single";
$attributes_attributes["creatorsname"]["type"] = "text";
$attributes_attributes["creatorsname"]["function"] = "lookup_cn";
$attributes_attributes["createtimestamp"]["access"] = "read";
$attributes_attributes["createtimestamp"]["value_type"] = "single";
$attributes_attributes["createtimestamp"]["type"] = "text";
$attributes_attributes["createtimestamp"]["function"] =
"timestamp_to_locale";
The function lookup_cn goes back and retrieves the cn from the dn (i.e.
creatorsname, modifiersname); the other functions do similar things (i.e.
converting the timestamp to local time, or translate 'enabled,disabled' into
the appropriate language. The 'dropdown' type includes a list of possible
values {enable,disable} to put in a SELECT FORM-element.
Yes, I could put all this info in a ldap tree (and I might) but it is a hassle
(much less though than rewriting the whole interface logic all the time)
but... the ldap_access function would really simplify life. As for the other
attributes, some of them are in the schema definition (Single/multi for
instance), but some other.... well, I *could* put them in the DESC field of
an objectclass or attribute definition. Grossly abusing the schema files and
totally dependent on my own schema's (I'd have to subclass 'uid' to something
of my own to deal with a controlled 'DESC' field).
I think the best way is making an ITS out of ldap_access, as a feature
request?
Cheers,
ace
> 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
--
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