[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: Comments on aci-model-04
>
> However semantically they may be different. The underlying
> implementation of the access decision function (which looks at ACL
> entries and compares them against the subject's credentials to render
> a yes/no decision about a particular access request) may treat "group"
> entries differently from "role" entries. For example, it might
> implement "union semantics" for groups but "intersection semantics"
> for roles. Thus if an ACL contained 4 entries:
>
Bob
This is another example of the lack of precise definition that worries
me. There is too much vagary (vagueness?) in the acl model as it
stands. I have already commented previously that nowhere is it
stated which permissions are needed (i.e. which grants are needed)
for which operations, in order for them to be successfully
performed. Now we also seem to have a variable ACDF in which
different implementations use the same ACI and derive different
results. So without a fixed and clearly defined ACDF, and fixed
permissions per operation, it seems pointless to talk about
precedences of various ACIs (which we have been doing) , since
by extension, each ACDF can determine its own precedence rules.
Comments?
David
***************************************************
David Chadwick
IS Institute, University of Salford, Salford M5 4WT
Tel +44 161 295 5351 Fax +44 161 745 8169
Mobile +44 790 167 0359
Email D.W.Chadwick@salford.ac.uk
Home Page http://www.salford.ac.uk/its024/chadwick.htm
Understanding X.500 http://www.salford.ac.uk/its024/X500.htm
X.500/LDAP Seminars http://www.salford.ac.uk/its024/seminars.htm
Entrust key validation string MLJ9-DU5T-HV8J
***************************************************