Re: Fwd: Re: please publish (draft-ietf-ldapext-acl-model-05.txt)

[George_Robert_Blakley_III@tivoli.com]

Comments prefaced by <bb> below.

> > >ii) I made a comment on 04 about ReadDN that I don't believe has been
> > >addressed yet. There is a difference between letting someone have
> > >access to an entry they know exists, and ones they don't know exist.
> > >I.e. there is a difference in permissions needed for the base object
> > >of a Search and the entries beneath the base object (the latter is a
> > >greater permission than the former). At the moment BrowseDN gives the
> > >latter permission, but there is not the lesser permission of
> > >accessing an entry whose name you already know. This would call for a
> > >ReadDN permission I believe. Comments please on this.
> >
> > (EJS) BrowseDN is ReadDN.
>
>I know that. What I was saying is that there is not a lesser
>permission than BrowseDN that only allows a read if you know the
>name beforehand. (Consider web access for example. There are
>many web pages that you can only access if you know the URL
>beforehand, but cannot browse to look for them)
>
> >BrowseDN allows that DN in a search.  This
> > allows someone access to only information that he has been authorized
> > for.  A person may know that an entry exists, but just because he does
> > have that knowledge does not mean he can access it.  Likewise, if a
> > person doesn't know an entry exists doesn't mean that he should be
> > able to discover it.
>
>Agreed, but you do not currently have a way of allowing someone to
>access something they know exists and not have access to
>something they dont know exists. This is what I am suggesting
>should be added.

<bb> We could call this the "GuessDN" permission -- if you correctly guess
<bb> a DN, then the entry whose name you've guessed is returned.  If on
<bb> the other hand, you're sitting at the same entry's superior entry
<bb> and you have BrowseDN permission but don't know the DN of the entry
<bb> you're looking for, your Browse attempt will not return the entry.
<bb> Hmmmmmm......  I don't know if I like this or not -- need to see
<bb> a compelling example of a problem this lets me solve.

< djb > Currently, the "BrowseDN" permission works as follows:
1. If you know the entry, and have browse permission, the DN can be returned
2. If you know the entry, and do not have browse permission, the DN is not
returned.
3. If you have browse permission on the entry, the DN can be returned,
*regardless*
     of whether you have browse permission on all ancestors.

I think case number 3 solves the web URL problem you mention above.

> > >iii) Precedence of privilege dnTypes. I would argue that role comes
> > >higher than group as it is more specific. By this I mean that group
> > >membership is usually conferred on more people than are roles (and as
> > >you said in October, roles can be regarded as groups with
> > >permissions). I would expect my role of abc administrator to have
> > >more weight than simply a member of the IETF LDAP group.
> >
> > The following is a cut and paste from Bob Blakley's reasoning in his
> > prior email on the precedence stated in this current draft.
> >
> > 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:
> >
> > group1 : grant (read, search)
> > group2 : grant (update)
> > role1 : grant (read, search)
> > role2 : grant (update)
> >
> > A subject belonging to group1 and group2 would be granted access
> > (because union semantics grants access if any group grants access),
> > but a subject belonging to role1 and role2 would be denied access
> > (because intersection semantics grants access only if all roles grant
> > access).
> >
> > This ability to distinguish groups and roles semantically is
> > important. It permits security administrators to have two different
> > subject collection constructs with different granularities and
> > different dynamism.  Roles (not role attributes -- actual roles) are
> > typically defined at a fairly high organizational level and changed
> > infrequently. The authorizations granted to role attributes mirror the
> > organizational responsibilities associated with the roles.
> >
> > However in modern organizations roles don't describe the "entire job"
> > of an individual -- the VP of marketing may be assigned (for a short
> > time) to a task force evaluating the technical competitiveness of a
> > product. To participate in this activity, she may need access to
> > engineering data to which her job role (or roles) as marketing VP
> > don't entitle her. The CFO and the East Region Helpdesk Director may
> > also be on the taskforce, and may need access to the same data. To
> > grant the desired access to all three of these individuals, it would
> > be possible to individually authorize them to the data -- but this
> > would be bad for several reasons. The first is scale -- for three
> > people this would be feasible, but for 30 it would be unpleasant, and
> > for 3000 it would be impractical (especially in organizations which
> > run lots of task forces or have lots of matrix management). The second
> > is that if you simply put individual entries on the ACL, you might
> > forget who the individuals are and why they're on the ACL. In this
> > case you'd very likely forget to take them off the ACL when the task
> > force ended, thus creating a need-to-know violation.
> >
> > On the other hand, defining a new "role" for the task force is bad
> > also: task force membership isn't really a role; it's really an
> > assignment. Adding lots of roles to the role namespace pollutes the
> > policy environment and makes it very difficult for the enterprise
> > policy administrators, whose job is defining work roles and their
> > proper authorizations, to do their work.
> >
> > What's really called for is defining a "group" -- an ad-hoc collection
> > of users who can be authorized to the specific set of resources for
> > the duration of the project as an *exception* to the role-based
> > policy. The group should be given an evocative name (like the name of
> > the project) and should be authorized to the resource. When the
> > project ends, the group can be deleted, and its entries can be removed
> > from the associated resource ACLs.
> >
> > As this example suggests, in order to support using groups as
> > exceptions to roles, group attributes and role attributes need to have
> > different precedence. As the example also suggests, I think groups
> > should have *higher* precedence than roles, since roles are
> > essentially a coarse-grained, static, subject collection,  and groups
> > are a fine-grained, dynamic subject collection.
> >
> > Note that many existing security models, including ISO, ECMA-138,
> > CORBA, and others include both groups and roles (and type-distinguish
> > the two).
>
>I follow this and agree with the example as far as it goes, but fail to
>see how the example supports the case for multiple role permissions
>to be intersection and not union, which appeared to be the rationale
>for the example, did it not? Also Bob has not said how role and
>group should combine together - would it be union or intersection? If
>it were union, then the precedence of group could be below role and
>his example would still work, would it not? Therefore can Bob explain
>why the example is arguing for group above role.

<bb> As I said in my earlier note, we don't propose (in this version of the
draft) to provide support
<bb> for using an intersection combinator for roles -- just as with groups we
use union here and assume
<bb> that if you want exclusivity you will insure at credential acquistion time
that only one role attribute
<bb> is in the user's credential.

<bb> Roles & groups aren't combined -- dnType precendence insures that groups
are used where
<bb> present and relevant; roles are used if groups aren't present or relevant.

<bb> Strict union for groups & roles together wouldn't work, because "deny" for
a role and conflicting
<bb> "grant" for a group would result in "deny" -- a violation of group
precendence over role.

--bob

Bob Blakley
Chief Scientist
Tivoli SecureWay Business Unit