James Mason wrote:
Talking about ACLs gets really sticky. As far as I know every LDAP server has it's own unique way of managing authorizations internally. Since LDAP is just a communication protocol I don't think it has any specifications for this, so I don't know of any standard way to get/set access permissions on objects in an LDAP server. This makes managing ACLs through Slide rather difficult. I see three approaches to this: 1) Slide has a very permissive ACL for every object in the LDAP store, basically handing all authorizations off to the LDAP server. 2) Slide connects to the LDAP server as an "admin" user then manages ACLs internally to control access. This has some possible security and auditing complications, though. 3) LDAP is read only. All management is done externally to Slide. This works for users and groups but really limits LDAP as a general purpose Store.
The other thing to consider is how to handle Slide-specific attributes on objects. All objects in LDAP have one or more "objectClass" attributes that determine which properties are available on the object. Extending the LDAP schema with a new Slide objectClass is doable but not always feasible (I would have a hard time getting our LDAP admin to do that, for instance). This means Slide will need to support storing extended properties locally in addition to the properties stored in LDAP. I was thinking of maybe extending the tx store and mapping which properties should be stored where.
I don't think LDAP is suitable for a general purpose Store for the
reasons you mentioned. Most of the tools supporting LDAP just use it for
user/group/roles. I think the Slide LDAP store should be something like
the JBoss LDAP login module. The LDAP queries to authenticate (bind) and
get the roles are customizable. If we want to have the user nodes in
Slide, we just map a minimum set of LDAP attributes to WebDAV, and those mappings are customizable.
Basically, your solution 3: LDAP is readonly and leave the ACLs storage
outside of LDAP.
It might be posible to define a standard mechanism, maybe by writing
some Abstract Store class for a partial or "transparent" store, where a store that does not handle an operation it delegates to the parent store. For example, you mount a standard store on /, Tx or JDBC, and then you mount the LDAP store on /users and /roles. If the LDAP store doesn't handle a given operation, like creating arbitrary properties, it delegates to the root store.
Carlos
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
