[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
RE: LDAP ACLs
In light of the resounding defeat of the multiple-ACL-model-support
resolution at the Los Angeles meeting, I find it difficult to understand
why one person's individual misunderstanding obviates the clear
consensus developed on that day. I believe the minutes will show that
the question was put clearly to the room, aside from any particular
arguments that may have been offered.
IMHO, Multiple ACL models will make LDAP irrelevant to real business.
I'm inclined to wonder (albeit cynically) if that is not precisely the
point.
One may (as you have) provide eloquent and substantial arguments in
favor of multiple ACL models for a given system. If support for native
authorization mechanisms is required, more often than not the use of
native access methods will be used, not a union of all possible
protocols. Unless someone wants to write a draft for LDAA (Lightweight
Directory Access Architecture) which contains pluggable authorization,
selectable transport, dynamic schema management, etc. etc., I think the
notion of multiple acl models for LDAP should be put to bed.
> -----Original Message-----
> From: Paul Leach [SMTP:paulle@microsoft.com]
> Sent: Wednesday, April 29, 1998 12:20 AM
> To: ietf-ldapext@netscape.com
> Subject: LDAP ACLs
>
> -----BEGIN PGP SIGNED MESSAGE-----
>
> After the WG meeting in L.A., I was talking to Ed Reed about ACLs, and
> he said that he had misunderstood my proposal. On the theory if he
> had, others may have as well, I'm going to restate it here in writing
> and attempt to reopen the issue.
>
> My proposal was this:
> 1. any given server implementation would store and support exactly one
> kind of ACL -- the kind that it could enforce, either itself or with
> the help of its friendly local OS.
> 2. However, there might be several different kinds of ACL formats,
> for different servers. Each format would have an OID associated with
> it.
> 3. There would be a standardazed was for clients to ask a server for
> the ACL associated with an object. What that request would return
> would be an ACL format OID, and then the ACL in that format.
> 4. There would be a standardized way for clients to ask a server to
> set the ACL associated with an object. That request would take an ACL
> format OID, and then an ACL in that format. If the format wasn't the
> one supported by that server, the request would fail.
>
> This is similar to the approach adopted by WebDAV (and possibly IMAP
> - -- we had reports from IMAP WG people when WebDAV was considering
> ACLs, and that's what I thought they said, but I'm not positive I
> understood it completely. I do recall they said that they were unable
> to come up with any universal ACL format.)
>
> - ----------------------------------
> Paul J. Leach <paulle@microsoft.com>
> PGP Key ID: 0x978829DD
> Fingerprint: 9EFA A405 39B4 F91F DE6F 8939 6FE9 F5D8
> Key Servers: http://pgpkeys.mit.edu:11371 ldap://certserver.pgp.com
>
>
> -----BEGIN PGP SIGNATURE-----
> Version: PGP 5.5.5
>
> iQCVAwUBNUbUkcqlCdSXiCndAQHvvwP+KQb8jbiiUf0UM8fnKAmmZFVbUZGpYGXq
> PlHQv90QFUEeYBwjRJh4JGt88apKgbSa2TprtsfT0fQ6Ga6YdOrO6ninluhwlvMq
> 2oRqDrXC6qJ1gIc6Dbnyza6qtCZ1cypt64Fe+Mito9z87BiyVOsG0T163NJPjCOd
> 1kdgIEnxfqw=
> =VfVb
> -----END PGP SIGNATURE-----
>