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

Actually there are more kinds of 'groups' in a FDS / Netscape/ Sun LDAP
Directory Server
than just group entries:

1) Treenodes / Entry DN
Every node defines a group of its subnodes and leaves.
If a person entries is under some organisation and organisationunit nodes,
it is member of the organisations and organisationalunits. Membership
can be deduced from the DN of that entry. Search all person in a subtree
are the member of that 'group'

2) Classical static groups
A group entry has a multivalued attributes with references (DNs) of all
members.
Best for the question: who are the members of a group
Worst for the question: to which groups does an entry belong

3) 'Reverse' or 'forward referencing' groups aka NSroles
A person entry has multivalued attribute with references (DNs) to all group
(role) entries
it is member of.
Best for the question: to which groups does an entry belong (the most often
used case!)
Worst for the question: who are the members of a group (if no clever
indexing/caching)

4) Simple 'group' attribute
Some simple entry attribute holds the names of all groups/roles an entry is
member of.
There is no special entry for that group or entry, just membership by name.
'Department'
are something similiar is a candidate for this.

5) Filtered Groups/ Roles
Most flexible membership through arbitrary matching criteria through
LDAP search string (beware of the performance!)

6) Hierarchical groups/roles
Groups or Roles which may contain other groups or roles

So in this broader sense LDAP-Clients/Applications should get smarter and
have
should have a more flexible configuration,
or they should use adapters which abstract the whole LDAP-Server like in
Security-Reams of Java Application Servers where the source for
authorization
and authentication can be exchanged with a database or property file.

Fropm my experience the Apache Jakarta Tomcat 5.5.7 supports NSRoles in its
JNDIRealm out of the box even without mentioning it. It combines the
membership
in LDAP Groups AND LDAP Roles to provide an application with the sum as
Java/Application roles.
I implemented my own custom Realm according to the JAAS standard and
therefore
I'm able even to interpret filtered and hierarchical groups/roles and hide
them
from the application. It is possible to use the declarative Access Control
Instructions
in a java application, which is not possible with standard realms.

But as long as someone has to support some closed source, braindead, legacy
code with an over-simplified LDAP connection I would be against curring
that disease
on the server-side, perpetuing the problem into the future and encouraging
those
implementations even in future developments.

Instead some kind of LDAP-Proxy-Super-Adapter comes to my mind: it would
use and understand all those variations of groups and present them to an
application
as being a classical static group. It would be very configurable in every
aspect.

Otherwise I'm afraid to much of application logic moves into the directory
server like PL/SQL only for LDAP.


Frerk Meyer

EDEKA Aktiengesellschaft
GB Datenverarbeitung
Frerk Meyer
CC Web Technologien
New-York-Ring 6
22297 Hamburg
Tel: [phone] - 3272
Fax: [phone] - 41268
mailto:[e-mail]

[Fedora-directory-users] Ideas for fds [Auf Viren geprüft]

[David Boreham]

Thanks, that was an interesting analysis.

> Instead some kind of LDAP-Proxy-Super-Adapter comes to my mind: it
> would
> use and understand all those variations of groups and present them to an
> application
> as being a classical static group. It would be very configurable in every
> aspect. 
I believe this is what was called the 'policy server'.
Problem is that AFAIK nobody has built a generally useful one.

> Otherwise I'm afraid to much of application logic moves into the
> directory
> server like PL/SQL only for LDAP.
>   
>  
True. There are two (valid) reasons for stored procedures: 1) ensure 
data integrity
2) performance. Both these apply to the LDAP DS scenario too.
So it's a two-sided thing : offload too much to an intermediary LDAP
client and performance will suffer, plus applications that do not use
the intermediary now have the problem of maintaining consistency with it.

The doomsday scenario of a full-blown policy language inside the DS
is certainly scary. All the proposals being discussed here are very simple
by comparison (and sometimes too simple of course).

[Fedora-directory-users] Ideas for fds [Auf Viren geprüft]

[Rich Megginson]

Frerk.Meyer(a)Edeka.de wrote:

> Actually there are more kinds of 'groups' in a FDS / Netscape/
> Sun LDAP
> Directory Server
> than just group entries:
>
> 1) Treenodes / Entry DN
> Every node defines a group of its subnodes and leaves.
> If a person entries is under some organisation and organisationunit nodes,
> it is member of the organisations and organisationalunits. Membership
> can be deduced from the DN of that entry. Search all person in a subtree
> are the member of that 'group'
>   
>  
Right.  But then moving an entry from one group to another becomes 
problematic.  Even if the server supports the modrdn or subtree rename 
operation, it can be a problem for apps that expect the entry DN not to 
change.

> 2) Classical static groups
> A group entry has a multivalued attributes with references (DNs) of all
> members.
> Best for the question: who are the members of a group
>   
>  
Actually, this can be a very expensive operation when you have more than 
several hundred members of a group.  There is no good way in LDAP to 
efficiently retrieve a large number of values for a single attribute.  
We need to solve this problem if we want to use standard static group 
semantics.

> Worst for the question: to which groups does an entry belong
>
> 3) 'Reverse' or 'forward referencing' groups aka NSroles
> A person entry has multivalued attribute with references (DNs) to all group
> (role) entries
> it is member of.
> Best for the question: to which groups does an entry belong (the most often
> used case!)
>   
>  
Is this really the most often used case?  Which applications use this case?

> Worst for the question: who are the members of a group (if no clever
> indexing/caching)
>   
>  
In FDS with Roles this is a simple search (nsRole=<DN of role definition>)

> 4) Simple 'group' attribute
> Some simple entry attribute holds the names of all groups/roles an entry is
> member of.
> There is no special entry for that group or entry, just membership by name.
> 'Department'
> are something similiar is a candidate for this.
>
> 5) Filtered Groups/ Roles
> Most flexible membership through arbitrary matching criteria through
> LDAP search string (beware of the performance!)
>
> 6) Hierarchical groups/roles
> Groups or Roles which may contain other groups or roles
>
> So in this broader sense LDAP-Clients/Applications should get smarter and
> have
> should have a more flexible configuration,
> or they should use adapters which abstract the whole LDAP-Server like in
> Security-Reams of Java Application Servers where the source for
> authorization
> and authentication can be exchanged with a database or property file.
>
> Fropm my experience the Apache Jakarta Tomcat 5.5.7 supports NSRoles in its
> JNDIRealm out of the box even without mentioning it. It combines the
> membership
> in LDAP Groups AND LDAP Roles to provide an application with the sum as
> Java/Application roles.
> I implemented my own custom Realm according to the JAAS standard and
> therefore
> I'm able even to interpret filtered and hierarchical groups/roles and hide
> them
> from the application. It is possible to use the declarative Access Control
> Instructions
> in a java application, which is not possible with standard realms.
>
> But as long as someone has to support some closed source, braindead, legacy
> code with an over-simplified LDAP connection I would be against curring
> that disease
> on the server-side, perpetuing the problem into the future and encouraging
> those
> implementations even in future developments.
>
> Instead some kind of LDAP-Proxy-Super-Adapter comes to my mind: it would
> use and understand all those variations of groups and present them to an
> application
> as being a classical static group. It would be very configurable in every
> aspect.
>
> Otherwise I'm afraid to much of application logic moves into the directory
> server like PL/SQL only for LDAP.
>
>
> Frerk Meyer
>
> EDEKA Aktiengesellschaft
> GB Datenverarbeitung
> Frerk Meyer
> CC Web Technologien
> New-York-Ring 6
> 22297 Hamburg
> Tel: [phone] - 3272
> Fax: [phone] - 41268
> mailto:[e-mail]
>
>
>
> --
> Fedora-directory-users mailing list
> Fedora-directory-users(a)redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-directory-users
>   
>

[Fedora-directory-users] Ideas for fds [Auf Viren geprüft]

[Jeff Clowser]

Rich Megginson wrote:

>  Frerk.Meyer(a)Edeka.de wrote:
>
> > Actually there are more kinds of 'groups' in a FDS / Netscape/ Sun LDAP
> > Directory Server
> > than just group entries:
> >
> > 1) Treenodes / Entry DN
> > Every node defines a group of its subnodes and leaves.
> > If a person entries is under some organisation and organisationunit 
> > nodes,
> > it is member of the organisations and organisationalunits. Membership
> > can be deduced from the DN of that entry. Search all person in a subtree
> > are the member of that 'group'
> >  
> >
>  Right.  But then moving an entry from one group to another becomes 
>  problematic.  Even if the server supports the modrdn or subtree rename 
>  operation, it can be a problem for apps that expect the entry DN not 
>  to change. 
And applications that depend on a particular tree structure or the 
format of the dn are a nightmare, because if you are trying to integrate 
2 of them in the same directory, they probably won't match up.  I prefer 
to allow entries to be more or less anywhere in the tree (grouping by 
some common criteria like "all users", "all groups", "all
resources for 
a customer", etc, and sort them out by objectclass or attribute values - 
i.e. this grouping is appropriate for administering your directory and 
keeping it organized, but is not necessarily a good way to organize 
things for application logic.  Example: if you have an 'engineering' 
group that is defined as all users under ou=engineering,ou=people,o=isp, 
and apps depend on a users position in the tree do access control, 
email, etc to the "engineering" group, that's just bad, because 1) 
people can't be in both the engineering group and marketing group at the 
same time, and 2) moving a user from one "group" to another can be 
really painful (esp if they are part of a lot of static 
groupofuniquename groups, populated in "owner" and "manager" dn based

attributes, etc throughout the directory).

I've never considered this a "group" per se, but I think I understand 
your point - Sun's messaging server, for example, defines an entry that 
defines an email domain.  All users and mail lists for that domain are 
"grouped" under that domain entry, and the server only honors email 
addresses in that domain if they are under that domain entry, without 
caring _where_ under that domain entry they are.

I think this is a pretty good model, I've just never thought of it as a 
group :)

> > 2) Classical static groups
> > A group entry has a multivalued attributes with references (DNs) of all
> > members.
> > Best for the question: who are the members of a group
>
>  Actually, this can be a very expensive operation when you have more 
>  than several hundred members of a group.  There is no good way in LDAP 
>  to efficiently retrieve a large number of values for a single 
>  attribute.  We need to solve this problem if we want to use standard 
>  static group semantics. 
It's definately shown that this does not scale well in all cases, but 
it's the most easy to understand, and is the most "obvious" form of group.

> > Best for the question: to which groups does an entry belong (the most 
> > often
> > used case!)
>
>  Is this really the most often used case?  Which applications use this 
>  case? 
I'd say any app that uses groups for authentication, where you have 
different "groups" of users that have different roles - i.e. can I 
access this web page?  Can I use this feature?  What part of the 
directory can I write to?  However a group is defined, a group is often 
used to determine access.  I would have to agree that this is probably 
the most used in my experience as well.  Something like an email list 
will want to read a group and do something all the members, but I'd say 
I more often am asking am I part of group/privilege x?

> > Worst for the question: who are the members of a group (if no clever
> > indexing/caching)
> >  
>
>  In FDS with Roles this is a simple search (nsRole=<DN of role 
>  definition>) 
I would agree that this is the more reasonable approach for a lot of 
cases, but I also have to say that the problem lies in apps that exist 
that you have no control over, that know the static group/uniquemember 
method of lookup only.  We can't claim that this is old, obsolete ways 
of doing groups, because there really is no alternative that is 
defined/implemented across all ldap servers and widely accepted like 
groupofuniquenames is.

Unless you are selling an ldap server implementation, people don't tend 
to write LDAP apps to a specific implementation, so 
groupofuniquenames/uniquemember is the most "universal" way to do a 
"group".  (OK, grouping by common values in some attribute is just as 
universal, but I don't think most people formally consider this as a 
"group" so much as a way to do this that doesn't involve groups, if that 
makes sense.  Well, maybe netscape's groulOfURL's _is_ a formal way of 
doing this, but is not widely accepted.)

> > Some simple entry attribute holds the names of all groups/roles
> an 
> > entry is
> > member of.
> > There is no special entry for that group or entry, just membership by 
> > name.
> > 'Department'
> > are something similiar is a candidate for this.
>
>  4) Simple 'group' attribute 
Again, something I never really considered a "group" - at least not from 
an application level perspective, though technically speaking I guess it 
is (kinda like saying all guys named joe make up a group) :).  I would 
say also that nsroles (as well as "memberof") is just a refinement of 
this form of group, in which the attribute can be populated dynamically, 
and/or does reference some other entry someplace.

I've always been kinda leary of this type of group because of the 
challenge of properly securing it.  Consider the following:

1.  I don't want a user to be able to administer their own roles - easy 
enough to restrict if I'm careful setting up my aci's.
2.  I want an admin in engineering to be able to define members of the 
engineering group.  I want an admin in HR to define members of an HR 
group.  Assuming nsRoles, I now have 2 groups that need to edit the same 
attribute, but I won't want engineering to be able to make the user a 
member of the hr group, and vice versa.  This is easy to set up with 
traditional static groups, but gets complicated with nsRoles, and 
doesn't scale well to a large # of groups.
3.  You have to be sure you don't define groups around an attribute that 
the user can edit themselves, unless that is ok for your uses (i.e. for 
mail lists, it might be ok, but for admin groups, it probably is not).

> > 5) Filtered Groups/ Roles
> > Most flexible membership through arbitrary matching criteria through
> > LDAP search string (beware of the performance!)
>  
I think this is where this all started, with me asking for a dynamic way 
to populate uniquemember :)

> > 6) Hierarchical groups/roles
> > Groups or Roles which may contain other groups or roles
> >
> > But as long as someone has to support some closed source, braindead, 
> > legacy
> > code with an over-simplified LDAP connection I would be against curring
> > that disease
> > on the server-side, perpetuing the problem into the future and 
> > encouraging
> > those
> > implementations even in future developments.
>  
The problem with this is that we don't always get to choose the
"best" 
application based on it's ldap integration.  Business decisions are 
based on broader criteria than that :)  So, we get stuck with some of 
these periodically.

To solve this, we need to get wide spread acceptance for a different way 
of doing groups, such that they can be/are implemented in any LDAP 
server (dynamically populating them can be a feature of a particular 
server, but the _definition_ - aka schema - of the list should not be).  
You have to change the mindset on how people define groups in ldap.  
FWIW, nsroles _could_ fit that bill - there is nothing saying we can't 
define and manually populate the attributes to mimic nsroles in any ldap 
server, it's more that vendors haven't written apps to work that way. 

Consider how to implement the following (examples I've used through this 
thread):
1.  Mailing lists.  If the mail server that supports this allows you to 
configure message size limits, header/footers, moderators, etc for each 
group, you can't (and don't want to) store this as attributes in each 
users entry.
2.  VPN Templates - each template defines host access lists, times, etc, 
and a user can be a member of multiple templates to define a merged view 
of their access.

You could populate nsrole with the dn of an entry that is both an nsrole 
and a mail list or vpn template, which contains things like the mail 
list's sizelimits, headers/footers, etc or a vpn templates host list, 
access times, etc.  You could also do this as a separate attribute for 
each app (i.e. memberofLists in the users entry containing the dn or 
email address of the list's they belong to, and memberOfVPNtemplates 
that contains a list of dn's or vpn template id's to let the app find 
the vpn template entries a user is a member of).  You don't want to use 
CoS to put those values in a users entry, because you'd mix and merge 
list or vpn template info inappropriately.

Keep in mind also the amount of work to change something - i.e. what if 
the email address of a group changes, do you want to have to update 100k 
users?

 - Jeff

[Fedora-directory-users] Ideas for fds [Auf Viren geprüft]

[Pete Rowley]

>  -----Original Message-----
>  From: fedora-directory-users-bounces(a)redhat.com 
>  [mailto:[e-mail]] On Behalf 
>  Of jclowser(a)unitedmessaging.com
>  Sent: Monday, June 13, 2005 10:36 AM
>  To: General discussion list for the Fedora Directory server project.
>  Subject: Re: [Fedora-directory-users] Ideas for fds [Auf 
>  Viren geprüft]
>  
>  Rich Megginson wrote:
>  
>  > Frerk.Meyer(a)Edeka.de wrote:
>  >
>  >> Actually there are more kinds of 'groups' in a FDS / Netscape/ Sun 
>  >> LDAP Directory Server than just group entries:
>  >>
>  >> 1) Treenodes / Entry DN
>  >> Every node defines a group of its subnodes and leaves.
>  >> If a person entries is under some organisation and 
>  organisationunit 
>  >> nodes, it is member of the organisations and organisationalunits. 
>  >> Membership can be deduced from the DN of that entry. Search all 
>  >> person in a subtree are the member of that 'group'
>  >>  
>  >>
>  > Right.  But then moving an entry from one group to another becomes 
>  > problematic.  Even if the server supports the modrdn or 
>  subtree rename 
>  > operation, it can be a problem for apps that expect the 
>  entry DN not 
>  > to change.
>  
>  And applications that depend on a particular tree structure 
>  or the format of the dn are a nightmare, because if you are 
>  trying to integrate
>  2 of them in the same directory, they probably won't match 
>  up.  I prefer to allow entries to be more or less anywhere in  
They are indeed a nightmare - and this scenario is one of the targets for
the FDS virtual views feature - if you can't change the apps, change the dit
on the fly...