Comments on Role Based Access Control

[Anne Anderson <Anne.Anderson@Sun.com>]

**The opinions expressed below are those of the individual
**author, and do not represent any official position on the part
**of Sun Microsystems.

The following comments pertain to the proposed ANSI standard
"Role Based Access Control", BSR INCITS 359, 4/4/2003.

1. 4. "Permission" - The definition of "Permission" used
   throughout this specification is rather limited.  In most
   cases, a role will not be allowed unconditional access to a
   given operation on a given object, but will be given access
   under certain additional constraints: time of day, IP address
   from which request comes, etc.  The existing definition is OK
   as a starting point, but the functional schemas should take
   into account that additional constraints are likely to be
   associated with a "permission".

2. 5. "RBAC Reference Model"  I think the specification of the
   model components for Core RBAC, Hierarchical RBAC, Static
   Separation of Duty, and Dynamic Separation of Duty are very
   useful.  It will be good to have this standard description
   available to use as a reference.  While more elaboration of
   the models with additional components might be desired, I
   believe these are a good starting point.

3. 6.1.1 I doubt whether the administrative functions pertaining
   to user administration (AddUser, DeleteUser) belong in this
   specification.  Most implementations of RBAC will be done as
   part of an existing system that has its own user
   administration functions.  These functions should be made
   non-mandatory.  The specification should require only that
   there be a means of creating a defined set of USERS.

4. 6.1.2, 6.2.1.2, 6.4.1.2, 6.4.2.2 Likewise, most systems will
   not have session management functions that map exactly onto
   the schemas specified for CreateSession, DeleteSession, etc.
   I suggest that these be made non-mandatory, and that the
   requirement be only that the specified semantics be a subset
   of some collection of operations supported by a complying
   system.

5. 6.1.2 "CheckAccess" does not belong in "Supporting System
   Functions".  This is the central function in RBAC, and should
   have its own category.  This is the one function that should
   probably be specified as mandatory in something like its
   specified form.  RBAC-supporting systems may have various ways
   of associating users with sessions, activating roles for
   sessions, etc. but "CheckAccess" is the one function that
   might be implemented by a standard, non-platform-specific
   entity.

6. 6.1.4, 6.2.1.4 "RolePermissions", "UserPermissions",
   "SessionPermissions", "RoleOperationsOnObject", and
   "UserOperationsOnObject".  It is in these functions that the
   limited definition of "permission" used in this specification
   becomes problematic.  In real-world systems, a "user" will not
   have a set of unconditional "permissions": rights to perform
   specific operations on specific objects.  Instead, the user
   will have such permissions subject to additional constraints,
   such as time of day or whether user's source IP address is
   inside or outside the firewall.  These functions either need
   to require specific constraints as inputs (e.g. at this time
   of day, which operations may this user perform on which
   objects), or else the result needs to include predicates
   representing various constraints.

Anne Anderson
-- 
Anne H. Anderson             Email: Anne.Anderson@Sun.COM
Sun Microsystems Laboratories
1 Network Drive,UBUR02-311     Tel: 781/442-0928
Burlington, MA 01803-0902 USA  Fax: 781/442-1692

**The opinions expressed above are those of the individual
**author, and do not represent any official position on the part
**of Sun Microsystems.