Mailing-List: contact dev-help@directory.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Apache Directory Developers List" <dev@directory.apache.org>
Received-SPF: pass (asf.osuosl.org: domain of aok123@bellsouth.net designates
 205.152.59.64 as permitted sender)
Message-ID: <4485989E.1020100@bellsouth.net>
Date: Tue, 06 Jun 2006 11:00:46 -0400
From: Alex Karasulu <aok123@bellsouth.net>
User-Agent: Mozilla Thunderbird 1.0.8 (X11/20060502)
MIME-Version: 1.0
To: Apache Directory Developers List <dev@directory.apache.org>
Subject: Re: Auxiliary objectClasses for specific subentries
References: <448539CB.2080207@gmail.com> <4485964F.7050908@bellsouth.net>
 <44855F16.4010001@gmail.com>
In-Reply-To: <44855F16.4010001@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

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