[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
RE: LDAP ACLs
I hope the proposal is only addressing screen presentation format and
not putting forward we need lots of ACL types within directory
standards.
Because in theory of this sounds ok. but in practice on larger
distributed systems its really unworkable.
I tend to think of directories that have 100k+ entries and probably 10 -
15 levels of DIT. If we now say that a number of ACL forms can exist
and these forms can be applied based on User authentication processes,
ie an authenticated user can select an ACL type or the admin can select
an ACL type based on the User- and in the context of the DIB area
searched . Question - what sort of trust in the system will be there?
What happens with alias and distributed searching across 1000s of
objects with nested ACLs - what takes precedence how are these different
ACLs related?
In the standards process - and specifically for building "trust" related
mechanisms - we must seek to have one (and may be end up with two) not
build in a mechanism that isnt trusted to deal with N options that when
put together in any combination, the processes that deal with N cannot
be trusted either.
Isnt display formats of any directory object a function of the client?
regards alan
> -----Original Message-----
> From: Paul Leach [SMTP:paulle@microsoft.com]
> Sent: Wednesday, April 29, 1998 5:20 PM
> 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-----
>