Re: [Fedora-directory-users] Ideas for fds - roles / forward groups [Auf Viren geprüft]

[jclowser at unitedmessaging.com]

Frerk.Meyer at Edeka.de wrote:

>The naming is a misfortune: nsrole = netscape roles
>First because they have their proprietary origin in the name.
>  
>
Agreed.  To be fair, there's a lot of history to this name/naming 
convention.

>Second because most applications use LDAP groups to determine
>application roles, and LDAP roles are just another kind of group
>definition but no roles at all. They became roles by interpreting them
>in an application for authorization.
>  
>
OK, I'll agree with that. :)

>But in LDAP this mistake is the standard for groups. And people
>adhere to it because it is the 'STANDARD'.
>Static LDAP roles do it like in every RDBMS, so it's right but
>non standard. I should become standard IMHO.
>  
>
And I think this is the answer - making it standard/portable, and 
pushing it as a "better" way to define groups.  When it was Netscape, 
there was reason to make it "proprietary" in that it was a 
differentiating feature to make it sell.  Now, as an Open Source 
project, there is reason to make this "a standard".  But, the question 
then becomes how to do this. A couple ideas:

1.  Someone write this up as an RFC and standard track it.  (I assume 
this has not already been done?)  If it's defined as an rfc, and other 
ldap servers pick it up (presumably openldap would if it were standards 
track(?)), it will catch on.
2.  Figure out how and document how to replace static groups with roles 
in commonly used apps - i.e. show how a group would be used in apache, 
and how to use roles instead, etc.

I agree that people resist using nsroles because of this lack of 
portability/standardization.  Might also be just that people don't 
understand or have a hard time grasping how roles work, and maybe the 
lack of portability/standardization makes them feel it's not worth it?  
Just guessing here.  Showing how to use it for some real world solutions 
would probably help a lot.

>OpenLDAP has no roles because it implements the standard.
>Netscape/Sun/FDS implement roles but nobody uses it because
>it is not the standard.
>
Agreed, see above.  How difficult would it be to rename nsrole to 
something like role, or roleGroup or something?  I imagine that is a lot 
of work, and we'd ideally want to support both the new and old name for 
backward compatibility...

Netscape Roles does dynamically what you can more or less do statically 
in any ldap server - create an attribute that points to another entry, 
indicating membership in the "group" that entry defines.  There is more 
to it than that, but that's probably all that is needed to "standardize" 
this mind set/way of doing things.  With CoS, FDS can dynamically use 
that to populate attributes in a users entry, further defining a "group" 
of users by a common attribute value - again, something done dynamically 
that any ldap server can do statically (i.e. I can group people by 
setting their deparment to engineering).

My view of what would have to be in an rfc for this is something like this:

1.  Defining the new way to do groups via "roles".
2.  First define the format of the "role" entry - at the minimum, it's 
just an entry with an objectclass of nsrole and a name/rdn attribute.
3.  Then define how you make an entry a member of a role group, by 
putting the DN of the role group in the users entry.
4. Then define examples of usage.  For example:
    a.  Auth groups - define how an app would use a role to see if a 
user had a particular role, compared to static
         groups - i.e. in static groups, typically search for the users 
uid to get their entry, from which you get their DN
        with which you attempt to bind.  Then search for 
(&(objectclass=groupofuniquenames)(uniquemember=<usersdn>))
        to see if a user is a member of the group.
       With roles, you search for the users entry, then attempt to 
bind.  After binding, you look at the role attribute of the
       user entry you already retrieved to see what roles the belong to, 
rather than yet another search.
    b.  Mailing lists - maybe we define a mailing list objectclass that 
is an extension of a role, or just give it as an
       example.  In this case, the role entry would be extended to keep 
an email address for the list, and maybe
       other restrictions for the list.  When email comes in to that 
address, it finds that list entry by searching for
       the email address, checks the message against the restrictions, 
and if it passes, looks for all users with a role
       that matches the dn of the role.  Mail lists would actually be 
more complex - they would probably use
       uniquemember, nsroles, and something like rfc822mailmember (for 
members not in your directory) - I
       would see the nsrole replacing groupOfURL's type groups (for 
those familiar with the Netscape/Sun
       JES messaging server).

Maybe something other than mail lists would be a better example, but 
it's what comes to mind because I deal with 'em every day.

All the dynamic magic, usage with CoS, etc can still be a 
differentiating benefit of FDS (unless Red Hat wants that to be part of 
the standard).

 - Jeff