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