Re: DUA and access control

["peter (p.w.) whittaker" <[e-mail]>]

On Thu, 19 Oct 1995 srussert%atc.boeing.com@bcars735 wrote:
>Is it reasonable to classify DUA implementations by access control
>scheme?

No.  Access controls are implemented by DSAs in order to provide the ACI
services defined by X.500 and required by data owners and Direcory
administrators.  ACI evaluation happens at the DSA when a user attempts
to access particular data elements (particular entries, attributes, or
attribute values).  As such, ACIs never "leave" the DSA.  (They are
written to and read from DSAs just like other attributes, subject to
evaluation of the ACDF; see below).

DUAs do not implement access controls.  DUAs can be used to read and
write access control information (ACI) from and to the DIT, pending
appropriate privileges, just as they are used to read and write any
other attributes.  The DUA accesses the DIT on behalf of a particular
user; each DSA contacted to satisfy that user's request then decides how
to respond to that request based on the ACIs which pertain to that user.

>I have looked at the DAP bind in x.511 and the contract and packages in
>x.519, and cannot see where information about access control would be
>conveyed.  What bothers me is that it seems that DSAs would want to know
>about the access control used by another DSA, and I don't see a place in
>DSP, either.  Can anyone provide pointers on this?

ACIs are written to the DIT just like any other attribute:  a
sufficiently privileged user writes entryACI attributes to particular
entries, or prescriptiveACI attributes to particular subentries.  As
with all writes, the write is done at the master DSA.

ACIs are read from the DIT just like any other attribute:  sufficiently
privileged users can read the entryACI or prescriptiveACI from the
appropriate entries.

Ergo, as far as writing and reading are concerned, ACIs are conveyed via
the DAP and DSP just like any other attributes; also, ACIs are conveyed
in the DISP, and shadow consumers must enforce the ACIs so conveyed
(i.e., a shadow consumer must enforce the ACIs for particular entries,
attributes, or values, just as the master DSA would).

The catch when reasing ACIs, of course, is the term "sufficiently
privileged":  in order to read an entryACI, you must be able to browse
to that entry, read that entry, and read the entryACI attribute, which
means that you must have been granted those permissions via an
appropriate set of prescriptiveACI and entryACI attributes, based on the
credentials you presented when you bound to the Directory.

If a user is not permitted to read a particular entry (or even to know
that it exists) then they cannot read that entry's entryACI (which makes
perfect sense, when you think about it :->).

However, I suspect that this is not what was being asked about.

I think that the real question might have been:  how can a DUA or
*other* DSA determine the full set of ACIs which will be used in the
ACDF (access control decision function) when deciding whether a
particular user can access a particular entry, attribute, or value?

The short answer is "They cannot".  The more complete answer is "Any
sufficiently priviliged user can browse the DIT and read all ACIs that
pertain to particular entries, attributes, or values".  Again, the catch
is the term "sufficiently privileged".

It is worth bearing in mind that a DSA has access to all data in its
naming context, and is not subject to ACIs; the DSA uses ACIs to
determine how to respond to particular use requests (i.e., no such
object, insufficient access rights, partial response, complete response,
etc.).  DSAs have zero knowledge of ACIs in effect in other naming
contexts (i.e.  naming contexts which they neither master nor shadow).

The only entity which has complete access to ACIs and which is not
subject to the ACDF is the DSA itself (and any shadow consumers of that
DSA's complete naming context); as mentioned, ACIs only apply to users,
not DSAs, and are used by DSAs to determine each user's access rights.

It is also worth bearing in mind that ACIs were designed so that the
ACDF could be carried out entirely locally:  when a DSA decides a user's
access rights, they do so with local data and do not need to consult
other DSAs.  Note that there is no mechanism for a DSA to initiate a
read from another DSA:  DSAs only contact other DSAs as part of working
on a user's request; in other words, the user initiates a read operation
which may involve multiple DSAs, and the DSAs will chain the request as
necessary, service controls and knowledge references permitting.

Thus, it makes no sense to ask how a DUA or DSA determines the ACIs in
effect at a particular DSA; ACIs are "just another attribute type", and
are treated just like any other attribute.  The only difference is that
ACIs, like contexts (see the upcoming X.500 1996), determine how a DSA
responds to particular requests.

(It would be useful for the DSA manager to have a tool which determined
the complete set of ACIs pertaining to any particular entry, attribute,
or value, and which presented that information in a manner analogous to
how the ACDF is evaluated, in order to assist users in determining
whether or not they in fact have appropriate access rights.
Implementation of this tool is left to the discretion of the X.500
vendors.)

pww