ECRM:AccessControl
From FaithHighway Wiki
Contents |
[edit] Main
RBAC - Role Based Access Control system;
http://andrey.fhv2.com/rbac/test.php - test of the above system using;
http://andrey.fhv2.com/rbac - access managment tool for the above system.
[edit] Staff
This page consists of two main parts – the RBAC Reference Model and the RBAC System and Administrative Functional Specification. These are overview of the standard Role Based Access Control
[edit] Terms & Definitions
The following terms have specialized meanings within this standard.\
component: As used in this standard, component refers to one of the major blocks of RBAC features, core RBAC, hierarchical RBAC, SSD relations, and DSD relations.
objects: As used in this standard, an object can be any system resource subject to access control, such as a file, printer, terminal, database record, etc.
operations: An operation is an executable image of a program, which upon invocation executes some function for the user.
permissions: Permission is an approval to perform an operation on one or more RBAC protected objects.
Role: A role is a job function within the context of an organization with some associated semantics regarding the authority and responsibility conferred on the user assigned to the role.
User: A user is defined as a human being. Although the concept of a user can be extended to include machines, networks, or intelligent autonomous agents, the definition is limited to a person in this document for simplicity reasons.
[edit] RBAC Reference Model
The RBAC reference model is defined in terms of four model components—Core RBAC, Hierarchical RBAC, Static Separation of Duty Relations, and Dynamic Separation of Duty Relations. Core RBAC defines a minimum collection of RBAC elements, element sets, and relations in order to completely achieve a Role-Based Access Control system. This includes user-role assignment and permission-role assignment relations, considered fundamental in any RBAC system. In addition, Core RBAC introduces the concept of role activation as part of a user’s session within a computer system. Core RBAC is required in any RBAC system, but the other components are independent of each other and may be implemented separately.
Each model component is defined by the following sub-components:
• a set of basic element sets
• a set of RBAC relations involving those element sets (containing subsets of Cartesian products denoting valid assignments)
• a set of Mapping Functions, which yield instances of members from one element, set for a given instance from another element set.
[edit] Core RBAC
Core RBAC model element sets and relations are defined in Figure 1. Core RBAC includes sets of five basic data elements called users (USERS), roles (ROLES), objects (OBS), operations (OPS), and permissions (PRMS). The RBAC model as a whole is fundamentally defined in terms of individual users being assigned to roles and permissions being assigned to roles.
Central to RBAC is the concept of role relations, around which a role is a semantic construct for formulating policy. Figure 1 illustrates user assignment (UA) and permission assignment (PA) relations. The arrows indicate a many-to-many relationship (e.g., a user can be assigned to one or more roles, and a role can be assigned to one or more users). This arrangement provides great flexibility and granularity of assignment of permissions to roles and users to roles.
Each session is a mapping of one user to possibly many roles, i.e., a user establishes a session during which the user activates some subset of roles that he or she is assigned. Each session is associated with a single user and each user is associated with one or more sessions. The function session_roles gives us the roles activated by the session and the function session_users gives us the user that is associated with a session. The permissions available to the user are the permissions assigned to the roles that are currently active across all the user’s sessions.
Core RBAC specification:
LookTo: ANSI+INCITS+359-2004.pdf p4(13).
[edit] Hierarchal RBAC
This model component introduces role hierarchies (RH) as indicated in Figure 2. Role hierarchies are commonly included as a key aspect of RBAC models and are often included as part of RBAC product offerings. Hierarchies are a natural means of structuring roles to reflect an organization’s lines of authority and responsibility.
Role hierarchies define an inheritance relation among roles. Inheritance has been described in terms of permissions; i.e., r1 “inherits” role r2 if all privileges of r2 are also privileges of r1. For some distributed RBAC implementations, role permissions are not managed centrally, while the role hierarchies are. For these systems, role hierarchies are managed in terms of user containment relations: role r1 “contains” role r2 if all users authorized for r1 are also authorized for r2. Note, however, that user containment implies that a user of r1 has (at least) all the privileges of r2, while the permission inheritance for r1 and r2 does not imply anything about user assignment.
This standard recognizes two types of role hierarchies—general role hierarchies limited role hierarchies. General role hierarchies provide support for an arbitrary order to serve as the role hierarchy, to include the concept of multiple inheritances permissions and user membership among roles. Limited role hierarchies impose restrictions resulting in a simpler tree structure (i.e., a role may have one or immediate ascendants, but is restricted to a single immediate descendent).
[edit] Constrained RBAC
Constrained RBAC adds Separation of Duty relations to the RBAC model. Separation of duty relations are used to enforce conflict of interest policies that organizations may employ to prevent users from exceeding a reasonable level of authority for their positions.
This RBAC standard allows for both static and dynamic separation of duty as defined within the next two subsections.
[edit] Static Separation of Duty Relations
Conflict of interest in a role-based system may arise as a result of a user gaining authorization for permissions associated with conflicting roles. One means of preventing this form of conflict of interest is through static separation of duty, that is, to enforce constraints on the assignment of users to roles. Static constraints can take on a wide variety of forms. A common example is that of Static Separation of Duty (SSD) that defines mutually disjoint user assignments with respect to sets of roles. Static constraints have also been shown to be a powerful means of implementing a number of other important Separation of Duty policies.
The static constraints defined in this model are limited to those relations that that place restrictions on sets of roles and in particular on their ability to form UA relations. This means that if a user is assigned to one role, the user is prohibited from being a member of a second role. An SSD policy can be centrally specified and then uniformly imposed on specific roles. From a policy perspective, static constraint relations provides a powerful means of enforcing conflict of interest and other separation rules over sets of RBAC elements. Static constraints generally place restrictions on administrative operations that have the potential to undermine higher-level organizational Separation of Duty policies.
As illustrated in figure 3, SSD relations may exist within hierarchical RBAC. When applying SSD relations in the presence of a role hierarchy, special care must be applied to ensure that user inheritance does not undermine SSD policies. As such, role hierarchies have been defined to include the inheritance of SSD constraints. To address this potential inconsistency SSD is defined as a constraint on the authorized users of the roles that have an SSD relation.
[edit] Dynamic Separation of Duty Relations
Static separation of duty relations reduce the number of potential permissions that can be made available to a user by placing constraints on the users that can be assigned to a set of roles. Dynamic Separation of duty (DSD) relations, like SSD relations, are intended to limit the permissions that are available to a user. However, DSD relations differ from SSD relations by the context in which these limitations are imposed. SSD relations define and place constraints on a user’s total permission space. This model component defines DSD properties that limit the availability of the permissions over a user’s permission space by placing constraints on the roles that can be activated within or across a user’s sessions. DSD properties provide extended support for the principle of least privilege in that each user has different levels of permission at different times, depending on the role being performed. These properties ensure that permissions do not persist beyond the time that they are required for performance of duty. This aspect of least privilege is often referred to as timely revocation of trust. Dynamic revocation of permissions can be a rather complex issue without the facilities of dynamic separation of duty, and as such it has been generally ignored in the past for reasons of expediency.
Dynamic separation of duty relations are defined as a constraint on the roles that are activated in a user’s session.
