Re: Comments on aci-model-04

[Bob Blakley <blakley@dascom.com>]

Jim

Ellen Stokes wrote:

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

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

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 (blakley@dascom.com)
Chief Scientist, Dascom


BEGIN:VCARD
VERSION:2.1
N:Blakley;Bob
FN:Bob Blakley
ORG:Dascom
TITLE:Chief Scientist
TEL;WORK;VOICE:+1 (512) 458-4037 x 5012
TEL;WORK;FAX:+1 (512) 458-2377
ADR;WORK;ENCODING=QUOTED-PRINTABLE:;;Plaza Balcones=0D=0A5515 Balcones Drive;Austin;TX;78731;USA
LABEL;WORK;ENCODING=QUOTED-PRINTABLE:Plaza Balcones=0D=0A5515 Balcones Drive=0D=0AAustin, TX 78731=0D=0AUSA
URL:
URL:http://www.dascom.com
EMAIL;PREF;INTERNET:blakley@dascom.com
REV:19991022T192748Z
END:VCARD