Frerk.Meyer@xxxxxxxx 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
--
Fedora-directory-users mailing list
Fedora-directory-users@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-directory-users
