Fedora directory users - Jun 2005 - Ideas for fds

One of those things I always had a love/hate relationship with in the 
Netscape/Sun directory server was dynamic lists.

Loved ''em because you could create email lists and aci groups that were
self maintaining based on ldap filter criteria.

Hated ''em because no third party app''s knew how to use them -
most apps
see groups as groupofmembers or groupofuniquemembers with a list of
dn''s
in member/uniquemember.

It would be nice to have a dynamic group like Netscape''s groupOfUrls 
(i.e. an ldap url defines members), but have the members returned to 
clients as uniquemembers of the group.  In this way, you could create 
dynamic groups that are much more useful.

For example, if I created:

cn: hr users
objectclass: top
objectclass: groupofuniquenames
objectclass; groupofurls
memberurl: ldap:///<basedn>??sub?(department=hr)
...

and did a search to retrieve it, the people that match the memberurl 
would be returned dynamically as uniquemember values.

Issues I see with this:
1.  Server load - if I have a lot of these groups and do a search that 
returns all groupofurl entries, it could take a lot of resources to 
generate that dynamically.
2.  Assuming this is inherited from groupofuniquenames, what happens if 
I add static members to uniquemember?  I would say return the merged 
list.  How do we know if a value is static or dynamic, to do things like 
removing a static member?  We don''t, but this is similar to the issues 
using class of service where attributes are dynamically added. 
(Actually, would it be possible to implement this using class of 
service?  Hmmm...)

 - Jeff

jclowser@unitedmessaging.com wrote:
> One of those things I always had a love/hate relationship with in the 
> Netscape/Sun directory server was dynamic lists.
>
> Loved ''em because you could create email lists and aci groups that
> were self maintaining based on ldap filter criteria.
>
> Hated ''em because no third party app''s knew how to use
them - most
> apps see groups as groupofmembers or groupofuniquemembers with a list 
> of dn''s in member/uniquemember.
>
> It would be nice to have a dynamic group like Netscape''s
groupOfUrls
> (i.e. an ldap url defines members), but have the members returned to 
> clients as uniquemembers of the group.  In this way, you could create 
> dynamic groups that are much more useful.
>
> For example, if I created:
>
> cn: hr users
> objectclass: top
> objectclass: groupofuniquenames
> objectclass; groupofurls
> memberurl: ldap:///<basedn>??sub?(department=hr)
> ...
>
> and did a search to retrieve it, the people that match the memberurl 
> would be returned dynamically as uniquemember values.
>
> Issues I see with this:
> 1.  Server load - if I have a lot of these groups and do a search that 
> returns all groupofurl entries, it could take a lot of resources to 
> generate that dynamically.
> 2.  Assuming this is inherited from groupofuniquenames, what happens 
> if I add static members to uniquemember?  I would say return the 
> merged list.  How do we know if a value is static or dynamic, to do 
> things like removing a static member?  We don''t, but this is
similar
> to the issues using class of service where attributes are dynamically 
> added. (Actually, would it be possible to implement this using class 
> of service?  Hmmm...) 
I think that you''ve (re)-invented ''filtered roles''.

They''ve been supported in the server since 1999 or so.

Your second point above I believe is covered by nested roles.

Roles (deliberately) don''t use the same schema as static groups,
so the same problem you mentioned that apps don''t support them
applies still. They use the ''nsRole'' attribute.

> I think that you''ve (re)-invented ''filtered
roles''.
>
> They''ve been supported in the server since 1999 or so.
>
> Your second point above I believe is covered by nested roles.
>
> Roles (deliberately) don''t use the same schema as static groups,
> so the same problem you mentioned that apps don''t support them
> applies still. They use the ''nsRole'' attribute.

Yeah - but my point was that I want something that _does_ work with 
existing apps that know nothing about the Netscape/Sun extensions like 
nsRoles and memberURL - i.e. that could look up a "standard" 
groupofuniquenames groups and see things in the uniquemember attribute, 
without having to look at something else (i.e. nsRole).  That has always 
been the problem with using these extensions.  So what I am asking for 
_is_ different than the filtered roles, I think.  :)

 - Jeff

> Yeah - but my point was that I want something that _does_ work with 
> existing apps that know nothing about the Netscape/Sun extensions like 
> nsRoles and memberURL - i.e. that could look up a "standard" 
> groupofuniquenames groups and see things in the uniquemember 
> attribute, without having to look at something else (i.e. nsRole).  
> That has always been the problem with using these extensions.  So what 
> I am asking for _is_ different than the filtered roles, I think.  :)
This idea was considered when roles were developed and rejected at the time.
Reason was that we didn''t want to interfere with the existing behavior 
of static groups
in any way. Another reason was that we didn''t have high confidence in 
the whole
static group concept : generating a single entry with a potentially vast 
number of
attribute values can cause problems for clients. Microsoft attempted to 
solve this
problem with the paged results control, I believe. Therefore roles 
attempted to
steer applications in a different direction : the application reads the 
target entry
and by examining attributes of that entry it can determine group membership
(or entitlement to perform some operation, however the grouping semantics
are to be interpreted within the application). This approach seemed to 
be more
efficient from both a server and a client perspective.

However, I don''t think it would be too hard to leverage the roles code
to make the kind of ''view group'' feature that you want.
Performance might
not be great for large groups and the issue with clients reading huge 
group entries
is still present.

I should also say that the roles feature was born at a time
when the product was marketed for very large scale deployments.
We had seen for example the mail server users attempt to create
groups with millions of entries. That just didn''t work at all well.

That was then and this is now: the target market is somewhat
different. For the typical F500 company with a few thousand employees,
virtual view static groups are probably just fine.

Netscape roles are great, but the reason I don''t prefer them (and 
dynamic groups) is that it is very implementation specific - i.e. 
netscape/sun/fedora directory server (I''m considering them all more or 
less the same) is the only server that implements it.  If I depend on 
it, I''m tied to a particular implementation of ldap server, and
can''t go
to openldap, active directory, joes directory, etc (not that I''d want
to
- esp ad, but for the sake of the whole standards argument, it''s 
important to consider and I''d want that option). 

If I have a dynamic group that returns members in uniquemember, I could 
always switch, without changing my apps, with the caveat that the groups 
may have to be managed statically.  I suppose you could say the same 
about nsroles, but that further assumes an app allows you to define the 
search filter.  I actually used a static method very similar to nsroles 
before nsroles existed (i.e. create an entry in ldap, then create an 
attribute in the users entry that contains the DN of that entry, and use 
that to determine what roles a user is part of, solely by looking at the 
users entry.  Nice ''cause you could config referential integrity to 
clean it up and all if you delete the role, too).  But I ran into the 
same problem - only the apps I wrote knew how to use it (but at least it 
worked in any ldap server :) ).  At least it didn''t have the resource 
limit issues that groupofurls has.

Anyway,  the issue of large groups does exist for me, so it is a concern 
- A customer of 100k-1 million or more is not out of the question.  It 
would have to be used with care.   But, in the case of smaller 
deployments, or even smaller or "select" groups, it would be useful to
have this for cases where I can''t make apps use the Netscape 
extensions.  In a lot of cases, the _app_ doesn''t need to deal with a 
large list of returned values - i.e. if I do a search for 
(&(cn=MyGroupName)(objectclass=groupofuniquenames)(uniquemember=<someUserDN>)),
returning say,  only the cn attribute or discarding everything but a 
found/not found result to see solely if I''m a member, I would want it
to
work.  Some apps use this to determine group membership, and can''t be 
changed...  This is actually the more likely scenario than wanting to 
use/display the entire list.

Haven''t really thought this through, but would it be possible to use a 
combination of roles and cos to create a group the way I am suggesting?  
I would think even if possible, it would be complicated and probably 
pretty inefficient, but is an option.  If I remember correctly, you 
can''t search on dynamic attributes generated by Cos, though (actually,
I
think in the most recent version of the Sun DS, you could search on 
them, but they are treated as unindexed searches)...  This would likely 
factory into the members dynamically returned as uniquemember idea as 
well, so one more inefficiency in implementing my idea :-D

 - Jeff



David Boreham wrote:
> I should also say that the roles feature was born at a time
> when the product was marketed for very large scale deployments.
> We had seen for example the mail server users attempt to create
> groups with millions of entries. That just didn''t work at all
well.
>
> That was then and this is now: the target market is somewhat
> different. For the typical F500 company with a few thousand employees,
> virtual view static groups are probably just fine.
>
>
> -- 
> Fedora-directory-users mailing list
> Fedora-directory-users@redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-directory-users

jclowser@unitedmessaging.com wrote:
> Netscape roles are great, but the reason I don''t prefer them (and 
> dynamic groups) is that it is very implementation specific - i.e. 
> netscape/sun/fedora directory server (I''m considering them all
more or
> less the same) is the only server that implements it.  If I depend on 
> it, I''m tied to a particular implementation of ldap server, and
can''t
> go to openldap, active directory, joes directory, etc (not that
I''d
> want to - esp ad, but for the sake of the whole standards argument, 
> it''s important to consider and I''d want that option).
> If I have a dynamic group that returns members in uniquemember, I 
> could always switch, without changing my apps, with the caveat that 
> the groups may have to be managed statically.  I suppose you could say 
> the same about nsroles, but that further assumes an app allows you to 
> define the search filter.  I actually used a static method very 
> similar to nsroles before nsroles existed (i.e. create an entry in 
> ldap, then create an attribute in the users entry that contains the DN 
> of that entry, and use that to determine what roles a user is part of, 
> solely by looking at the users entry.  Nice ''cause you could
config
> referential integrity to clean it up and all if you delete the role, 
> too).  But I ran into the same problem - only the apps I wrote knew 
> how to use it (but at least it worked in any ldap server :) ).  At 
> least it didn''t have the resource limit issues that groupofurls
has.
>
> Anyway,  the issue of large groups does exist for me, so it is a 
> concern - A customer of 100k-1 million or more is not out of the 
> question.  It would have to be used with care.   But, in the case of 
> smaller deployments, or even smaller or "select" groups, it would
be
> useful to have this for cases where I can''t make apps use the
Netscape
> extensions.  In a lot of cases, the _app_ doesn''t need to deal
with a
> large list of returned values - i.e. if I do a search for 
>
(&(cn=MyGroupName)(objectclass=groupofuniquenames)(uniquemember=<someUserDN>)),
> returning say,  only the cn attribute or discarding everything but a 
> found/not found result to see solely if I''m a member, I would want
it
> to work.  Some apps use this to determine group membership, and
can''t
> be changed...  This is actually the more likely scenario than wanting 
> to use/display the entire list.
>
> Haven''t really thought this through, but would it be possible to
use a
> combination of roles and cos to create a group the way I am 
> suggesting?  I would think even if possible, it would be complicated 
> and probably pretty inefficient, but is an option.  If I remember 
> correctly, you can''t search on dynamic attributes generated by
Cos,
> though (actually, I think in the most recent version of the Sun DS, 
> you could search on them, but they are treated as unindexed 
> searches)...  This would likely factory into the members dynamically 
> returned as uniquemember idea as well, so one more inefficiency in 
> implementing my idea :-D
In Fedora DS these attributes are "indexed" so you can search on them 
very quickly (e.g. ldapsearch .... (nsrole=ROLEDN)).

But, point taken.  Roles work great, but they don''t conform to the 
standard group schema.  We could use our roles/cos technology to 
implement a very efficient static group.  One problem remains though - 
how to solve the problem of retrieving a large static group?
>
> - Jeff
>
>
>
> David Boreham wrote:
>
>> I should also say that the roles feature was born at a time
>> when the product was marketed for very large scale deployments.
>> We had seen for example the mail server users attempt to create
>> groups with millions of entries. That just didn''t work at all
well.
>>
>> That was then and this is now: the target market is somewhat
>> different. For the typical F500 company with a few thousand employees,
>> virtual view static groups are probably just fine.
>>
>>
>> -- 
>> Fedora-directory-users mailing list
>> Fedora-directory-users@redhat.com
>> https://www.redhat.com/mailman/listinfo/fedora-directory-users
>
>
>
> -- 
> Fedora-directory-users mailing list
> Fedora-directory-users@redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-directory-users

I seem to have missed the start of this thread, so apologies for replying to
both posts here: 
> -----Original Message-----
> From: fedora-directory-users-bounces@redhat.com 
> [mailto:fedora-directory-users-bounces@redhat.com] On Behalf 
> Of Richard Megginson
> Sent: Friday, June 10, 2005 4:45 PM
> To: General discussion list for the Fedora Directory server project.
> Subject: Re: [Fedora-directory-users] Ideas for fds
> 
> jclowser@unitedmessaging.com wrote:
> 
> > Haven''t really thought this through, but would it be 
> possible to use a 
> > combination of roles and cos to create a group the way I am 
> > suggesting?  I would think even if possible, it would be 
> complicated 
> > and probably pretty inefficient, but is an option.  If I remember 
> > correctly, you can''t search on dynamic attributes generated
by Cos,
> > though (actually, I think in the most recent version of the Sun DS, 
> > you could search on them, but they are treated as unindexed 
> > searches)...  This would likely factory into the members 
> dynamically 
> > returned as uniquemember idea as well, so one more inefficiency in 
> > implementing my idea :-D
> 
This crops up every now and then and for the reasons given I (and others)
have fended it off.  I am always weary of performance expectations with
feature requests and it is probably unlikely that an implimentation like
this would equal static group performance let alone roles performance.  As
others have said, those potentially huge attribute value lists are a major
issue - just moving that data around on the server side is burdonsome.

Having said that, I did consider what would be required to do this.  If you
required a two way relationship where the static groups could be updated old
style then you would need to make virtual attributes writeable - not a slam
dunk by any means.  If you just wanted readable entries then that is
possible, but not the way you suggest.  You would be far better off creating
a new virtual attribute service provider designed for the purpose than
retro-fitting the functionality into roles.  It could key off the nsrole
attribute and/or interpret dynamic groups.
> In Fedora DS these attributes are "indexed" so you can search 
> on them very quickly (e.g. ldapsearch .... (nsrole=ROLEDN)).
> 
When did indexing get added? :)

Are there really large numbers of applications deployed that
grok static groups ? I''d like to hear about them because I
can''t
remember ever seeing one. Mind you I don''t get out much ;)

I think it would be useful to hear more about the use-cases in
applications for groups. Understanding those might shed more
light on the subject. I used the mail list group example previously,
but there will be many others each with its own peculiar set of
issues I suspect.

Way back I did think about intercepting a search for a
particular uniquemember attribute value on a group, generating
the result from roles-like logic. However, at the time it seemed
good to leave the static group semantics alone and define a new
mechanism (roles/cos). The intention at the time was to
submit the work to the IETF working group and eventually
have industry-wide support for the feature. Since that didn''t
happen perhaps the choice to not integrate with static groups
was wrong, I''m still not sure though. One key aim with
roles/cos was that an application should be able to determine
all the things it needed to know in connection with an entry
by inspection of _the_entry_ itself (and not some other object
such as a group entry). The logic was: I''m an app, I want to
make a decision about entitlement or somesuch for this entity,
so let me look at their LDAP entry and decide what to do.
The idea was that the policy regarding entitlement and access
would be contained in and interpreted by the DS (and hence
allow arguably useful benefits such as centralized management of
entitlement/access control across the enterprise). I believe that
AD has this for its groups : you can see the groups an entry
belongs to by looking only at the entry. You can''t do that with
FDS static groups.

Pete Rowley wrote:
>I seem to have missed the start of this thread, so apologies for replying to
>both posts here: 
>  
>
The thread started with looking for a solution to a "simple" problem
(of
course) :)

Basically, if I have an application that looks for members of groups for 
things like authentication and access control, it''s common for that app
to look at something like 
(&(objectclass=groupofuniquemembers)(dn=<usersdn>)) to determine if
they
are a member or not.  In many cases, the apps have this hardcoded and 
don''t allow the filter to be changed.  Alternately, they may read these
static groups for things like determining a list of members to send mail 
to (if they are used as mail lists, for example).

In some cases, these groups change often, and/or are burdensome to 
manage statically, so it would be nice to set them up as dynamic 
groups.  nsRole and groupOfURLs provides this functionality, but is 
incompatible with the above apps, so you have to fall back on static lists.

Was just saying it would be nice to be able to support dynamic lists in 
such a way as to be compatible with apps that only know how to check 
static groups.

I know there are a lot of issues related to performance, etc, but it 
would be nice if there was some way somewhere to deal with this 
problem.  Anyway, just wanted to through this out there for discussion, 
and see if it could be done, if others had dealt with this, come up with 
alternate solutions that work in the above case, etc (one solution I''ve
implemented in the past was to create a custom "dynamicGroup" 
objectclass inherited from groupofuniquenames, which had a memberURL or 
similarly named attribute, and then had a nightly script that ran the 
ldap url and populated uniquemember).  ''Course, that has obvious 
limitations, such as the list not updating often enough, and still has 
the problem inherent in large lists.

Maybe FDS will be accepted widely enough that other directory servers 
and apps will start supporting nsrole and/or groupOfURL''s and this will
become a moot issue (though groupOfURL''s has it''s problems as
well)  :)
>This crops up every now and then and for the reasons given I (and others)
>have fended it off.  I am always weary of performance expectations with
>feature requests and it is probably unlikely that an implimentation like
>this would equal static group performance let alone roles performance.  As
>others have said, those potentially huge attribute value lists are a major
>issue - just moving that data around on the server side is burdonsome.
>  
>
Agreed - I understand some of the overhead in this, and that it would 
have an impact (esp vs true static groups), but if used carefully... 
''Course, as soon as you implement it, there will be people that abuse
it
and/or do not understand the caveats involved in using it, and you get 
hammered for implementing something that has poor performance :)
>Having said that, I did consider what would be required to do this.  If you
>required a two way relationship where the static groups could be updated old
>style then you would need to make virtual attributes writeable - not a slam
>dunk by any means.  If you just wanted readable entries then that is
>possible, but not the way you suggest.  You would be far better off creating
>a new virtual attribute service provider designed for the purpose than
>retro-fitting the functionality into roles.  It could key off the nsrole
>attribute and/or interpret dynamic groups.
>  
>
Well, I was thinking along the lines of the behavior of CoS, where you 
can read attributes that may have generated values, you can write to it 
(and I believe the static and dynamic values are either merged or one 
takes precedence - been a while and I forget the behavior).
>>In Fedora DS these attributes are "indexed" so you can search 
>>on them very quickly (e.g. ldapsearch .... (nsrole=ROLEDN)).
>>    
>>
>
>When did indexing get added? :)
>
>  
>
Um... maybe I''m mixing up some of the differences that happened after 
the Netscape/Iplanet/SunONE/JES/name of the day split happened, and this 
is only in the latest Sun release :-D (or was that even something that I 
said?).

 - Jeff

David Boreham wrote:
> Are there really large numbers of applications deployed that
> grok static groups ? I''d like to hear about them because I
can''t
> remember ever seeing one. Mind you I don''t get out much ;)
Hmm - good question.  I''ve been working with nsds since 1.0, and over 
that time, it comes up every so often, but I couldn''t give you a big 
list of apps that exist now :)

One simple realworld example I run into:
- I want to create a group of people.  Lets say I want this to be all 
people in the engineering department, which is determined by having the 
value "engineering" in the department attribute of their entry.
- I want to use that group as a mail group in Sun JES (or Netscape) 
messaging server.  I can create a groupofURLs style group that the 
Messaging server will use to determine members of the email list, based 
on an appropriate filter.  As a dynamic group, it maintains itself (sort 
of - I guess it''s more a matter of a client that knows how to interpret
it).  Messaging server also recognizes uniquemember values as members of 
the list, so if that were dynamically generated, it would work in place 
of groupOfUrls.
- Further, I want to set up a webpage in Apache that only the 
engineering group can see.  Apache doesn''t deal with groupOfURL style 
lists, as far as I know, so this doesn''t work. (groupOfURLS being ok
for
finding a list of members, but lousy for determining if a user is a 
(dynamic) member of it)  Nsroles would probably work for apache, but I 
don''t think JES/Netscape messaging supports nsroles as a means for 
defining mail groups - its not really appropriate for determining lists 
of users like this.

Ignoring for the moment that JES messaging is pretty much tied to one 
ldap implementation (i.e. the Sun JES Directory server), I want to use 
the same group across apps, because I don''t want to have to maintain 2 
versions representing the same group information and possibly have them 
out of sync.  Also, I want to be able to send email notices related to 
the engineering web page, targeted at those users that have access to 
it.  I _could_ define the same LDAP URL in apache for access to the web 
page - i.e. ignore the group and just use the same or similar LDAP URL 
that I used in the mail list for apache .htaccess files.  But... if I 
later change the group filter in LDAP - say I make the filter 
(|(department=engineering users)(department=engineering staff)), if I 
don''t remember to go back and change things in apache everywhere
it''s
defined, I loose consistency.

Maybe the best solution would be to create a single ldap entry that is 
groupOfUrls, inetMailgroup (JES mail list), and a dynamic nsrole group, 
so that one entry defines the same list of users in multiple ways that 
each app can find.  At least having this all together means that if I 
change my filter, I will see all the filters/methods in one place, so in 
my above example I won''t have to go find all my apache .htaccess files.

One last thing to keep in mind - nsroles and groupOfUrls is a 
netscape/sun/fds schema extension.  If I want to keep an app portable, 
so that I can drop in openldap, FDS, AD, etc without having to go back 
and change all my apps, nsroles and groupOfURL''s don''t work -
is there a
way that is consistent across ldap implementations?  With a "dynamic" 
groupOfUniqueNames, this would be portable, though on other ldap 
implementations, my list may have to become static if the replacement 
ldap implementation can''t generate it on the fly.

I guess what I am really lookig for is a standardized way to define a 
dynamic group that works consistently across applications (and is 
"portable" across ldap implementations).  groupOfUniqueNames fits this
for static groups, but there is nothing that fits this for dynamic groups.

Does that make sense?  Any ideas on solutions, or am I asking too much? :)

Anyway, sorry for beating this horse to death...

 - Jeff

jclowser@unitedmessaging.com wrote:
> One simple realworld example I run into:
> - I want to create a group of people.  Lets say I want this to be all 
> people in the engineering department, which is determined by having 
> the value "engineering" in the department attribute of their
entry.
I guess by an example I mean the complete application use-case. When you say
you want to create a group, I say ''ok, what do you want to do with that
group?''.
e.g. enforce access control to the engineering building doors ? Allow higher
internet bandwidth to engineering staff ? Something like that ?
> - Further, I want to set up a webpage in Apache that only the 
> engineering group can see.  Apache doesn''t deal with groupOfURL
style
> lists, as far as I know, so this doesn''t work. (groupOfURLS being
ok
> for finding a list of members, but lousy for determining if a user is 
> a (dynamic) member of it)  Nsroles would probably work for apache, but 
> I don''t think JES/Netscape messaging supports nsroles as a means
for
> defining mail groups - its not really appropriate for determining 
> lists of users like this.
This is an interesting one, because applications like apache were the
target for roles/cos. Do you know what Apache does support for
detemining page access via LDAP ?

David Boreham wrote:
> This is an interesting one, because applications like apache were the
> target for roles/cos. Do you know what Apache does support for
> detemining page access via LDAP ?
Roles should work for apache.  Out of habit, I''ve used apache/auth_ldap
as follows, to limit users to a group (from an htaccess file):

    AuthLDAPURL ldap://ldap1.airius.com:389/ou=People, 
o=Airius?uid?sub?(objectClass=*)
    require group cn=Administrators, o=Airius

In this case, if memory serves, this will look up the user by uid to get 
their dn and auth them, then will check to see if their dn is in the 
uniquemember attribute of the group to see if they can see whatever is 
protected.

I think (have not tested this), I could use roles instead by doing:

    AuthLDAPURL ldap://ldap1.airius.com:389/ou=People, 
o=Airius?uid?sub?(nsRole=<dn of the role>)
    require valid-user

Or something like that.  So, instead of saying "auth the user and see if 
they are in a group, and if so they are allowed", we are saying "auth 
any users, but only if they match this filter, and if they do, they are 
allowed".  The roles method actually uses half the searches, so is more 
efficient, admittedly :)  But, apache (auth_ldap) is nice enough to 
allow you to define the filters.  Netscape Enterprise/Fastrack web 
server only did groups one way - it looked at static members in the 
uniquemember attribute.  Part of why I always used Apache instead.  (ok, 
so admittedly that''s a _really_ old example, and may not even apply to 
whatever state that server is in at Sun these days... :)  )

The problems I''ve run into is that I want to create a group that:
1.  Represents some some subset of users (obviously)
2.  Is dynamically generated (otherwise I''d use groupOfUniqueNames and 
be done).
3.  Can be used for multiple applications.  For example:
    a.  As an auth group for apache .htaccess files
    b.  Can be used as an email list for messaging servers.
    c.  aci groups in ldap (for example, I want this group of people to 
be able to edit certain fields in ldap).
    d.  defines a vpn template (I think checkpoint firewall 1 extends a 
groupofuniquenames group to include vpn template attributes to determine 
who can access what services).
    (e.  probably other things but can''t think of ''em now :) 
)
    Anyway, the point is that one group may be used by multiple things 
and represent different functions that group of users can do across 
different services (Example:  members of the HR group can log into a web 
page that allows you to change users contact info (apache auth), gets 
email notices related to this web page (mail server list), and has 
rights in LDAP to actually make these changes (LDAP acis).  Further, I 
only allow HR users access to the server this runs on via a VPN).
4.  Is portable across ldap server implementations (otherwise, why use a 
standard like LDAP?)

So I guess I see a group as doing 2 things, primarily:  Allowing me to 
determine all the members of the group (i.e. for things like email 
lists), and to determine if someone is a member of a particular group 
(i.e. I can do/access X if I''m part of group Y).  The difference is 
whether my searches return a list and I do something involving all the 
members of it, or if I just want to return what lists I am a member of.

Speaking to portability across LDAP server implementations:
1.  There is nothing "special" about groupOfURLs, since the client has
to read memberURL and process that to get the list (and hope it doesn''t
run into resource limits).  So, one caveat here is that the "dynamic" 
group part is implemented on the client, so is really more of a schema 
thing vs server coding (ignoring for the moment the server''s use of it 
in acis).  It also has not really been widely adopted as a group 
mechanism (only by Sun/Netscape/iPlanet/etc, as far as I know).

2.  roles are "special", in that FDS can generate them.  However, I 
_can_ add the schema to most ldap implementations and statically 
maintain the nsrole attribute (which is close enough to portable to me - 
i.e. if I go from FDS to OpenLDAP for whatever reason, I loose the 
ability to have this populated dynamically, but I can still manually 
populate it and use it without changing all my applications).  I suppose 
a Role could be extended and used for email lists just as easily as 
groupOfUrls is, now that I think about it, since the mail server would 
have to do almost the exact same work to find members (and face the same 
resource limits).  But... I can''t change servers like Netscape/Sun JES 
messaging to support this.  If I ported this to Openldap, the problem 
would become cleaning up these statically created groups (even with 
static roles, I can use referential integrity on FDS to clean ''em up), 
but that''s just a cron script :)

3.  groupofUnique names is "standard" so is in there for every ldap 
server I''ve seen (even AD), so is definately portable, but is not as 
useful because it''s not dynamic.

4.  Admittedly, aci''s should probably be out of scope for this idea - 
since ldap access control is not portable, how you define a group to 
support it being portable is probably not so important :)

I guess what it really comes down to is trying to find a way to 
implement dynamic groups that is transparent to applications that don''t
know how to use them.  Maybe part of it is that I''ve been doing this
for
so long (since Netscape dir server 1.0 and the original U of Mich 
stuff), I have some old habits I need to unlearn :) 

Sorry for rambling on for so long over so many messages about all this :-)

- Jeff

jclowser@unitedmessaging.com wrote:
> Sorry for rambling on for so long over so many messages about all this 
> :-)
No, this is good stuff. I''d be nice to finally nail this. Only been
working
on it for 8 years ;)

Now, when roles (and to an extent cos) were originally conceived,
one thing I did was ask "if I were an application writer and I wanted
to use the DS to decide to allow or not allow someone to do something,
how would I want to do that ?". To be honest, I never thought the
answer would be "I''d like to test to see if the entry is a member
of
a static group". I was thinking more of trying to keep the application
logic very simple (and also assuming that there weren''t many
applications
that existed in the wild that I needed to worry about being compatible 
with).

Instead, the idea I had was to require that the application instead simply
read attribute(s) on the user''s entry, and do what it needs to do based
on
their values. For example the VPN app would read an attribute called
''allowVPNAccess'', and if it had the value
''true'', then it would allow
the user
access.

Everything else kind of followed from that original concept.
I guess also the problem I was trying to solve was that to
a first approximation no applications had decent LDAP support
at that time (not even Netscape applications).
So a feature that made the implementation hurdle for the app
developer to add LDAP support lower seemed like a good idea.

Perhaps that was a mistake. Anyway, just to give you some insight
into how this stuff came into being.

David Boreham wrote:
> Instead, the idea I had was to require that the application instead 
> simply
> read attribute(s) on the user''s entry, and do what it needs to do 
> based on
> their values. For example the VPN app would read an attribute called
> ''allowVPNAccess'', and if it had the value
''true'', then it would allow
> the user
> access.
Roles are great if I''m looking for a yes or no answer - i.e. do I have 
role x or not?  Sometimes that''s not enough.  To give a couple
examples...

In the case of the VPN Template (and I only worked on this briefly a 
couple years back), I believe the checkpoint stuff worked like this:

1.  They created a new vpntemplate schema extension of groupofuniquenames
2.  This extended group had attributes to limit times, hosts, and a 
bunch of other things they could access when connected to the VPN.
3.  When a user logged into the VPN, it would auth the user, then search 
for  something like 
(&(objectclass=vpntemplate)(uniquemember=<authedusersdn>)).
4.  If that returned a group, these other attributes in the returned vpn 
group define what access the user has.


I wrote a web admin tool that we use for our customers here that uses a 
similar concept:
1.  I created an extention of groupofuniquenames to create an "admin"
group.
2.  This admin group has attributes to contain:
    - a "template" (a reference to a php file that does something like
user admin, group admin, etc).
    - settings for the template (i.e. email domain to use, quota 
options, etc.)
3.  Different users may be members of different templates for user admin 
(say, full user admin template,
     password admin template, etc), and settings allow me to reuse 
templates for different customers
     (same template, but different search bases for users, different 
quota options, different dns domains
     for email, etc)
3.  When a user logs in, it searches for 
(&(objectclass=admingroup)(uniquemember=<usersdn>))
     to see which admin capabilities the user has, and how those 
capabilities are applied.
4.  For each admin group I find, I read the template, settings, etc. and 
present a list of tabs - each
    admin group translates to a tab, and the extra attributes in the 
extended admin group tells it
    the name of the tab, what code to use in that tab, and config info 
to drive how that tab works.

There''s more to it than that, but that''s the basics.

If I used roles here instead, I could probably extend the role the way I 
extended groupofuniquenames.  Then, when I auth the user, I''d see the 
roles the user is a member of, and run through that list to see which 
are admin groups and get those settings there.  FWIW, this was more a 
case of showing how I''m using groups than why I need a better dynamic 
group - creating dynamic admin groups is probably not the best thing to 
do :).

 - Jeff

jclowser@unitedmessaging.com wrote:
> David Boreham wrote:
>
>> Instead, the idea I had was to require that the application instead 
>> simply
>> read attribute(s) on the user''s entry, and do what it needs to
do
>> based on
>> their values. For example the VPN app would read an attribute called
>> ''allowVPNAccess'', and if it had the value
''true'', then it would allow
>> the user
>> access.
>
>
> Roles are great if I''m looking for a yes or no answer - i.e. do I
have
> role x or not?  Sometimes that''s not enough.  To give a couple 
> examples...
>
> In the case of the VPN Template (and I only worked on this briefly a 
> couple years back), I believe the checkpoint stuff worked like this:
>
> 1.  They created a new vpntemplate schema extension of groupofuniquenames
> 2.  This extended group had attributes to limit times, hosts, and a 
> bunch of other things they could access when connected to the VPN.
> 3.  When a user logged into the VPN, it would auth the user, then 
> search for  something like 
> (&(objectclass=vpntemplate)(uniquemember=<authedusersdn>)).
> 4.  If that returned a group, these other attributes in the returned 
> vpn group define what access the user has.
Interesting. This was what role-based-cos was designed for.
Would that have worked for this application ?
(user''s role drives cos, which returns a set of attribute values
on the user''s entry from cos).

David Boreham wrote:
>
>> In the case of the VPN Template (and I only worked on this briefly a 
>> couple years back), I believe the checkpoint stuff worked like this:
>>
>> 1.  They created a new vpntemplate schema extension of 
>> groupofuniquenames
>> 2.  This extended group had attributes to limit times, hosts, and a 
>> bunch of other things they could access when connected to the VPN.
>> 3.  When a user logged into the VPN, it would auth the user, then 
>> search for  something like 
>> (&(objectclass=vpntemplate)(uniquemember=<authedusersdn>)).
>> 4.  If that returned a group, these other attributes in the returned 
>> vpn group define what access the user has.
>
>
> Interesting. This was what role-based-cos was designed for.
> Would that have worked for this application ?
> (user''s role drives cos, which returns a set of attribute values
> on the user''s entry from cos).
I think it would be feasible in that role-based cos could provide the 
equivalent end result, (if the vendor changed their product to know how 
to look at roles?).  Assuming a closed source COTS application, 
hardcoded to the above filter (looking at uniquemember for membership), 
is there a way to make roles based-cos match on that search?  I 
understand that changing apps to support roles should be easy, but 
unless you _can_ change the app, that doesn''t help much, unfortunately.
How wide spread has adoption of Roles been (or does it need to be)?  
Maybe with the introduction of FDS into the open source world, that will 
change soon.

An example entry would be something like the following (making up the 
attributes and stuff, but the form is close enough as an example):

objectclass: top
objectclass: groupofuniquenames
objectclass: vpntemplate
accesstime: 0900-1800
accesshosts: host1.example.com
accesshosts: host2.example.com
uniquemember: uid=jdoe,ou=people,o=example.com
cn: Engineering VPN
...

 From what I remember, that vpn server searched for the users dn in 
uniquemember to find a template entry, and the above is what it is 
expecting to find.  How would I set up Roles and CoS entries that would 
work without changing the app (is that possible)?  Can I set up 
Roles/CoS that would populate the uniquemember attribute of the 
vpntemplate entry?  Is that searchable (if I remember correctly, early 
versions of CoS didn''t allow you to search on cos populated attributes,
later versions might have, and I''m not sure where in that line FDS is).

My job has tended to be more one of deploying existing software and 
finding a way to make it all work together, rather than being the 
developer writing the software (though I do do some coding), so I don''t
necessarily have the option of changing the app to use a new form.  Some 
apps are _really_ bad (depend on specific tree structures, etc - my 
"favorite" are those that are "ldap integrated", meaning
"the first time
you log in, it reads your info and copies it to a relational db and uses 
that from there on..."), and businesses don''t always allow you to
select
apps based on how well they properly integrate against ldap :-(

Admittedly, I have not played with Roles too much - never _thought_ they 
really fit anything I was doing, but maybe it''s time to take another 
look at them (esp if I can resolve the above with them :) ).

 - Jeff

> From what I remember, that vpn server searched for the users dn in 
> uniquemember to find a template entry, and the above is what it is 
> expecting to find.  How would I set up Roles and CoS entries that 
> would work without changing the app (is that possible)?  Can I set up 
> Roles/CoS that would populate the uniquemember attribute of the 
> vpntemplate entry?  Is that searchable (if I remember correctly, early 
> versions of CoS didn''t allow you to search on cos populated 
> attributes, later versions might have, and I''m not sure where in
that
> line FDS is).
Yeah, I don''t know about this. I was more interested in the semantics
of the
checkpoint application behavior, which I think are easily implemented with
role-based cos (the end result is that the user entry has the necessary vpn
cruft on it directly, with no need to indirect to the template entry at 
the client end).

If an existing application can be made to simply fetch its per-user 
parameters
from attributes on the user''s entry , then roles/cos will work fine.

I have no idea what proportion of deployed applications can do this,
but it seems simpler and easier than indirection via a group that acts as
a template entry. I would _hope_ that an application that supports the
fancy ''indirect via a group'' thing, would also support the
very simple
''read some attribute values from the user''s entry''
model too.
Whether or not that''s a reasonable thing to hope for, I''m not
sure
these days.

Just to be clear: I don''t expect (nor require) that there are any
applications that ''support'' roles. All the applications need
to do
is to support regular ldap attributes on the user entries.

Pete Rowley wrote:
>I seem to have missed the start of this thread, so apologies for replying to
>both posts here: 
>
>  
>
>>-----Original Message-----
>>From: fedora-directory-users-bounces@redhat.com 
>>[mailto:fedora-directory-users-bounces@redhat.com] On Behalf 
>>Of Richard Megginson
>>Sent: Friday, June 10, 2005 4:45 PM
>>To: General discussion list for the Fedora Directory server project.
>>Subject: Re: [Fedora-directory-users] Ideas for fds
>>
>>jclowser@unitedmessaging.com wrote:
>>
>>    
>>
>>>Haven''t really thought this through, but would it be 
>>>      
>>>
>>possible to use a 
>>    
>>
>>>combination of roles and cos to create a group the way I am 
>>>suggesting?  I would think even if possible, it would be 
>>>      
>>>
>>complicated 
>>    
>>
>>>and probably pretty inefficient, but is an option.  If I remember 
>>>correctly, you can''t search on dynamic attributes generated
by Cos,
>>>though (actually, I think in the most recent version of the Sun DS, 
>>>you could search on them, but they are treated as unindexed 
>>>searches)...  This would likely factory into the members 
>>>      
>>>
>>dynamically 
>>    
>>
>>>returned as uniquemember idea as well, so one more inefficiency in 
>>>implementing my idea :-D
>>>      
>>>
>
>This crops up every now and then and for the reasons given I (and others)
>have fended it off.  I am always weary of performance expectations with
>feature requests and it is probably unlikely that an implimentation like
>this would equal static group performance let alone roles performance.  As
>others have said, those potentially huge attribute value lists are a major
>issue - just moving that data around on the server side is burdonsome.
>
>Having said that, I did consider what would be required to do this.  If you
>required a two way relationship where the static groups could be updated old
>style then you would need to make virtual attributes writeable - not a slam
>dunk by any means.  If you just wanted readable entries then that is
>possible, but not the way you suggest.  You would be far better off creating
>a new virtual attribute service provider designed for the purpose than
>retro-fitting the functionality into roles.  It could key off the nsrole
>attribute and/or interpret dynamic groups.
>
>  
>
>>In Fedora DS these attributes are "indexed" so you can search 
>>on them very quickly (e.g. ldapsearch .... (nsrole=ROLEDN)).
>>
>>    
>>
>
>When did indexing get added? :)
>  
>
I just meant that searches using virtual attributes in search filters 
are processed efficiently as if they had been indexed.
>
>
>--
>Fedora-directory-users mailing list
>Fedora-directory-users@redhat.com
>https://www.redhat.com/mailman/listinfo/fedora-directory-users
>  
>

David Boreham wrote:
>
>> From what I remember, that vpn server searched for the users dn in 
>> uniquemember to find a template entry, and the above is what it is 
>> expecting to find.  How would I set up Roles and CoS entries that 
>> would work without changing the app (is that possible)?  Can I set up 
>> Roles/CoS that would populate the uniquemember attribute of the 
>> vpntemplate entry?  Is that searchable (if I remember correctly, 
>> early versions of CoS didn''t allow you to search on cos
populated
>> attributes, later versions might have, and I''m not sure where
in that
>> line FDS is).
>
> Yeah, I don''t know about this. I was more interested in the
semantics
> of the
> checkpoint application behavior, which I think are easily implemented 
> with
> role-based cos (the end result is that the user entry has the 
> necessary vpn
> cruft on it directly, with no need to indirect to the template entry 
> at the client end).
>
> If an existing application can be made to simply fetch its per-user 
> parameters
> from attributes on the user''s entry , then roles/cos will work
fine.
The problem lies in what happens if the user is part of multiple 
templates.  For example, one template may say I can access host 1 and 2 
from 9am to 5pm, and another template may say I can access host 3 (no 
time specification, so any time), etc.  If I use roles to merge all the 
values from all these templates into the users entry, I may get 
something like host 1, 2, and 3 are allowed only from 9am-5pm, depending 
on how the templates are organized/defined by the vendor, which is 
different from what I had intended.  FWIW, as I remember it, the 
checkpoint product did allow these in the users entry, and I think it 
broke if a user was actually part of more than one template, but I was 
trying to speak generically vs a particular product :).
> Just to be clear: I don''t expect (nor require) that there are any
> applications that ''support'' roles. All the applications
need to do
> is to support regular ldap attributes on the user entries.
Sorry - bad wording on my part.  When I say "support roles", that 
includes the case where I can read the info from the users entry as you 
specified.  I think it just comes down to being creating in the use of 
roles, and in some cases, nothing will help.

 - Jeff