RE: LDAP ACLs

[Alan Lloyd <Alan.Lloyd@OpenDirectory.com.au>]

Hello - thank you for the comment and whilst appreciating that Msoft
have a strong position in the market place and they can do want they
want - here are my thoughts.

> -----Original Message-----
> From:	Paul Leach [SMTP:paulle@microsoft.com]
> Sent:	Tuesday, May 05, 1998 12:12 PM
> To:	Alan Lloyd; ietf-ldapext@netscape.com
> Subject:	Re: LDAP ACLs
> 
> >> 
> > Yes - perhaps the industry does - but there is no need to
> >institutionalise that fact with confusing standards and apply them in
> >every directory implementation. The directory ACL/I standard is to
> >provide portability of ACI information between systems and the
> ability
> >to provide a common Authentication/ ACI policy across a number of
> >interconnected servers(DSAs). 
> 
> Excuse me, those were IETF ACL standards for "single ACL model" I was
> talking about. So we've already lost portability.
> 
	Well some vendors have got a mix of ACLs for all sorts - but I
thought this list was directory related and dealing with "serious"
international directory standards of which there is only one and one ACI
model worth speaking of and that is the X.500 ACI - authentication
model.
	And because there is only one - that has an admin management
model, can dominate subtrees of entries, ditto with DSAs, etc, can be
nested, does have precedence levels, can be transferred in DOP for
distributed DSAs or transferred in DISP with replicated information and
seems to cover the 5 dimensional space of authentication and access
controls, most think that model should be it.

> >
> > Does it not follow that as we evolve to X.509 based systems for
> >authentication and signatures and these are applied to ACI models
> >(otherwise how does ACI work if one cannot verify the user) and the
> fact
> >that people are mobile and want to acccess a DSA system from anywhere
> - -
> >that ACI needs to be consistent just like X.509 authentication
> >processes.
> 
> Not at all. I, as a client, can access a DSA system from anywhere as
> long as I can authenticate. I do not need to be able to manage ACLs to
> be able to do that.
> 
	Of course not - I think the world knows that Users dont manage
ACLs - its admin and ops staff - and system policy people - and they
just love 20 ACL types across a pile of intermingled schema.... I think
not.

	WE promote our DSA because of its ACL compliance to X.500 -
which is over arched with set of human usable policy/profiles - that
permit ops people to configure 1 - 20,000,000 entries in a distributed
environment with a set of ACLs for admin user, named users, own entry,
groups, anon users etc in about.... a few minutes.

	I work a bit with military and one thing they do is deploy
assets - eg ships, tanks and mail hubs, directories - and they need to
do this fast. I have seen heard  of some (entry level ACL configured)
directories where the theoretical acl configuration time for 250,000
entries would be one man year! Lets add a few ACL models to this - and
what does one get. The LDAP Configuration Army to feed and the risk of
an information mess.... in about a year!

	If one is promoting a multiple ACL model - it might pay to do
some trivial, simple or lightweight Human Factors Engineering tests on
it. 

	The draft LDAP ACL document that was circulated - read it and
stand back and ask - how long to configure on a big system and then ask
what are the holes in it in terms of trust, being technically viable,
scaleable  and operationally deployable......And the answer is - not in
our products to our customers and thats because we care about both.

	regards alan
	 

> - -------------------
> 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
> 
> iQCVAwUBNU51dcqlCdSXiCndAQFwAgP9F6DdohLxQrmIa34EevdxSB1xGFHEIaKU
> 0a6GLFT5iKBf6A1ffWYuJlTY8hyKF6yTJVSC36uAXC37zU773/IQWQpIp1Dr+EdT
> T1JtN60HaJ3TuTB05aLF/F6aMKfTwpKni6NsYypIjIWoCaT5XT+7xybhFKsPQQGz
> RNcShQvkOWo=
> =lUGq
> -----END PGP SIGNATURE-----
>