An Investigation on Testing RBAC Constraints

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 (contd)

• 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 -gt The system enforces Rule 1
• False -gt 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

10
Separation of Duty Constraints (contd)

• 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 (contd)

• 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 (contd)

• 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 (contd)

• 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 doesnt 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 (contd)

• 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 (contd)

• 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.
• Dont 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