Subject: [I2nsf] Post 3: Differentiating between Groups and Roles

From: John Strassner <[email-masked]>
Date: Sat, 19 Dec 2015 23:39:28 -0800

During IETF94, I expressed discomfort with the
"Subject-Object-Action-Function" paradigm. This note defines and
differentiates between the concepts of groups and roles.

1.  Motivation

There are several places in draft-merged-i2nsf-framework-04 that treat
groups and roles as the same. I feel that this is incorrect. For example:

   "However, the notion of Groups (or roles), ..."
   "Composite Groups or Roles (I2NSF-Role)...This is a group of..."

There are also places where role is used (correctly imho) but which
contradict the implied equivalence of groups and roles, such as:

   "to reflect the different roles that each vNSF is designated for"
2.  Definitions

The mathematical treatment of groups is important, as it more clearly
differentiates groups from roles.

2.1.  Group

A group is a set of elements.

Mathematically, a group G is defined with an operation O. When O is applied
to any two elements of the group, a and b, the result is a third element c,
that is part of G. More specifically, G and O must satisfy the following
four axioms:
   - Closure:        For all a, b in G, a O b is also in G
   - Associativity: For all a, b, c in G, (a O b) O c = a O (b O c)
   - Identity:        There exists an element e in G such that e O a = a O
e = a
   - Inverse:        For any element a in G, there exists an element b in G,
                          such that a O b = b O a = e (the identity element)

2.2.  Role

In software engineering, a role is defined as a responsibility that an
object has. Since a responsibility may be complex, the responsibility is
represented as an object. This has the additional advantage of making it
reusable.

For example, in a business, it is common to group people into a number of
different roles. A role may be restricted by context (e.g., by time,
location, or other factors). An object may be able to combine roles
(technically called a role combination), such as an EmployeeRole AND a
SupportDeskRole AND a ManagerRole. If this is done, then it is important to
ensure that the responsibilities of the roles in the role-combination do
not conflict with each other (e.g., if an Employee submits a travel
document for reimbursement, then that same Employee MUST NOT be able to
sign the same document; more formally, this is called separation of
privileges, and the Principle of Least Privilege is often a cornerstone of
security implementations [2]).

2.3.  Role-Object Pattern

This is a fundamental design pattern, and is described more thoroughly in
[1]. Its purpose is to adapt an object O to the needs of different clients
through a set of transparently attached role objects R. In this approach,
each role object R represents a role that O has to play in that particular
client's context.

The key feature in this simple design pattern is the use of **context**.
For example, a user may have multiple roles (i.e., responsibilities)
assigned, such as an engineer and a manager. Each role may have different
permissions, and in general, roles may or may not be allowed to be
used concurrently. This pattern models context-specific functionality of an
object O as a set of role objects R that can be dynamically attached to,
and removed from, the object O. This allows the combination of O and R to
be viewed as an **aggregate object** that represents **one** logical object
(even though it consists of multiple separate objects). In UML, this is
represented as an **aggregation**.

Visually, the pattern looks like this:

  +--------+   HasRoles  +------+
  | Object |<>---------->| Role |
  +--------+1..1     0..n+------+

where the HasRoles relationship is an aggregation. Its multiplicity means
that an Object may have zero or more Roles, but each Role is defines for
that particular object. In this design, the Role class is subclassed to
define the different types of Roles that this object can play. The
aggregation then enables zero or more of these roles to be selected based
on context.

3.  Why Group Is NOT The Same As Role

Looking at the definitions above, a Group is "just" a set. Furthermore,
there are specific properties of a Group that guarantee a set of behaviors
that characterize group operation.

In stark contrast, a Role has nothing to do with sets. A role represents a
single responsibility that the object has. Roles are, of course, related to
the object that aggregates them, but the concepts of closure, identity, and
inverse are not applicable. More importantly, the concept of associativity
is NOT true, as this can lead to privilege violation.

4. Using Groups and Roles

Since these are different concepts, they can be easily combined. Consider
the following UML diagram:

        +----------------------+
        | PersonOrOrganization |
        +----------+-----------+
                  / \
                   I
                   I
          +--------+-------------------+
          I                            I
          I                            I
  +-------+------+   HasPeople  +------+-------+
  |              |<>----------->|              |
  | Organization |              |    Person    |
  |              |              |              |
  +---+------+---+              +--+--------+--+
      I     / \                   / \       I
      I     \ /                   \ /       I
      I      |                     |        I
     Org     |                     |     Person
  Subclasses |                     |   Subclasses
             |                     |
            \ /                   \ /
       +-----+---+           +-----+------+
       | OrgRole |           | PersonRole |
       +---------+           +------------+

The above figure shows:

   1) An organization with a set of subclasses
   2) A Person with its own set of subclasses
   3) An Organization with an aggregation of OrgRole subclasses
   4) A person with an aggregation of PersonRole subclasses
   5) An aggregation, enabling an Organization to aggregate People

Hence, any of the Organization subclasses can have its own Role or Role
Combination, and any of the Person classes can have their own separate Role
or Role Combination.

5. References

[1]  Riehle, D., "Composite Design Patterns", Proceedings  of the 1997
      Conference on Object-Oriented Programming Systems, Languages and
      Applications (OOPSLA '97), ACM Press, 1997. Page 218-228
[2] http://csrc.nist.gov/groups/SNS/rbac/standards.html

regards,
John