A Model of OASIS Role-Based Access Control and Its Support for Active Security

1. A Model of OASIS Role-Based Access Control and Its Support for Active Security Rick Murphy, IT 862, Spring 2005

2. The Open Architecture for Securely Interworking Services (OASIS) • Built to support healthcare in the UK • Role-based access control for services • Roles and policies at the service level • Local policies • Service-Level Agreements between administrative domains • Parameterized roles and permissions • Allows policy to express policy exceptions

3. OASIS RBAC • Issues with role hierarchies • Senior roles inherit, violating least privilege • Conflicting constraints • Activation Hierarchies are one solution • Choose to activate roles when necessary • Hierarchies are static, OASIS is dynamic • Dynamic role-role relationship/dependencies

4. Credential-Based Role Activation • Authorization to activate role depends on • User Credentials • Environmental State • Prerequisite roles • User activates subset of potential roles • Least privilege • Active security takes context into consideration • OASIS Role Activation similar to sessions • Except that user does not deactivate

5. Role Activation Rules • Specify necessary conditions to activate a role • Prerequisite Roles (Session-based) • Appointments • Constraints (Separation of duties, etc.) • Active security uses time-based constraints • Parametric model based on first-order logic • Variables bound to time, userids, object attributes • Predicates tested at both activation and access time

6. Appointment vs. Delegation • Delegation allows user to grant role to others • Delegation grants target role’s permissions • Appointment • Appointer role grants credential to user • Credential can be used to activate role(s) • Appointed role is task-based and restricted • Tightly controlled privilege propagation • Appointment does not confer privileges • Appointer can confer privileges they do not possess

7. Task Assignments and Qualification • OASIS allocates privileges by controlling role activation • Task Assigned to principal • Privileges aggregated into associated role • Combined with appointments • Delegator may not have permission granted • Granted due to holding qualification or credential • May be necessary but not sufficient

8. Appointment, Role-Based Delegation, and Administrative Roles • Appointment and Role-Based Delegation enable privilege propagation • Delegation need not grant all permissions • Some models allow partial delegation • Role delegation associated with task assignment • Appointer may not themselves have role • As with administrative roles • Appointee granted only permissions necessary to task

9. Appointment Characteristics • Type: Task assignment, qualification • Appointer: Principal who initiates • Appointer role must permit issuance • Appointee: Principal receiving appointment • Activation rules restrict usage • Identity match, validity rules • Revocation: Triggered by invalidating CR

10. Appointment Revocation • Appointer-only • Manager delegates and monitors • Appointer-role • Limits error/damage if appointer unavailable • System-managed • Revoked automatically if conditions met • Periodic renewal • Task-Based • Session-Based

11. OASIS Basic Model • Based on first-order propositional logic • Basic Sets: • U: setofall user sessions • S: set of all services • N: set of all role names • E: set of all environmental constraints • O: set of all objects • A: set of all access modes for objects • Extended Sets: • R: set of all roles • P: set of all privileges • Ω: set of all appointment certificates

12. Definitions

13. Role Activation Rules • All of the xj conditions must be satisfied • These are called activating conditions • Examples: • R = {r1, r2, r3, r4} and Ώ = {ω1, ω2} • r1, ω1├ r4 • user in role r1 holding certificate ω1 can activate role r4(providing appointment certificate conditions are met) • (r1 v r2) ^ ω1├ r4 • Either role r1 or r2 holding ω1can activate r4

14. Role Activation • Initial roles: depend on Ω, E only • Allow users to start session with some roles • Assumes user authentication/session setup • Can have roles with no antecedent conditions, ┤r. • Initial roles activated after authentication • Additional roles activated during session • Restricted by • Activation rules • Parameter evaluation

15. Activation Interpretation Function • Activation Rule Predicates must be satisfied to activate a role • Activation Function evaluates those • Interpretation function for user u and variable x: Note that activation rules do not include negation.

16. Role Activation • Given, Γ, the set of role activation functions: • Definition depends on context: session, environment. • Deactivation may be automatic when membership rule no longer valid

17. Activation Process • Each condition of the activation rule verified • Some activation variables static • Some depend on roles held, environment • Service s may register trigger to revoke role • Environment changes (timer) • Release of prerequisite roles • Membership in prerequisite groups • Active Security prototype uses database triggers to support this

18. Membership Rules • Role membership is predicated on Membership Rules (Λ) • These must remain satisfied to remain active in role

19. Role Deactivation • Deactivated when predicates no longer satisfied • May lead to cascading deactivation • OASIS has event infrastructure for triggers

20. Role-Privilege relation • Associates roles with privileges • Many-to-Many relation • Specified by security administrators • Direct Privileges • Those assigned to role r directly: • Effective Privileges • Include those that session with user in r must necessarily hold. • DP(r) • EP(x) for prerequisite roles • EP(p) for appointment certificates

21. Privilege Sets • Some RBAC models allow computation of maximal privilege set • OASIS policies are more complex • Set on a service-by-service basis • Multiple, distributed management domains • Service-level agreements between domains • Appointment certificates may cross levels • Appointment scope may vary (local, cross-domain)

22. Extended Model • Basic Model decides based on propositions evaluated in current context • Roles and appointments • Permission acquisition policy based on those • Extended model allows parameterization of roles, appointment certificates, privileges, and environmental constraints • Define role activation rules using predicates rather than propositions

23. Extended Model Constructs • Sets as in basic model : U, S, N, O, A. • Typed parameters • Allows static checking • Variables, constants, functions • Parameter modes: in and out • P(x, y?) has in-parameter x and out-parameter y • Bound variables: u is bound in a rule if used as an out parameter, else free.

24. Role Activation Rule Example • Cannot have free variables • Allows clearly-defined activation semantics • Example: hospital policy where user who is employed there may acquire doctor_on_duty role whenever she is on duty

25. Another Example • All patients in a ward are in the care of the doctor currently on duty there.

26. Appointment Certificate Example • Doctor must be qualified and a current employee to be on duty. • Not all elements need be specified

27. Privileges and Authorization Rules • Basic model used RP relation • Extended model uses role parameters at access time • Authorization rules • (r, e1,…,en |- p) • en are environment variables, authorizing conditions

28. Authorization Rule Example • Treating_doctor in the ward is allowed to read fields 1, 3, and 4 only from the EHR of a patient under her care.

29. Model Semantics • Basic Model uses truth function • Extended Model uses variables • Interpretation guides assignment to variables • Satisfaction based on variable assignment • Interpret environmental predicates • Bind parameters • Evaluate terms • Model provides Term Evaluation rules • Must also consider role deactivation conditions

30. Case Studies • Detailed case studies provided • Anonymity • Multidomain Healthcare System

31. Related Work • Temporal RBAC [Bertino et. al.] • OASIS uses environmental triggers • Team-Based Access Control [Thomas; Georgiadis] • OASIS could be extended • Content-Based access control [Giuri and Iglio] • Parameterization of roles via templates

32. Conclusion • OASIS is a practical approach to real-world problems • Designed from the start to be a distributed system • Dynamic, reactive role membership • Prototype system has been proposed in UK