RE: ACL Policy should be a property of the partition of namespace ...

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

> -----Original Message-----
> From:	Colin Robbins [SMTP:Colin.Robbins@nexor.co.uk]
> Sent:	Friday, May 08, 1998 9:29 PM
> To:	paulle@microsoft.com; ietf-ldapext@netscape.com; 'Ed Reed'
> Subject:	RE: ACL Policy should be a property of the partition of
> namespace...
> 
> Ed Reed[SMTP:ED_REED@novell.com] wrote:
> > 
> > The central point of this is to say that even if vendor A implements
> policy
> > P1 in their namespace, if vendor B can also implement that same
> policy P1,
> > then it's OKAY for replicas of an LDAP namespace to be held on both
> vendor's
> > LDAP servers, and if not, then not.
> > 
> 
> Ed,  the problem with this approach is interoperability.   What you
> will get in the market place is
> Vendor A, with Policy P1.  Vendor B, with Policy P2 etc etc.   These
> policies are then likely to become proprietary because of the "We took
> the standard and enhanced it" approach.   We already see this in
> products today with the basic LDAP v2 access protocol.
> 
> What is more, Vendor A will only release sketchy details of the
> implementation details of Policy P1, so vendor B cannot implement it
> effectively.   This means products of Vendor B cannot replicate or
> even cache data from Vendor A,  hence customers and their business
> partners get tied into a proprietary vendor community.
> 
> If you are going to build an open system, you need one, or a very
> small subset of policies, that can be agreed upon.   An unbounded
> system, does not produce interoperable solutions.
> 
> We do have one such policy today - as defined in X.500(93).
> I've seen arguments put forward that X.500 access control is too
> complex to be understood by customers etc.  I would suggest that this
> is due to bad implementation.   Gory details of access control should
> not be seen by customers - they should see an abstraction of the
> model, fitted into an overall directory management environment.   Many
> X.500 products on the market do this today - and these products
> interwork, can replicate data whilst maintaining the access policy,
> and are accessible via LDAP.
> 
> Rather than inventing yet another protocol, why don't we review the
> X.500 policy in detail.  Remove the bits that are unwanted or don't
> make sense, and add a few bits to cover any holes.
> It is always a lot easier to modify something that exists, that has
> evolved, been tested and works, than to invent from scratch.
> 
> Colin
> 
	Absolutely agree with Colin..If all the X.500 ACI is too hard
for some then profile it down - not mess the system up.  In addition
one thing that must be considered is that Users may log onto different
DSAs and expect to be mutually authenticated when their entry (with
their password) is in another DSA and then use the ACI applied to such
authentication. The LDAP approach to this is to replicate every Users
entry to everywhere (which is a BROKEN concept) but if one adds
different AC regimes to this which have to be replicated or tested by
other DSAs  --  its unworkable as well... ie.  It will be the end of
LDAP..


	regards alan