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

LDAP groups and LDAP roles: pro LDAP roles, but call them forward groups
and use them

The naming is a misfortune: nsrole = netscape roles
First because they have their proprietary origin in the name.
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.

In SQL/RDBMS only newbies make the mistake to try to represent
a 1:n relation by storing all primary keys of B in a record of A.
SQL records are not multivalued so this mistake does not happen
that much. Everone learned to do it the other way around.

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.

OpenLDAP has no roles because it implements the standard.
Netscape/Sun/FDS implement roles but nobody uses it because
it is not the standard.
But in MS-ADS - as I learned here - there is an attribute in every entry
representing group memberships. So they set their own standard,
as usual.
If the OSS community doesn''t start to use the roles feature, soon
we will have to adhere to the MS standard and use ADS.

Frerk Meyer

EDEKA Aktiengesellschaft
GB Datenverarbeitung
Frerk Meyer
CC Web Technologien
New-York-Ring 6
22297 Hamburg
Tel: 040/6377 - 3272
Fax: 040/6377 - 41268
mailto:frerk.meyer@edeka.de

Frerk.Meyer@Edeka.de wrote:
> If the OSS community doesn''t start to use the roles feature, soon
> we will have to adhere to the MS standard and use ADS.
I think that roles support should probably be coded into pam_ldap. 
Anybody here active on the pam_ldap list?

--
mike

Frerk.Meyer@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

This all sounds great.

I began to write a roles RFC way back in the day, but
stopped when our work went in a different direction.

That effort could be resurrected.
> 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).
There''s a lot of work to implement this stuff and to make it work
efficiently (and to ensure that it''s well tested, documented and
supported).
I don''t see any value to RH in restricting what is included in a
standard.

> -----Original Message-----
> From: fedora-directory-users-bounces@redhat.com 
> [mailto:fedora-directory-users-bounces@redhat.com] On Behalf 
> Of Frerk.Meyer@Edeka.de
> Sent: Tuesday, June 14, 2005 1:11 AM
> To: General discussion list for the Fedora Directory server project.
> Subject: Re: [Fedora-directory-users] Ideas for fds - roles / 
> forward groups[Auf Viren geprüft]
> 
> 
> The naming is a misfortune: nsrole = netscape roles First 
> because they have their proprietary origin in the name.
This is not an unusual thing for a proprietary attribute type.  We used ns*
_because_ it namespaces the attribute and differentiates from standard
attributes.  Were roles to ever get a draft written I am sure the type name
would be changed to ldaprole or some such.
> 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.
They are a little more than a grouping mechanism, role based attributes
provide for much greater power than a mere group.  And actually, for LDAP,
they _do_ perform the function of roles, allowing for authorization in the
directory and property inheritance.  Applications could choose to use these
roles to perform their authorization functionality too via directory access
control.
> Static LDAP roles do it like in every RDBMS, so it''s right 
> but non standard. I should become standard IMHO.
I agree.  Probably the largest impediment to that happening before now were
patent applications filed for the technology.