1. An Investigation on Testing RBAC Constraints Presented by Jiao Chen 04/29/2003

2. Project Objectives Develop coverage criteria for testing RBAC constraints Develop algorithms for statically checking the enforcement of RBAC constraints Generating test cases for RBAC constraints based on the developed coverage criteria

3. Significance of the Problem The RBAC has generated great interest in the security community as a flexible approach in access control. Constraints are an important aspect of access control and are a powerful mechanism for laying out a higher-level organization policy.

4. Significance of the Problem (cont’d) Issues of specification of constraints have received surprisingly little attention in the research literature [1]. Few literature discusses the testing of the RBAC constraints.

5. Coverage Criteria Coverage is an operational definition for a complete test suite. It is important to define the coverage criteria before generating test case. Classical coverage criteria, like statement coverage, c-use coverage, etc. are not suitable for testing RBAC constraints. New coverage criteria are needed.

6. Details of My Approach The work of this project is based on the constraints specification described in Ahn G-J. and Shin M. E.’s [1] paper. For each kind of RBAC constraints, static checking algorithm and corresponding coverage criterion is developed respectively. A case study is performed. Test cases are generated following the coverage criteria developed.

7. Category of Role-based Constraints Separation of duty constraints Prerequisite constraints Cardinality constraints

8. Separation of Duty Constraints Rule 1: Conflicting roles cannot be assigned to the same user. Criterion 1: All conflicting role pairs in the conflicting role set are exercised in negative way. That means, for each conflicting role pair, at least one test case should cover the violation of that conflicting role pair.

9. Static checking algorithm for Rule 1 Input: Conflicting role set A = {(r1, r1c), (r2, r2c), (ri, ric), …, (rn, rnc)}, Assigned role set B = {(r1u1, r2u1, r3u1, riu1, …, rnu1), (r1u2, r2u2, r3u2, riu2i, …, rnu2), (r1u3, r2u3, r3u3, riu3, …, rnu3), …, (r1un, r2un, r3un, riun, …, rnun)} Output: True -> The system enforces Rule 1 False -> The system does not enforce Rule 1 Initialization: flag = 0 For each user in the assigned role set B For each role assigned to that user, riui Go through the conflicting role set A if riui is one of ri flag = 1 Go through the corresponding assigned roles of that user, i.e., (r1u1, r2u1, r3u1, riu1, …, rnu1) if  riui  (r1u1, r2u1, r3u1, riu1, …, rnu1) and riui = ric flag = 2 if flag == 2 return false, exit else return true end for

10. Separation of Duty Constraints (cont’d) Rule 2: Conflicting permissions cannot be assigned to the same role. Criterion 2: All conflicting permission pairs in the conflicting permission set are exercised in negative way. That means, for each conflicting permission pair, at least one test case should cover the violation of that conflicting permission pair.

11. Separation of Duty Constraints (cont’d) Rule 3: Conflicting users cannot be assigned to the same role. Criterion 3: All conflicting user pairs in the conflicting user set are exercised in negative way. That means, for each conflicting user pair, at least one test case should cover the violation of that conflicting user pair.

12. Separation of Duty Constraints (cont’d) Rule 4: Conflicting roles cannot be activated in the same session. Criterion 4: All conflicting role pairs in the conflicting role set are exercised in negative way. That means, for each conflicting role pair, at least one test case should cover the violation of that conflicting role pair.

13. Prerequisite Constraints Rule 5: A user can be assigned to role r1 only if the user is already a member of role r2. Criterion 5: All role prerequisite pairs in the role prerequisite set are exercised in following two ways: –1. For each role prerequisite pair, (ria, rib), at least one test case should cover the violation of that role prerequisite pair. In other word, the test case should cover the situation when assigning a user to ria without rib existing. 2. For each role prerequisite pair, (ria, rib), at least one test case should cover the situation that when rib is revoked, ria should be revoked at the same time.

14. Prerequisite Constraints (cont’d) Rule 6: A permission p can be assigned to a role only if the role already possesses permission q. Criterion 6: All permission prerequisite pairs in the permission prerequisite set are exercised in following two ways: –1. For each permission prerequisite pair, (pia, pib), at least one test case should cover the violation of that permission prerequisite pair. In other word, the test case should cover the situation when pia is assigned to a role but that role doesn’t possess pib. –2. For each permission prerequisite pair, (pia, pib), at least one test case should cover the situation that when pib is revoked, pia should be revoked at the same time.

15. Cardinality Constraints Rule 7: Numerical limitation N that exists for the number of users authorized for a role cannot be exceeded. Rule 8: Numerical limitation N that exists for the number of sessions a user can have active at the same time cannot be exceeded.

16. Cardinality Constraints (cont’d) The domain testing strategy –Identify boundary conditions. –Select test values for variables in each boundary. –Select test values for variables not given in the boundary. –Determine expected results

17. Cardinality Constraints (cont’d) The “one-by-one” domain testing strategy calls for one on point and one off point for each domain boundary. Selection rules: –One on point and one off point for each relational condition. –Don’t repeat identical tests for adjacent subdomains.

18. Case Study The corporate banking application in Chandramouli R.’s paper [2]. The results of the case study are in Constraints Specification.doc file.

19. References [1] Ahn G-J. and Shin M. E., Role-based Authorization Constraints Specification Using Object Constraint Language, Enabling Technologies: Infrastructure for Collaborative Enterprises, 2001. WET ICE 2001. Proceedings. Tenth IEEE International Workshops on, 2001, Page(s): 157 -162 [2] Chandramouli R. Application of XML tools for enterprise- wide RBAC implementation tasks Proceedings of the fifth ACM workshop on Role-based access control July 2000