[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: Management domains and access controls
Bob wrote:
> You're correct; this is different, and you've correctly described the
> difference (though I could quibble and say that in X.500, the subentry in
> the administrative point explicitly defines its relationship to the naming
> context, rather than that there's no relationship...)
>
No I dont believe you are correct Bob, The subentry is in reality part
of the administrative point, but because of the "grouping of
attributes" problem (see my ID on families of entries) it was made
into a separate subentry. But there is no explicit relationship that I
am aware of between an administrative point and a naming context
prefix. Nor between a subentry and a naming context. The subtree
specification in a subentry points to a subtree of the DIT, not a
subtree of a naming context. Hope that clarifies things
> So, for example, an X.500 directory acting as an LDAP
> server is free to
>
> (1) receive a policy command which directs it to apply a particular
> access
> control policy to a particular subtree
> (2) express that policy command in the X.500 policy language
> (including
> for example explicit denial)
> (3) Store the resulting policy language expression anywhere it wants
> (for
> example, in a subentry in a node *above* the context prefix of the
> naming
> context.
>
>
Let me try to interpret this I read it. The sender, who applies a policy
to the DIT (not to a naming context e.g. say he is the security
administrator for large multinational with many servers e.g. ibm),
must decompose the policy into that bit that applies to the naming
context of the receiving server, and send just that to it. The policy
must likewise be decomposed for every server that it is being sent
to. Is this correct? In other words, the administrator cannot send a
policy for o=ibm to a server that holds o=ibm, ou=sales. It must take
the subset of the policy that applies to o=ibm, ou=sales.
With X.500 the administrator will send the o=ibm policy to every
server regardless of the portion of the ibm namespace that it holds. I
think this is perhaps a difference between the models
David
>
> --bob
>
> Bob Blakley (blakley@dascom.com)
> Chief Scientist, Dascom
> -----Original Message-----
> From: David Chadwick <d.w.chadwick@iti.salford.ac.uk>
> To: djbyrne@us.ibm.com <djbyrne@us.ibm.com>; ietf-ldapext@netscape.com
> <ietf-ldapext@netscape.com> Cc: Ellen Stokes <stokes@austin.ibm.com>; Bob
> Blakley <blakley@dascom.com> Date: Thursday, April 29, 1999 5:08 AM
> Subject: Re: Management domains and access controls
>
>
> From: djbyrne@us.ibm.com
> To: d.w.chadwick@iti.salford.ac.uk
> Copies to: Ellen Stokes <stokes@austin.ibm.com>, "Bob Blakley"
> <blakley@dascom.com>
> Date sent: Wed, 28 Apr 1999 15:19:43 -0500
> Subject: Re: Management domains and access controls
>
>
>
>
> David
>
> > Debbie
> >
> > INet: djbyrne@us.ibm.com
> > Lotus Notes : djbyrne@ibmus
> > Phone: (512)838-1930 ( T/L 678 )
> >
> >
> >
> ***************************************************
>
> David Chadwick
> IT Institute, University of Salford, Salford M5 4WT
> Tel +44 161 295 5351 Fax +44 161 745 8169
> *NEW* Mobile +44 790 167 0359 *NEW*
> Email D.W.Chadwick@iti.salford.ac.uk
> Home Page http://www.salford.ac.uk/its024/chadwick.htm
> Understanding X.500 http://www.salford.ac.uk/its024/X500.htm
> X.500/LDAP Seminars http://www.salford.ac.uk/its024/seminars.htm
> Entrust key validation string MLJ9-DU5T-HV8J
>
> ***************************************************
>
>
***************************************************
David Chadwick
IT Institute, University of Salford, Salford M5 4WT
Tel +44 161 295 5351 Fax +44 161 745 8169
*NEW* Mobile +44 790 167 0359 *NEW*
Email D.W.Chadwick@iti.salford.ac.uk
Home Page http://www.salford.ac.uk/its024/chadwick.htm
Understanding X.500 http://www.salford.ac.uk/its024/X500.htm
X.500/LDAP Seminars http://www.salford.ac.uk/its024/seminars.htm
Entrust key validation string MLJ9-DU5T-HV8J
***************************************************