Re: DUA and access control
"peter (p.w.) whittaker" <pww@bnr.ca> Fri, 20 October 1995 19:36 UTC
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa17893;
20 Oct 95 15:36 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa17889;
20 Oct 95 15:36 EDT
Received: from haig.cs.ucl.ac.uk by CNRI.Reston.VA.US id aa17080;
20 Oct 95 15:36 EDT
Received: from bells.cs.ucl.ac.uk by haig.cs.ucl.ac.uk with local SMTP
id <g.14532-0@haig.cs.ucl.ac.uk>; Fri, 20 Oct 1995 14:32:07 +0100
Received: from x400gate.bnr.ca by bells.cs.ucl.ac.uk with Internet SMTP
id <g.19352-0@bells.cs.ucl.ac.uk>; Fri, 20 Oct 1995 14:30:15 +0100
X400-Received: by mta bnr.ca in /PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/; Relayed;
Fri, 20 Oct 1995 09:29:01 -0400
X400-Received: by /PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/; Relayed;
Fri, 20 Oct 1995 09:28:31 -0400
X400-Received: by /PRMD=bnr/ADMD=telecom.canada/C=ca/; Relayed;
Fri, 20 Oct 1995 09:28:30 -0400
X400-Received: by /PRMD=bnr/ADMD=telecom.canada/C=ca/; Relayed;
Fri, 20 Oct 1995 09:28:30 -0400
Date: Fri, 20 Oct 1995 09:28:30 -0400
X400-Originator: /dd.id=1660747/g=peter/i=pw/s=whittaker/@bnr.ca
X400-MTS-Identifier: [/PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/;
<Pine.HPP.3.91.951020084738.1256]
X400-Content-Type: P2-1984 (2)
Content-Identifier: Re: DUA and a...
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: "peter (p.w.) whittaker" <pww@bnr.ca>
Message-ID: <Pine.HPP.3.91.951020084738.12569K-100000@bwdlh591>
To: osi-ds <@bcars735:osi-ds@cs.ucl.ac.uk>
In-Reply-To: <9510191702.AA09886@atc.boeing.com>
Subject: Re: DUA and access control
X-Sender: pww@bwdlh591
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
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
- DUA and access control Steve Russert
- Re: DUA and access control peter (p.w.) whittaker