Sure,  lets say you have the below ACI which limits the addition of entries based on a group(it's been a while since I've worked with these, so forgive me if the syntax is a bit off)


dn: dc=mydomain,dc=com
subTreeACI: allow#a,m#group:cn=my dnymaicgroup,ou=groups,dc=mydomain,dc=com

then you would have a group:

dn: cn=my dynamicgroup,ou=groups,dc=mydomain,dc=com
objectClass: groupOfUrls
memberURL: ldap:///dc=mydomain,dc=com??sub?(someAttrb=someVal)

The combination of the ACI and the dynamic group defenition would in effect let you limit the permisions based on an attribute value.

Marc

On 9/26/05, Alex Karasulu <[EMAIL PROTECTED]> wrote:
Marc Boorshtein wrote:

> Actually it does, but not in a "direct" way.  I've seen the draft
> model used with dynamic groups which would allow the same functionality.
>
Can you elaborate some more on this?  Also I think we do have group
membership as a factor in determining ACI evaluation.  However this is
not the same as using dynamic groups.

I guess a dynamic group is modeled as a filter and this filter exerts an
assertion on an attribute's value within an entry to determine inclusion
within a group.

Thanks,
Alex

>
> On 9/26/05, *Alex Karasulu* <[EMAIL PROTECTED]
> <mailto:[EMAIL PROTECTED] >> wrote:
>
>     Trustin Lee wrote:
>
>     > I forgot to mention that it would be simpler to merge two operation
>     > scopes (attributeType and attributeValue) into one (attribute) so we
>     > have only two operation scopes (entry and attribute).  I don't
>     see any
>     > problem with this simplification for LDAP.  WDYT?
>
>     Yes I think we can make this simplification.  I looked to see if this
>     draft here has done the same though:
>
>     http://www.ietf.org/proceedings/01aug/I-D/draft-ietf-ldapext-acl-model-08.txt
>
>     I could not see any ACI which limited operations based on the value of
>     an attribute.  This is perhaps an example where X.500 goes way beyond
>     what is necessary.
>
>     In either case I think the best philosophy for us is to take what we
>     initially is the best of X.500 and this draft to come out with a
>     working
>     implementation.  Let's start using it and having our users use
>     it.  Get
>     feedback from them and start compiling a set of use cases which users
>     want/need which our implementation does not provide.  Then we can go
>     back and easily add this functionality.
>
>     Over time we're going to find out what the optimal ACI descriptor
>     really is.
>
>     Alex
>
>


Reply via email to