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.
