Subject: Re: Comments on aci-model-04

From: "Jim Sermersheim" <[email-masked]>
Date: Wed, 20 Oct 1999 10:57:27 -0600

Could the fact that when group dnType is used, the target points to a groupOfNames be documented in the draft?  

Then I'm still lost on two related points. I'm still unsure of what constitutes a role, and I'm wondering if there's a way to specify that the target is a subtree.

Jim

>>> Ellen Stokes <[email-masked]> 10/19/99 10:51:02 PM >>>
David,
I think perhaps I didn't write myresponse clearly.  There is only
one type of group and it contains a group of names, e.g. groupOfNames object.
It is the name of the group that is typically placed on an access control
list (implementation) to state the access for the names (DNs) contained
in that group.
Ellen

At 02:25 PM 10/19/1999 +0100, David Chadwick wrote:
>
>> 
>> In implementation, group and role tend to both be implemented as a group
>> of names. However, a group is just a collection of names where the group
>> name can be used to shorthand access to some object or attribute.
>
>Ellen,
>
>This is the bit I am objecting to, i.e. the attaching of two different 
>semantics to group - one where the name of the group is a 
>shorthand for the group e.g. o=ibm,c=us, - the other where the 
>name of the group points to a group of names object where the 
>enclosed names bear no relationship to the name of the group 
>e.g.cn=ldapext, dc=netscape, dc=com.
>
>I therefore am proposing that you have two separate values for 
>dntype, to reflect the differences. Lets call them subtree and group.
>
>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 [email-masked] 
>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
>
>***************************************************
>

---

From: [email-masked]
Date: Wed, 20 Oct 1999 13:11:08 -0500

Jim,

> Could the fact that when group dnType is used, the target points to a
groupOfNames be documented in > the draft?

I think I'd prefer to simply add a statement that says group refers to an object
which holds a collection of member DNs. I don't want to restrict implementations
to using the groupOfNames objectlcass if we don't have to.  Is that enough?

> Then I'm still lost on two related points. I'm still unsure of what
constitutes a role, and I'm > > > wondering if there's a way to specify that the
target is a subtree.

We can certainly consider adding something that represents something of type
'subtree' ( vs group or access-id ).

Let me try another stab at role vs group definition. In the strict defintion,
roles and groups are both collections of DNs. So, on the surface, they are the
same. My understanding is that in the security world, there is a slight
difference; not in implemenation, but in expectation.  When a user is added to a
group that's all there is to it; he's now a member of 'Monday football
announcements' ( or whatever ). However, when the user is added to a role, there
is some expectation that he will recieve certain permissions as a member of that
role. For instance, when a user is added to an 'Adminstrator' group, (s)he would
expect to have access to particular files, queues etc. ( It is still up to the
system administrator to ensure those expectations are met )

Debbie

INet: [email-masked]
Lotus Notes : djbyrne@ibmus
Phone: (512)838-1930 ( T/L 678 )

"Jim Sermersheim" <[email-masked]> on 10/20/99 11:57:27 AM

To:   [email-masked], [email-masked]
cc:   [email-masked]
Subject:  Re: Comments on aci-model-04

Could the fact that when group dnType is used, the target points to a
groupOfNames be documented in the draft?

Then I'm still lost on two related points. I'm still unsure of what constitutes
a role, and I'm wondering if there's a way to specify that the target is a
subtree.

Jim

David,

---

From: "Jim Sermersheim" <[email-masked]>
Date: Fri, 22 Oct 1999 14:43:40 -0600

Thanks for that Bob, It helps clarify things.  It also brings up more questions, like how does an implementation express the way it handles the differences between groups and roles.  For instance, using your examples below, it's not stated anywhere that all implementations will use union semantics for groups and intersections for roles.  This all needs to be advertised for the sake of interoperability.

Now, I'm sorry for being so thick, but I'm still stuck on the kernel of the question I've been asking, and that is (to restate it a bit), what *exactly* constitutes a "collection object" as you refer to it near the end of your post. I know it's a collection of DN's, but how is it specified in the directory?  The subject DN points to some entry in the directory.  I don't know what that entry looks like, how it's constructed, how to examine its members, nor how to ensure that it's a valid collection of entries.

The kind of answer I've been waiting for is, "it's an entry which has the xxx value in its objectClass attribute", or "it's an entry and all of its subordinates in the DIT", or both.

Jim

>>> "Bob Blakley" <[email-masked]> 10/22/99 1:27:49 PM >>>
Jim

Ellen Stokes wrote:

>same.

This is correct; syntactically, the spec. does not define "groups" and
"roles" -- it
defines privilege attributes, including a "group attribute" and a "role
attribute".
Membership in a "group" confers the corresponding "group attribute" on a
subject;
occupancy of a role confers the corresponding "role attribute" on the subject.
Role attributes and group attributes are implemented as collections of DNs --
where
the DNs in the collection are those of the role occupants and group members
respectively.

>My understanding is that in the security world, there is a slight
>is some expectation that he will receive certain permissions as a member of
that
>system administrator to ensure those expectations are met )

This is also correct.

You (Jim) wrote:

>I'm still not seeing the difference (sorry). From the perspective of ACLs,
they seem the
>same to me.

Yes and no.  Syntactically, group attributes and role attributes are identical
except that
they have different types.  Both group attributes and role attributes may
appear in the
subject field of an access control list entry.  No matter which type of
attribute appears in
the subject field of an entry, the permissions field has the same type.

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:

        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).

>From reading the draft, I had the impression that the difference between
>a group and a role is that you are included in a group (by the inclusion of
your DN), and
>you identify yourself as performing a role by presenting some role based
credentials
>or something.

I guess we need to clarify this.  You authenticate yourself on the bind, and
your
group attributes and role attributes are put into your credential on the basis
of your
membership in groups and your occupancy of roles.  These memberships and
occupancies are indicated by the collection structure of the group and role
objects
in the directory.

>I didn't get the feeling that a role was represented by an object which
>contained a set of DN's.

This impression isn't correct, in my opinion -- both group *attributes* and
role *attributes* are
represented in ACL entries by DNs, and these DNs are the DNs of collection
objects

>Jim

Thanks for your comments!

--bob

Bob Blakley ([email-masked])
Chief Scientist, Dascom

---

From: "David Ward" <[email-masked]>
Date: Mon, 25 Oct 1999 14:18:42 -0600

I would like to suggest a twist to the "subtree" idea.  Instead of adding an additional identifier "subtree", the default be an object receives all the rights explicitly given to it and the rights given to objects that comprise its DN.  For example when calculating the rights for the object:

           cn=dsward, ou=engineering, ou=provo, o=novell

The rights for the object would be the sum of:

          1) explicit rights given to cn=dsward,
          2) rights for ou=engineering,
          3) rights for ou=provo,
          4) rights for o=novell
          5) rights for "public"
    
If I remember correctly, Brian Jarvis referred to this as "identity equivalence" in earlier email.  There is no need for a "subtree" identifier.  By default, I inherit all the rights given to the "parent" objects in my DN.  

From an administrative point of view this can be very powerful.  If I want to grant/deny specific rights to all objects in the ou=marketing container, I just add one aci listing ou=marketing as the subject and every subordinate object gets the rights.

David Ward
[email-masked]

>>> <[email-masked]> 10/25/99 10:01:17 AM >>>

All:

There's been several requests for the concept of an acl applying to a
subtree of DNs.

The proposal on the table is to add an additional identifier to the subject
Type : subtree. Subtree would mean that the aci entry would apply to the DN
and all descendants of that dn.
aci: 1.2.3.4#entry#grant;r;w;[all];#subtree#ou=Org,c=Country
This aci would be applicable to: ou=Org,c=Country ,   cn=Group1
,ou=Org,c=Country etc.

Including subtree, the precedence order for subject Types would be:
(Lowest- least specific) subtree - role - group - accessId ( highest - most
specific )

I don't really like using the term subtree here, since it's already been
used in the BNF. I rather use a distinct term so there isn't any confusion,
so if anyone can think of another term, please speak up.

Debbie

INet: [email-masked]

---

From: "Brian Jarvis" <[email-masked]>
Date: Tue, 26 Oct 1999 13:31:45 -0600

David,

As I understand it, the effect of the new dn-type, subtree, is to change the subject(s) of the aci from a single object (given by the dn) to an entire subtree of objects (with the given dn at the root of the subtree).  Rights issued to a container object are also given to all the descendants of that container.

As I see it there are several ways to proceed.
1.  No change.  Access-id is unchanged.  Do not define subtree as a dn-type.
2.  Add subtree as a dn-type.  Access-id is unchanged.
3.  Extend definition of Access-id.  Change definition of access-id to include the subtree.  Do not define subtree as a dn-type.

I think most of us agree that we don't want option 1.

The primary difference between options 2 and 3 is that 2 has the ability to grant rights exclusively to a container (using access-id) without giving the same rights to the subtree.  Thus 2 is more powerful than 3.

But is this power useful?  I have worked with a system similar to option 3.  My experience shows that one rarely binds as a container (ou, o, c) and thus the distinction between 2 and 3 is never utilized.  Since it is not utilized, why bother with the complication of implementing it?

Frankly, I would be happy with either 2 or 3.  I prefer 3 because I believe it to be just as useful, yet simpler to implement.

--the walrus
a.k.a. Brian Jarvis
[email-masked]

David Chadwick wrote
>> one type of group and it contains a group of names, e.g. groupOfNames
>> object. It is the name of the group that is typically placed on an access
>> control list (implementation) to state the access for the names (DNs)
>> contained in that group. Ellen

>Then I would ask that subtree be added please