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

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

The only thing missing is how does an authenticated user work across
such scenarios and what are the configuration overheads re replication
and human resources

	It strikes me there is a case for a single standard that applies
to authentication and access control regimes.

	As a point - we as standards developers,  should we not try to
get open, interoperability  with the maximum integrity from information
protection regimes and the lowest burn on customer human resource ? That
way we can define and build trusted systems.


regards alan

> -----Original Message-----
> From:	Ed Reed [SMTP:ED_REED@novell.com]
> Sent:	Saturday, May 09, 1998 8:19 AM
> To:	paulle@microsoft.com; Colin.Robbins@nexor.co.uk
> Cc:	ietf-ldapext@netscape.com
> Subject:	Re: ACL Policy should be a property of the partition
> ofnamespace...
> 
> You are, of course, both right.
> 
> Many mechanisms do exist, and many of them want to be front-ended by
> LDAP responders.  Several of them would like to be replicable among
> other LDAP servers.  It's that last bit that I was addressing.
> 
> Scenario 1:  different mechanisms, different namespaces, federation
> limited to referrals, without replication - no problem, provided the
> policy mechanism is "known" to clients and servers who know about
> them, manage them, or know how to use them.
> 
> Scenario 2: different mechanisms, same namespace - big problem, since
> a policy administrator can't know whether the policy will be enforced
> when data are replicated to a server which doesn't know how to deal
> with the policy mechanism the administrator set.  This is the case
> which we've got to figure out how to work around.
> 
> Scenario 3: different mechanisms, same namespace, with fractional
> and/or sparse replication of attributes/objects, such that Server A
> won't send things to Server B which are subject to some policy
> mechanism that A knows about, but B doesnt.  This requires a mapping
> to be performed, perhaps algorithmically, probably manually, and for
> that to be known in the replica agreement.  This will probably be one
> of the more frequent causes for the use of fractional and sparse
> replicas.
> 
> Scenario 4: single mechanism, different namespaces - doesn't compute
> for the reason Paul mentions - multiple non-mappable,
> non-interoperable mechanisms already exist, and they DO want to be
> replicated among LDAP servers.  That suggests to me that a canonical
> mapping of each could be documented by the respective mechanism
> champions, published, and be used as the mapping mechanism, where
> possible, described in scenario 3 - either by mapping operations onto
> the canonical LDAP baseline, or by specifying that attributes/objects
> requiring protection which is not available in the LDAP baseline
> should / must not be replicated to a server which only supports the
> LDAP baseline.
> 
> any other possible scenarios anyone can think of?
> 
> Ed
> 
> -------------------
> Ed Reed, Technologist
> Group Technology Office
> Novell, Inc.
> +1 801 861 3320
> 
> >>> "Paul Leach" <paulle@microsoft.com> 05/08/1998 11:11:30 >>>
> -----BEGIN PGP SIGNED MESSAGE-----
> 
> You're forgetting something -- the other policies _already exist_.
> Acknowledging that fact, and making the allocation of policy ID
> codepoints dependent on a specification of the formats used by the
> policy, then you have a lever to encourage specification and hence
> interoperability. Ignoring it can only be worse.
> 
> The marketplace will take care of insuring that there are only a small
> number of relevant policies.
> - ---------------------
> 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
> 
> iQCVAwUBNVM8lsqlCdSXiCndAQE0MwQAhTkmi6sc1B7KocedL/5MgcP6NsQ0iDvl
> K5NkYGWtl+inHQiNFZANemYYuWncv81Exzunsg+2a/gg/1s0O29nfl1exK9EvYCV
> VYX24cdrWdpOQU097N06Sw7yDIcUo/xRAtmuP+JSKKpsvUYzQP3pwnEfQ41glPOf
> POPrrkzsQ/c=
> =yifo
> -----END PGP SIGNATURE-----
> 
>