An Introduction to Role-Based Access Control ANSI INCITS 359-2004

ANSI RBAC EXPLAINED

Misnomers abound as to what constitutes a working Role-Based Access Control (RBAC) system. With ANSI RBAC, Groups are not Roles and resource connections not Sessions. This paper explains what ANSI RBAC is and how it can be applied to existing problem domains. It dispels longstanding myths persistent within the enterprise. Additionally readers receive tips on how to implement their own successful RBAC program and where to go to get a fully compliant ANSI RBAC system that may be used as a reference implementation.

WHAT ANSI RBAC IS NOT

1. User Groups (i.e. LDAP groupOfUniqueNames). In RBAC, Roles are many-to-many mappings between User and Permission entities. Furthermore the assignments and grants may be interrogated, added or removed at any time. Roles should fall within a hierarchy which facilitate control over assets, encourages reuse and reduces the number of entitlements that have to be maintained.

RFC 4519 LDAP: Schema for User Applications June 2006        
(  2.5.6.17 NAME 'groupOfUniqueNames'          
   SUP top          
   STRUCTURAL          
   MUST ( uniqueMember $                
                cn )          
   MAY ( businessCategory $                
              seeAlso $                
              owner $                
              ou $                
              o $                
              description ) 
) 

groupOfUniqueNames is not RBAC

2. Resource connections (i.e. LDAP connection). Allowing your LDAP or DB system to calculate entitlements based on user group assignments violates the concept of least privilege. RBAC compliant systems add a role activation step to signon that provides control over what a user can do at a point in time within a particular application.

3. User-to-Entitlement Access Control List. Bypassing roles and mapping entitlements directly to users will undermine the ability to control and determine who has access to what resources. It also makes it difficult to figure out what access needs to be granted or revoked and when.

4. Outdated or obsolete. Contrary to what is often told, the RBAC model is still a viable means in which to manage security within the enterprise. Employ finer-grained attribute-based or dynamic access controls as needed but ANSI RBAC is still the foundation for sound enterprise IT security strategies.

WHAT ANSI RBAC IS

There is more to RBAC than using a Role object during policy enforcement.

1. ANSI INCITS 359-2001, http://profsandhu.com/journals/tissec/ANSI+INCITS+359-2004.pdf – The ANSI specification describes RBAC and provides functional specifications in Z-notation.

2. RBAC0 - Users, Roles, Permissions (Objects-Operations), Sessions - Form the Core of ANSI RBAC. Role activation and Permissions mapped to Object->Operation pairing are key facets of the basic ANSI RBAC model.

3. RBAC1 - Hierarchical Roles - Encourages proper role engineering. Parent roles are Business Roles while child roles map to IT Roles. Role hierarchies should be many-to-many or multi-inheritance.

4. RBAC2 - Static Separation of Duties - Used to limit the privilege of users to within normal boundaries. SSD constraints are applied at role assignment time.

5. RBAC3 - Dynamic Separation of Duties - Enforces constraints on what functions may used together at any point in time. DSD constraints may be used to enforce strict controls during multi-step approval processes. DSD constraints are applied at role activation time.

6. Well defined APIs that can be shared across projects and application development teams.

7. Well defined data model. Easily created and replicated across the enterprise.

WHY IS ANSI RBAC IMPORTANT?

1. Enforces the concept of least privilege. Granting users business functionality doesn’t imply entitlements may be used at any time. For example a bank teller shouldn’t withdrawal money from customer accounts outside of normal business hours or freelance contractors don’t require access to production resources to do their jobs.

2. Enables Regulatory Compliance. Who has been granted authority to the most important resources? How can we be certain that terminated employees and customers no longer have access to controlled resources?

3. Enforces separation of duty policies. For example traders must not be regulators or purchasing agents cannot approve transactions.

4. Eases administration costs due to elimination of redundant resources. Enable business units to be delegated administrative tasks.

HOW TO IMPLEMENT ANSI RBAC

1. Learn using the SPEC

2. Pick a technology stack you are comfortable with based on current knowledge, SLAs, data storage, and support requirements.

3. Design a very simple RBAC data model. Eight objects are all that is needed.

• User, Role, Permission, Object, Operation, User-Role, Session, Constraints

4. Design a simple RBAC software model.

Top layer called a Manager and contains a stable public API that external apps may call.

• Three managers, System, Admin, Review are all that is needed.

• The implementation the manager interface contains must be able to be be swapped out for another complete RBAC system without impacting dependent apps.

• External applications use RBAC Manager API to map to internal entitlement systems.

Middle layer for RBAC system is optional and may be used for processing fine-grained data validations rules

Bottom layer for accessing the actual data.

• Implementation may be swapped for other back ends without impacting Manager.

• LDAP, JDBC, Hibernate, JAX-WS, JAX-RS other technologies may be used here to manage the data

5. Don’t ignore the Audit

• View before and after images of the data

6. Code first as a POC. Start with the core - RBAC0. Get it right first.

7. Test driven development and automation key contributors to successful outcome.

8. Engage IT teams.

• analyze existing IT entitlements.

• Use established role mining techniques.

9. Map existing IT entitlements to RBAC system using established role engineering techniques

10. Use parent roles as Business Roles and child roles as IT Roles.

11. Deploy RBAC system into application environment using established standards. Use declarative policy enforcement points like JEE security for coarse-grained, Spring for fine-grained.

12. Application teams own mapping between Business and IT roles.

13. Model administrative controls on ARBAC. More on ARBAC coming soon…

14. Roll-out (Slow and steady starting out)

WHERE TO GO FOR MORE INFO

Download the ANSI RBAC specification: here

Download working ANSI RBAC reference implementation: here