You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@directory.apache.org by Ersin Er <er...@gmail.com> on 2006/06/06 10:16:11 UTC
Auxiliary objectClasses for specific subentries
Hi all,
I was looking at X.501 specification, section 14.5 about "System schema
supporting access control". It says:/
If a subentry contains prescriptive access control information, then its
objectClass attribute shall contain the value
accessControlSubentry:
accessControlSubentry OBJECT-CLASS ::= {
KIND auxiliary
ID id-sc-accessControlSubentry }
A subentry of this object class shall contain precisely one prescriptive
ACI attribute of a type consistent with the value of
the id-sc-accessControlScheme attribute of the corresponding access
control specific point.
/My question is: what's the point of /not having/ an attribute specifier
in the objectClass definition like this:
/ accessControlSubentry OBJECT-CLASS ::= {
KIND auxiliary
ID id-sc-accessControlSubentry
MUST CONTAIN {prescriptiveACI} }
/?
Thanks.
--
Ersin
Re: Auxiliary objectClasses for specific subentries
Posted by Ersin Er <er...@gmail.com>.
Ersin Er wrote:
> Well, X.500 is right. If we specify a predetermined attribute for
> Prescriptive ACI then it means we predetermine the syntax for it.
> However different schemes would likely define their own syntaxes. And
> also as I said they may even not support prescriptive ACIs.
>
> So my new question is: how will the schema system will accept this? An
> entry with an attribute which is not defined in any of its object
> classes ? With dITContentRules?
Well, prescriptiveACI is an operational attribute. So it does not need
an object class.
--
Ersin
Re: Auxiliary objectClasses for specific subentries
Posted by Ersin Er <er...@gmail.com>.
Ersin Er wrote:
> Alex Karasulu wrote:
>> Ersin Er wrote:
>>
>>
>>> Alex Karasulu wrote:
>>>
>>>
>>>> Ersin Er wrote:
>>>>
>>>>
>>>>
>>>>
>>>>> Hi all,
>>>>>
>>>>> I was looking at X.501 specification, section 14.5 about "System
>>>>> schema supporting access control". It says:/
>>>>>
>>>>> If a subentry contains prescriptive access control information, then
>>>>> its objectClass attribute shall contain the value
>>>>> accessControlSubentry:
>>>>>
>>>>> accessControlSubentry OBJECT-CLASS ::= {
>>>>> KIND auxiliary
>>>>> ID id-sc-accessControlSubentry }
>>>>>
>>>>> A subentry of this object class shall contain precisely one
>>>>> prescriptive ACI attribute of a type consistent with the value of
>>>>> the id-sc-accessControlScheme attribute of the corresponding access
>>>>> control specific point.
>>>>>
>>>>> /My question is: what's the point of /not having/ an attribute
>>>>> specifier in the objectClass definition like this:
>>>>>
>>>>> / accessControlSubentry OBJECT-CLASS ::= {
>>>>> KIND auxiliary
>>>>> ID id-sc-accessControlSubentry
>>>>> MUST CONTAIN {prescriptiveACI} }
>>>>> /?
>>>>>
>>>> Hmmm this is odd.
>>>>
>>>> I think they may be allowing for flexibility to have the access
>>>> control
>>>> scheme use it's own attribute type for the prescriptiveACI. So
>>>> perhaps
>>>> scheme xyz may use attribute abc for the prescriptiveACI atttribute
>>>> with
>>>> it's own syntax.
>>>>
>>> Yeah, this was also my guess, which does not make much sense still.
>>>
>>>
>>>> The problem here is that different schemes will introduce different
>>>> syntaxes for defining a prescriptiveACI right?
>>>>
>>> Right. Prescriptive ACI syntax depends on the scheme. (WhichI had
>>> mentioned in another mail. Had asked why we do not have
>>> accessControlScheme. Waiting for reply ;-) )
>>>
>>
>> Man I'm sorry. The response to this is we need it and I just forgot to
>> add it. There is a jira on fixing this.
>>
>>
>>>> So then the auxiliary
>>>> objectClass should not constrain the use of a specific attribute
>>>> for the
>>>> prescriptive aci. Meaning prescriptiveACI is specific to the basic
>>>> accessControlScheme so we cannot require it for all schemes.
>>>>
>>> Yeah, prescriptiveACI is specific to Basis Access Control as the
>>> accessControlScheme. However there still are gaps in my mind.
>>>
>>
>> Well this is why these guys did it the way they did IMO. They did not
>> include this prescriptiveACI atttribute int the objectClass' must list
>> because it would tie the implementation to the syntax of the basic
>> access control scheme.
>>
> Prescriptive ACI is a general term which can apply to any access
> control scheme. But I think they have thought further: An access
> control scheme can have more than one (prescriptiveACI) attribute in
> related subentries. Or even one may not support Prescriptive ACIs, but
> Entry ACIs only.
Well, X.500 is right. If we specify a predetermined attribute for
Prescriptive ACI then it means we predetermine the syntax for it.
However different schemes would likely define their own syntaxes. And
also as I said they may even not support prescriptive ACIs.
So my new question is: how will the schema system will accept this? An
entry with an attribute which is not defined in any of its object
classes ? With dITContentRules?
--
Ersin
> I had also this could be forced by dITContentRules but could not find
> a sign for it in X.501 spec. However, still seems applicable for me.
>
> (Well, I'm mad about making everything have an "explanation" based on
> their model.)
>
> So, OK. It's understood.
>
> Thanks for replies.
>
Re: Auxiliary objectClasses for specific subentries
Posted by Ersin Er <er...@gmail.com>.
Alex Karasulu wrote:
> Ersin Er wrote:
>
>
>> Alex Karasulu wrote:
>>
>>
>>> Ersin Er wrote:
>>>
>>>
>>>
>>>
>>>> Hi all,
>>>>
>>>> I was looking at X.501 specification, section 14.5 about "System
>>>> schema supporting access control". It says:/
>>>>
>>>> If a subentry contains prescriptive access control information, then
>>>> its objectClass attribute shall contain the value
>>>> accessControlSubentry:
>>>>
>>>> accessControlSubentry OBJECT-CLASS ::= {
>>>> KIND auxiliary
>>>> ID id-sc-accessControlSubentry }
>>>>
>>>> A subentry of this object class shall contain precisely one
>>>> prescriptive ACI attribute of a type consistent with the value of
>>>> the id-sc-accessControlScheme attribute of the corresponding access
>>>> control specific point.
>>>>
>>>> /My question is: what's the point of /not having/ an attribute
>>>> specifier in the objectClass definition like this:
>>>>
>>>> / accessControlSubentry OBJECT-CLASS ::= {
>>>> KIND auxiliary
>>>> ID id-sc-accessControlSubentry
>>>> MUST CONTAIN {prescriptiveACI} }
>>>> /?
>>>>
>>>>
>>> Hmmm this is odd.
>>>
>>> I think they may be allowing for flexibility to have the access control
>>> scheme use it's own attribute type for the prescriptiveACI. So perhaps
>>> scheme xyz may use attribute abc for the prescriptiveACI atttribute with
>>> it's own syntax.
>>>
>>>
>> Yeah, this was also my guess, which does not make much sense still.
>>
>>
>>> The problem here is that different schemes will introduce different
>>> syntaxes for defining a prescriptiveACI right?
>>>
>> Right. Prescriptive ACI syntax depends on the scheme. (WhichI had
>> mentioned in another mail. Had asked why we do not have
>> accessControlScheme. Waiting for reply ;-) )
>>
>
> Man I'm sorry. The response to this is we need it and I just forgot to
> add it. There is a jira on fixing this.
>
>
>>> So then the auxiliary
>>> objectClass should not constrain the use of a specific attribute for the
>>> prescriptive aci. Meaning prescriptiveACI is specific to the basic
>>> accessControlScheme so we cannot require it for all schemes.
>>>
>>>
>> Yeah, prescriptiveACI is specific to Basis Access Control as the
>> accessControlScheme. However there still are gaps in my mind.
>>
>
> Well this is why these guys did it the way they did IMO. They did not
> include this prescriptiveACI atttribute int the objectClass' must list
> because it would tie the implementation to the syntax of the basic
> access control scheme.
>
Prescriptive ACI is a general term which can apply to any access control
scheme. But I think they have thought further: An access control scheme
can have more than one (prescriptiveACI) attribute in related
subentries. Or even one may not support Prescriptive ACIs, but Entry
ACIs only.
I had also this could be forced by dITContentRules but could not find a
sign for it in X.501 spec. However, still seems applicable for me.
(Well, I'm mad about making everything have an "explanation" based on
their model.)
So, OK. It's understood.
Thanks for replies.
--
Ersin
> Alex
>
>
>
Re: Auxiliary objectClasses for specific subentries
Posted by Alex Karasulu <ao...@bellsouth.net>.
Ersin Er wrote:
> Alex Karasulu wrote:
>
>> Ersin Er wrote:
>>
>>
>>
>>> Hi all,
>>>
>>> I was looking at X.501 specification, section 14.5 about "System
>>> schema supporting access control". It says:/
>>>
>>> If a subentry contains prescriptive access control information, then
>>> its objectClass attribute shall contain the value
>>> accessControlSubentry:
>>>
>>> accessControlSubentry OBJECT-CLASS ::= {
>>> KIND auxiliary
>>> ID id-sc-accessControlSubentry }
>>>
>>> A subentry of this object class shall contain precisely one
>>> prescriptive ACI attribute of a type consistent with the value of
>>> the id-sc-accessControlScheme attribute of the corresponding access
>>> control specific point.
>>>
>>> /My question is: what's the point of /not having/ an attribute
>>> specifier in the objectClass definition like this:
>>>
>>> / accessControlSubentry OBJECT-CLASS ::= {
>>> KIND auxiliary
>>> ID id-sc-accessControlSubentry
>>> MUST CONTAIN {prescriptiveACI} }
>>> /?
>>>
>>
>>
>> Hmmm this is odd.
>>
>> I think they may be allowing for flexibility to have the access control
>> scheme use it's own attribute type for the prescriptiveACI. So perhaps
>> scheme xyz may use attribute abc for the prescriptiveACI atttribute with
>> it's own syntax.
>>
>
> Yeah, this was also my guess, which does not make much sense still.
>
>> The problem here is that different schemes will introduce different
>> syntaxes for defining a prescriptiveACI right?
>
> Right. Prescriptive ACI syntax depends on the scheme. (WhichI had
> mentioned in another mail. Had asked why we do not have
> accessControlScheme. Waiting for reply ;-) )
Man I'm sorry. The response to this is we need it and I just forgot to
add it. There is a jira on fixing this.
>> So then the auxiliary
>> objectClass should not constrain the use of a specific attribute for the
>> prescriptive aci. Meaning prescriptiveACI is specific to the basic
>> accessControlScheme so we cannot require it for all schemes.
>>
>
> Yeah, prescriptiveACI is specific to Basis Access Control as the
> accessControlScheme. However there still are gaps in my mind.
Well this is why these guys did it the way they did IMO. They did not
include this prescriptiveACI atttribute int the objectClass' must list
because it would tie the implementation to the syntax of the basic
access control scheme.
Alex
Re: Auxiliary objectClasses for specific subentries
Posted by Ersin Er <er...@gmail.com>.
Alex Karasulu wrote:
> Ersin Er wrote:
>
>
>> Hi all,
>>
>> I was looking at X.501 specification, section 14.5 about "System
>> schema supporting access control". It says:/
>>
>> If a subentry contains prescriptive access control information, then
>> its objectClass attribute shall contain the value
>> accessControlSubentry:
>>
>> accessControlSubentry OBJECT-CLASS ::= {
>> KIND auxiliary
>> ID id-sc-accessControlSubentry }
>>
>> A subentry of this object class shall contain precisely one
>> prescriptive ACI attribute of a type consistent with the value of
>> the id-sc-accessControlScheme attribute of the corresponding access
>> control specific point.
>>
>> /My question is: what's the point of /not having/ an attribute
>> specifier in the objectClass definition like this:
>>
>> / accessControlSubentry OBJECT-CLASS ::= {
>> KIND auxiliary
>> ID id-sc-accessControlSubentry
>> MUST CONTAIN {prescriptiveACI} }
>> /?
>>
>
> Hmmm this is odd.
>
> I think they may be allowing for flexibility to have the access control
> scheme use it's own attribute type for the prescriptiveACI. So perhaps
> scheme xyz may use attribute abc for the prescriptiveACI atttribute with
> it's own syntax.
>
Yeah, this was also my guess, which does not make much sense still.
> The problem here is that different schemes will introduce different
> syntaxes for defining a prescriptiveACI right?
Right. Prescriptive ACI syntax depends on the scheme. (WhichI had
mentioned in another mail. Had asked why we do not have
accessControlScheme. Waiting for reply ;-) )
> So then the auxiliary
> objectClass should not constrain the use of a specific attribute for the
> prescriptive aci. Meaning prescriptiveACI is specific to the basic
> accessControlScheme so we cannot require it for all schemes.
>
Yeah, prescriptiveACI is specific to Basis Access Control as the
accessControlScheme. However there still are gaps in my mind.
> HTH,
> Alex
Thanks for the reply.
--
Ersin
Re: Auxiliary objectClasses for specific subentries
Posted by Alex Karasulu <ao...@bellsouth.net>.
Ersin Er wrote:
> Hi all,
>
> I was looking at X.501 specification, section 14.5 about "System
> schema supporting access control". It says:/
>
> If a subentry contains prescriptive access control information, then
> its objectClass attribute shall contain the value
> accessControlSubentry:
>
> accessControlSubentry OBJECT-CLASS ::= {
> KIND auxiliary
> ID id-sc-accessControlSubentry }
>
> A subentry of this object class shall contain precisely one
> prescriptive ACI attribute of a type consistent with the value of
> the id-sc-accessControlScheme attribute of the corresponding access
> control specific point.
>
> /My question is: what's the point of /not having/ an attribute
> specifier in the objectClass definition like this:
>
> / accessControlSubentry OBJECT-CLASS ::= {
> KIND auxiliary
> ID id-sc-accessControlSubentry
> MUST CONTAIN {prescriptiveACI} }
> /?
Hmmm this is odd.
I think they may be allowing for flexibility to have the access control
scheme use it's own attribute type for the prescriptiveACI. So perhaps
scheme xyz may use attribute abc for the prescriptiveACI atttribute with
it's own syntax.
The problem here is that different schemes will introduce different
syntaxes for defining a prescriptiveACI right? So then the auxiliary
objectClass should not constrain the use of a specific attribute for the
prescriptive aci. Meaning prescriptiveACI is specific to the basic
accessControlScheme so we cannot require it for all schemes.
HTH,
Alex