Re: Comments on the ACL Model draft

[George_Robert_Blakley_III@tivoli.com]

My comments are preceded by <bb>

This is a  joint set of comments from Ryan Moats and Rick Huber.  We've
been discussing them internally for a while, so they may repeat some of
the last day's discussion on the list, but there is a fair amount of new
material here.

Rick Huber


Page 5:

EDITORIAL:

             A "subject' is an entity which initiate actions in an
                       ^                    ^^^^^^^^
             information system.

The quotes on subject don't match.  Also, "initiate" should be either
"may initiate" or "initiates".

TECHNICAL: How is a "role" really different from a "group" which
contains all of the subjects in the organizational position that the
role represents?  In Ellen's response to Dave Chadwick's questions, she
quotes Bob Blakley's previous posting on this.  Bob's posting talks
about having different semantics for combinations (union semantics vs.
intersection semantics), but the model in the draft does not seem to
allow for different merging semantics, so some of the reason to
separate roles and groups is not present.

<bb> I'm not sure I understand exactly the question here.  But let
<bb> me try again... precedence insures that either groups or roles
<bb> but not both will be used to make an access decision.  In the case
<bb> where both are present and relevant, precendence will ensure that
<bb> the decision will be based on the policy stated in the "group"
<bb> entries corresponding to the user's group memberships.  This is
<bb> in support of using groups as an exception mechanism to override
<bb> the more general policies enforced by the "role" entries.
<bb> You're correct that the current draft does not allow for
<bb> "role" entries to be combined using intersection semantics, which
<bb> is a function some people might want.  However, another way to
<bb> handle the same requirement is to ensure at credential construction time
<bb> that each user has only one role entry in his or her credential,
<bb> thus enforcing role exclusivity.  Not everyone agrees that roles
<bb> should have exclusivity semantics or intersection semantics, so
<bb> we don't want to require this -- in the future it might be good to
<bb> specify the semantics of entry combination explicitly in the ACL
<bb> but for now we've stuck with union default for all entry types
<bb> to simplify the resolution algorithm.  We'll clarify in the document
<bb> that both "group" and "role" entries are combined using union
<bb> semantics and that "group" entries and "role entries are not combined
<bb> with each other.


TECHNICAL:

             More specific policies must override less specific ones
             (e.g. individual user entry in ACI takes precedence over
              ^^^^
             group entry).

The "e.g." makes us very nervous.  There needs to be a solid definition
of what "more specific" means to avoid problems of interpretation by
different developers.


<bb> In the new draft we state the precedence rules explicitly

Also, what would happen if a DN was a member of
two groups, where one had rights while the other did not?  An example
on page 20 says to take the union of rights, but this behavior should
be specifically defined in the text, not just in an example.  Are union
semantics always used for dnTypes at the same precedence?

<bb> Yes.  This will be clarified.


--bob

Bob Blakley
Chief Scientist
Tivoli SecureWay Business Unit