[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Comments on Role Based Access Control
**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.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]