[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: Management domains and access controls



David,

>> 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

A bit; I'm quite confident on issues of naming like this that your
judgement is much better than mine, and I appreciate the reply.

>>  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.

I don't really think this is right; the code on the LDAP server which receives
an administrative command should be able to figure out whether the
subtree specified in the policy contains its naming context and behave
appropriately.

>The policy
>must likewise be decomposed for every server that it is being sent
>to. Is this correct?

Again, I think this can be handled on the server side in many cases.

>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.

Again, not necessarily... a server which holds o=ibm, ou=sales should be
able to interpret and apply the o=ibm policy if the bit indicating that
it applies to an entire subtree is set.

What you *can't* do in the LDAP model is specify a policy which applies
to a subset of the nodes in a subtree - as you *can* do in X.500 as I
understand it.

>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

--bob

Bob Blakley (blakley@dascom.com)
Chief Scientist, Dascom




BEGIN:VCARD
VERSION:2.1
N:Blakley;Bob
FN:Bob Blakley
ORG:Dascom
TITLE:Chief Scientist
TEL;WORK;VOICE:+1 (512) 458-4037 x 5012
TEL;WORK;FAX:+1 (512) 458-2377
ADR;WORK;ENCODING=QUOTED-PRINTABLE:;;Plaza Balcones=0D=0A5515 Balcones Drive;Austin;TX;78731;USA
LABEL;WORK;ENCODING=QUOTED-PRINTABLE:Plaza Balcones=0D=0A5515 Balcones Drive=0D=0AAustin, TX 78731=0D=0AUSA
URL:
URL:http://www.dascom.com
EMAIL;PREF;INTERNET:blakley@dascom.com
REV:19990517T220032Z
END:VCARD