Role-Based Access Control

Centralized access control enforcement is attractive because in most organizations, resource and information security objectives support a security policy that's typically defined at the highest level of the organization. Supporting such policies requires the ability to centrally control and maintain access rights. You can also argue that, for the following reasons, the RBAC model maps better to the administrative model that most organizations use for resource and application access control management:

• The security administrator is responsible for centrally enforcing access control policy. In the RBAC model, users can't simply pass their access permissions to other users at their discretion, as users in the DAC model can.
• Administrators who manage people are responsible for adding users to roles and often create user groups to facilitate role management. In the RBAC model, groups facilitate role management; in the DAC model, groups facilitate ACL management.
• In the RBAC model, resource and application administrators define roles in terms of application and resource operations and tasks. They pass this information to the security administrator, who ensures that the appropriate role-to-operation or role-to-task mappings are stored in the access control policy database. Administrators don't need to set appropriate ACLs on individual resources as they do in the DAC model.

A good example of an application that could easily take advantage of an RBAC model is an expense claiming and approval application. In such an application, you typically define a user and an approver role. Members of the user role have permission to create expense entries in the expense database. Every user has a manager attribute that links him or her to the expense approver. Members of the manager role are only permitted to change the status attribute of expense resources that are linked to users they manage. . . .