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

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.

Nikos Voutsinas



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 ( 1.3.6.1.4.1.10536.2.1.2
        NAME 'groupSR'
        DESC 'Value used to associate this user with different groups'
        SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
        EQUALITY caseIgnoreMatch
        SUBSTR caseIgnoreSubstringsMatch )

#


objectclass ( 1.3.6.1.4.1.10536.2.1.3
        NAME 'personSR'
        SUP ( top )
        AUXILIARY
        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.

<of topic>
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
<of topic>

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

Nikos Voutsinas