directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ersin Er <ersin...@gmail.com>
Subject Re: Auxiliary objectClasses for specific subentries
Date Wed, 07 Jun 2006 08:05:42 GMT
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.
>


Mime
View raw message