Re: Summary of ACL discussion and proposal

Paul,

> I think that we've been mostly talking about 3 things, which are related but
> which it might be better to tease apart and try to consider separately, and
> which I'll try to summarize.
>
> 1. Principal IDs should be more than user ID; in particular, they should be
> able to include location from where the access came.
> 2. The specification of an "accessor" in an ACE should be opaque, system
> specific things (lets call them "OIDs" for short), and new functions are
> needed to convert between OIDs and principal IDs.
> 3. The specification of which principals an ACE grants rights to should be
> more flexible and powerful than just a single principal ID (or OID); lets
> call it a "principal specification" after Howard's suggestion. I.e,
> conceptually, there is a function
>         bool IsMatchingPrincipal(principal-spec, principal-ID)
> which, given a principal ID and a principal specifier, tells whether the
> principal matches it.
>
> In order to enable us to flush out further issues, I would make the
> following proposal:
> 1. I will make the spec agnostic on the subject of issue #1. Actually, it
> already is, but I'll make it clear that it is.

I assume you're talking about the protocol spec.  I'm still trying to come up
with a description of the access control model for the requirements spec.
Perhaps you can split out the protocol design-independent part of your
description of the model, and that can go in the requirements to replace the
existing section 4.

> 2. I will make the spec 99% agnostic on the subject of issue #3. I.e., in
> the spec for an ACE, I'll make it refer to "principal specifier" instead of
> "principal ID"; but _for now_ the only form of principal specifier will be a
> simple principal ID. This will be isolated to one place, where we can
> upgrade it if/when we come to concensus on changing it. But at least it will
> be a separable discussion.

Issues 1 and 3 seem to be essentially the same issue to me.  It's a little
confusing because "principal ID" is getting overloaded.  But if the principal
specifier can specify constraints on more than just a "simple principal ID",
then the "state against which the principal specifier is evaluated" (principal
ID?) needs to be defined to include whatever additional attributes can appear in
the principal specifier.  For the requirements, we really need to pin down what
the requirement(s) is(are):

1.  Can new principal attributes be defined and used in the principal specifier?

2.  What form does the principal specifier take?
     a.  A list of simple principal IDs?
     b. A single principal attribute name and a pattern to match values of that
attribute?
     c. A list of (principal attribute name, principal attribute value pattern)
pairs?
         i. Evaluated as AND?
         ii. Evaluated as OR?
     d. A boolean expression of (principal attribute name, value pattern) terms?

     e. Some extensible form?

3.  What principal attributes are required?
     a. Simple principal ID (e.g. user ID and maybe group ID)?
     b. DNS name?
     c. IP address?
     d. Other?


> 3. Table issue #2 until there is a requirements specification for it.

Let me try to recast issue #2 more in terms of basic requirements.  Let's talk
specifically about how user identities (conceptually represented by user
objects) are conveyed over the wire.  On the client side there is a need for a
user to be able to identify users to whom access control is to be applied.  If
the client is able to communicate with a directory containing the users (is
directory-capable), it may provide a GUI which allows the user to perform
searches of the directory, and select user identifies from the search results.
Chances are good that the directory will have some way to uniquely identify a
user in the directory.  For example, an LDAP directory might use an ldap: URL.
So the client might actually specify user identities in the access control
protocol by using their directory "handles".  Likewise, if the server sends
directory handles to such a client, it can look these up and retrieve whatever
information it chooses to display about the referenced users.

On the other hand, the client may not be directory-capable, or the server may
not use a directory that can be accessed directly by the client.  For example,
the client may only be able to send text that the user types in to specify a
user identity, and only display whatever text the server sends to identify a
user.  The server would have to be able to parse the text typed in at the
client, and relate it to a unique user identity, and it would have to send user
identities to the client in a form that was suitable for presentation.

In each of these two cases, the client and the server must both have some
inkling of whether user identities are expressed in "presentation form" or in
"directory handle form", and if the latter, what kind of directory handle is
being used, including perhaps a reference to the directory server.  I think that
at a minimum, we should require that "presentation form" be supported and
explicitly identified in the protocol as such.  We could stop there, but provide
the capability to define and specify additional forms.  Or we could (boldly) go
a step further and specify something like "LDAP URL form" as well.

Assuming that we decide to support more than simple lists of distinct user
identities in the principal specifier, the nature of user specifications in the
protocol would need to include a way to specify patterns which might match
several users.  For example, presentation form might allow regular expressions
as a pattern, or directory-handle form might express patterns as a directory
query.  I think the requirements spec should take some kind of stand on this as
well.

As I see it, if we don't specify something about the form of a user identity in
the protocol, there can no assurance that clients and servers from different
sources will be able to interoperate with respect to access control.

[And similarly for any other form of "simple principal ID" that we decide
specify, such as group ID.]

This is a change in my previous position, which was that user IDs (simple
principal IDs) could be opaque as long as they were in some canonical form, and
the protocol provided operations to retrieve a presentation form.  Having
thought about that some more, I've concluded that it would ultimately amount to
reinventing a standard directory protocol between the client and server.  And if
the client is going to be able to speak some directory protocol, then why not
just use LDAP, and why restrict it to the server?

Howard

Received on Monday, 27 October 1997 05:42:02 UTC