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

["Ed Reed" <ED_REED@novell.com>]

At the risk of starting up this thread again, I want to put forward my take on what I think Paul is suggesting...

I believe that there are many different possible access control policies.  Many of them have their own syntax for
describing who has what rights to take which actions on various target objects.  All of them, by virtue of them
being "different" have different semantic interpretation of what ever syntax they use.

There will never be just one.  Particularly for federated, interlinked by reference, application-specific namespaces.

However, there is frequently just one for any given portion of the namespace.  That is, for the portion of the namespace
represented by a POSIX file service, the POSIX access control policy and syntax governs how the namespace may
be used and modified.  For the portion of the namespace managed by an X.500(1993) DSA having the basic
access control policy implemented and in force, that's the one that rules.  

As namespaces are partitioned, they frequently are broken up along boundaries which serve to define a portion, or partition, of the namespace under common administrative, political, or policy management.

That suggests, to me, that it's likely that the policy which governs access control can be conveniently noted in the attributes and subentries which correspond to the partition of the namespace to which they apply.  Such a policy notation can, itself, be used both by the directory server in question, and by applications who care to know, how to interpret and/or manage the policy-specific information which supports that policy on objects within the said partion.

Further, I'm not aware of ANY way to support more than one such policy for a given namespace in any general way.  Some mappings are possible on a case-by-case basis, but they're lossey, inexact (usually), and subject to severe misunderstandings and misuse when two or more administrators use two or more policy mechanism to assert their attentions on the same objects.

So - I propose that the partition roots of namespaces include a single-valued attribute which identifies the authoritative access control policy which governs that partition.  Call it an ACL Policy ID attribute for the sake of discussion.  Given the ACL Policy ID for the partition which holds an object, administrators and the DSA then know what syntax is used to store ACL information with regard to the object, and the interpretive policy to be used to make decisions over who can do what to it.  Things like Inheritance of rights, Prescriptive Rights, whether delegation is supported and how it's expressed can all be tied to the ACL Policy ID, and the mechanism for which it stands.

I'd put the ACL Policy ID as an attribute in the set of shared attributes associated with the replica agreements for the partition.

Servers unwilling or unable to support the mechanism identified by the ACL Policy ID of a partition MUST NOT hold replicas of such partitions.  Servers are welcome to hold replicas of multiple partitions, provided that ALL the mechanisms necessary to support the various partition access policies are available and in force for the replicas of the various partitions to which they apply.

References (attributes on objects with the syntax DN) to objects in other partitions MAY cross policy boundaries.  In particular, the object (A) which refers to another object (B) may be governed by one policy (P1), while object B is subject to another policy (B2).  The access and operations on each object MUST be governed SOLELY by the policy governing the respective objects.  So, operations on A are governed solely by the policy in force for the namespace in which object A is defined.  Ditto, object B and the policy for the namespace holding object B.  Such cross-partition references my not be possible, owing to conflicting or incompatible policies, and applications and services should allow for the possibility that they may not be able to be supported, and so don't count on them being there, but it's okay to use them if they are (backlinks are such a cross-partition referential integrity application use which may not be supported, but which are useful if they are).

LDAP will be used to register, and even provide referrals to, many different namespaces...some LDAP, some not.  Web servers who register with a distinguished name in LDAP are such an example, as are file volumes, print servers, routers, etc. 

That's okay.

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.

The LDAP ACL specification OUGHT to define a mechanism that all vendors CAN and MAY and maybe even MUST implement.  But it may be just one of the policy mechanisms an LDAP vendor chooses to support, or that customers choose to use.  

I meant to keep this short, so I'll stop now.

Ed

-------------------
Ed Reed, Technologist
Group Technology Office
Novell, Inc.
+1 801 861 3320

>>> "Paul Leach" <paulle@microsoft.com> 04/29/1998 01:16:37 >>>
-----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-----