Re: [ldapext] Dynamic group draft

[Howard Chu <hyc@highlandsun.com>]

Jaimon Jose wrote:
> Howard,
> thanks for the comments.  I couldn't locate any documents on openldap
> implementation of dynamic group.  Appreciate if you can forward any
> reference to this.
>
>   
We've always referred users to the original Netscape documentation, 
since that's where our definitions came from. But for the purposes of 
slapd access control, we've always allowed groups to use arbitrary 
schema.  See our slapd.access( 5 ) manpage. Basically, our syntax is
   access to foo
      by group[/objectclass[/attributename]] = <groupDN> ...

The defaults are groupOfNames and member, but you can use any object 
with any attribute that uses DN or nameAndOptionalUid syntax. This 
covers the static group support.

For a dynamic group, the same config syntax applies, but the objectclass 
and attributename obviously must be provided explicitly. The trigger for 
dynamic group behavior is that the specified attribute must be a subtype 
of labeledURI. This requirement is also spelled out in the slapd.access( 
5 ) manpage.

Ideally I would have said "the specified attribute has URI syntax" but 
obviously there is no such syntax in the base LDAP specification. 
(Though I believe there ought to be. One of the great strengths of 
X.500/ASN.1 is the self-describing nature of data; defining everything 
as IA5string or some other generic string syntax as LDAP has 
traditionally done totally neuters the system. But that's a different 
conversation...)

The original Netscape memberURL definition just uses IA5string syntax,  
but the dyngroup.schema file that we provide with OpenLDAP defines it as 
a subtype of labeledURI so that it will work with our ACL engine.

Re-reading this draft prompted me to revisit some other aspects of our 
implementation, which makes me think it's even more necessary to define 
new schema elements and abandon the current Netscape definitions. I.e., 
the Netscape definition was broken from day one; it is inherently 
impossible for a LDAPv3-compliant server to implement both their 
published definition and their deployed usage, only one or the other can 
actually be supported.  I've documented this problem here:
http://www.openldap.org/its/index.cgi/Software%20Bugs?id=4835


> Howard Chu wrote:
>   
> > Why did you feel it was necessary to define a new "memberQueryURL"
> > attribute that is essentially identical in meaning to memberURL?
> >     
> One reason is the extensibility of the attribute value.  As I remember,
> memberURL can only contain a base, scope and the search filter.  The
> searches are limited to the same LDAP server.  memberQueryURL attribute
> can contain an additional x-chain extension.  LDAP server will chain the
> request in a distributed environment if this extension is present. 
>   

Since you're only talking about x-chain as an extension field in a URL, 
and such a field could appear legally in any URL, I don't think this is 
a problem or a compelling reason. However, for the reasons I alluded to 
above, I believe we do need a new attribute, and it should be a subtype 
of labeledURI.

> > There are some obvious errors in this document, you list the
> > uniqueMember attribute with OID 2.5.4.32 inheriting from
> > distinguishedName, but 2.5.4.32 is actually the owner attribute.
> > uniqueMember is 2.5.4.50 and cannot inherit from distinguishedName
> > since it is of NameAndOptionalUUID syntax, not distinguishedName syntax.
> >     
> Thanks for pointing this out.  I will correct them.
>   
> > There's a lack of symmetry here - "excludedMember" is used for both
> > member and uniqueMember but it shouldn't be since the two syntaxes are
> > not the same. You need an excludedUniqueMember attribute to provide
> > the relevant functionality.
> >     
> excludedMember is a list of DNs that need to be excluded from the
> returned result set.  This disparity was caused because the original
> implementation returned both dynamic and static member list as
> "member".  However, do you really see a need for two attributes?
>   

Frankly I've never seen anybody using uniqueMember for its intended 
purpose. But it seems to me that if you are using uniqueMember, with a 
syntax of nameAndOptionalUID, then your set of exclusions must also use 
nameAndOptionalUID syntax.

But now that I think of it, evaluating the URL will perform a search 
which can only return actual DNs, so perhaps just a single exclusion 
attribute of DN syntax is fine. But that raises the question of whether 
defining a dynamic version of this group is actually a safe or valid 
thing to do. Only the static uniqueMember attributes will actually have 
the "unique" semantics. If anybody was actually relying on the DN 
uniqueness characteristic here, they would be in for disappointment at 
least, but most likely a security breach. IMO use of dynamic behavior 
with groupOfUniqueNames should be prohibited for these reasons.

--
 -- Howard Chu
 Chief Architect, Symas Corp.  http://www.symas.com
 Director, Highland Sun        http://highlandsun.com/hyc
 Chief Architect, OpenLDAP     http://www.openldap.org/project/


_______________________________________________
Ldapext mailing list
Ldapext@ietf.org
https://www1.ietf.org/mailman/listinfo/ldapext