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 roles 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 : set of all 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 x j conditions must be satisfied These are called activating conditions Examples: R = {r 1, r 2, r 3, r 4 } and Ώ = {ω 1, ω 2 } r 1, ω 1 r 4 user in role r 1 holding certificate ω 1 can activate role r 4 (providing appointment certificate conditions are met) (r 1 v r 2 ) ^ ω 1 r 4 Either role r 1 or r 2 holding ω 1 can activate r 4

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 NameTypeParameters local_user(h_id)roleh_id: local user id employed_medic(h_id)appointmenth_id: local user id on_duty(h_id)environmenth_id: local user id doctor_on_duty(h_id)roleh_id: local user id

25 Another Example All patients in a ward are in the care of the doctor currently on duty there. NameTypeParameters doctor_on_duty(h_id)roleh_id: local user id treating_doctor(h_id, pat_id)roleh_id: local user id pat_id: patient id ward_patient(pat_id, t)environmentpat_id: patient id t: time of admission

26 Appointment Certificate Example Doctor must be qualified and a current employee to be on duty. Not all elements need be specified NameTypeParameters qualified(gmc_id, name, d, sp)appointmentgmc_id: id name: doctors name d: date of registration sp: specialization emp_db_user(gmc_id, h_id)environmentgmc_id: identifier h_id: local user id doctor(h_id)roleh_id: local user id

27 Privileges and Authorization Rules Basic model used RP relation Extended model uses role parameters at access time Authorization rules (r, e 1,…,e n |- p) e n 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. NameTypeMeaning and Parameters read_EHR(y, f)privilegeRead a field from a patients EHR y: patient identifier f: field name check_field_td(f)environmentcheck within rights of treating doctor f: field name

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