[Date Prev][Date Next]
Re: "Roles" in OpenLDAP?
charlie derr wrote:
Nikos Voutsinas wrote:
......then it need only retrieve the user's entry to determine all of
the groups that
contain the user.
Thanks Howard for your answer.
Could you please provide me with more information on how someone could
get all of the groups that contain the user by just retrieving the
user's entry? If this functionality has already been explained
elsewhere, I would be gradefull if you could just point me where i can
find this kind of infomation.
I'm nowhere near as smart as Howard, but I'm going to give this one a
shot. We use a custom schema, two stanzas of which are excerpted here:
# value to be used to pigeonhole user in particular groups
# i.e. faculty, staff, student
attributetype ( 184.108.40.206.4.1.105220.127.116.11
DESC 'Value used to associate this user with different groups'
SUBSTR caseIgnoreSubstringsMatch )
objectclass ( 18.104.22.168.4.1.10522.214.171.124
SUP ( top )
MUST ( uinSR )
MAY ( groupSR $ bldg $ currentCourse $ completedCourse $
uidNumber $ gidNumber $ homeDirectory $ loginShell $
gecos $ description $ shadowLastChange $ shadowMin $
shadowMax $ shadowWarning $ shadowInactive $
shadowExpire $ shadowFlag $ origPassword $ genderSR $
mailSR $ mailAliasSR $ mailMessageStoreSR $ mailQuotaSR $
mailOrigSR $ mailAltSR $ gn $ loginSh0 $ loginSh1) )
Now, every entry that is objectclass personSR (one account per person is
our rule) has a potential groupSR attribute to check for group
membership. We've written web applications (with php) to allow specific
access to various components based on this. However groupSR isn't
mentioned in any slapd ACL (though I suppose it could be if we wanted to
restrict access to the information in LDAP based on groupSR). The
attribute groupSR may be empty or it may have one or more values. This
allows a person to be a member or one group or many or none. I think
it's a specific example of what was being discussed (dynamic groups).
Because we've done this in sort of a "non-standard" fashion (I just made
up this schema a couple years ago), we're considering moving back to a
more "standardized" organizationalRole or memberOf solution. I'd be
interested in the thoughts of people who feel strongly about how groups
should "best" be implemented.
What you have just described is the procedure to get the *roles* of your
users. In my opinion it is a standard method, whenever external
applications need to get a quick answer to the famous question: "In what
groups the user x is member of". This is by far the most common
-membership related- question a service may pose to the ldap server, and
the requirement here is to achieve the best server response time, the
minimum ldap-server overhead and the minimum time the client remains
blocked waiting for the answer. I suppose that we all agree that classic
groups does not meet the previous requirements when the question "In
what groups the user x is member of" comes into play. And this has
nothing to do with being dynamic or not, it has to do with the number of
operations to be performed and the number of groups to be checked.
To extend your thoughts you could even implement *dynamic roles* if you
find a method to store inside or under groupSR entries, ldap
filters/URIs. Those ldap filters combined with the uniSR attribute could
be used to fill groupSR dynamically. Obviously this is a heavy task, but
you can minimize the performance impact and the latency if you use a
cache layer between your application and the ldap server
The point here is: does openldap support *server-side dynamic roles* ?
Not groups but roles! If not, then is there any other method, that may
take advantage of openldap dynamic groups, in order to simplify the
procedure I described in the previous paragraph?
The issue I raised in my initial mail is that even if openldap provides
(or will provide) an operational attribute that is going to be used as
server-side dynamic role, this attribute should not be used by any
external application unless there is a way to define more than one
service specific, server-side dynamic role, (radius-role,
yourapplication-role etc etc), where each xxx-role is related with a
specific set of filters.
Anyway, I suspect that openldap dynamic groups are not what the
community describes as server-side dynamic roles. If that is the case,
most probably it was my mistake to initiate this thread