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: 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

RE RX

AO

AOP

E

NS

NSR

E

R

and ,Ω in variablea is ,1 where

|,...,sequent a is A

system. in the escertificatt appointmen all ofset theis Ω where

2 : form theof sconstraint talenvironmen

and 2 Ω : σ form theof roles teprerequisi includeMay

t.appointmenan of instancean is An

object for the mode accessan is andobject a is where

pair a is A

time.activation roleat evaluated are sconstraint talEnvironmen

.by defined role a of name theis and service a is where

pair a is A

rnjx

rxxxrule activation role

ecertificat tappointmen

oao

a ,opprivilege

ε

sns

n ,srrole

j

n21,

.

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 ω1 can 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:

otherwise.

true.yields of evaluation theand if

),( roles teprerequisi theallin active is

and ecertificatt appointmen thepossesses , if

, rolein active is and if

)(Iu

false

true

xx

xr

xux

xux

x

E

R

Note that activation rules do not include negation.

16

Role Activation

Given, Γ, the set of role activation functions:

. rolefor thebecomes

made. isrequest activation when the timeat the for

functiontion interpreta theis I where, 1 allfor | I

that provided ) -| ,..., ,( rule activation

by the session a within activated becan roleA

uu

r rule activation current

u

njx

rxxx

ur

j

n21

UR

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

.for function tion interpreta theis I where,condition membership some

for | I that so changescontext theassoon as ddeactivate be shall

Then rule. membership ingcorrespond theis ) -| (

thatand , rule activationcurrent has role a that Suppose

.conditions membership theare 1for which where

, somefor ) -| (sequent theis role for the

) -| ( rule activation with theassociated The

u

u

ux

xr

r,...,x,xx

r

mix

nmr,...,x,xxr

r,...,x,xx rule membership

i

i

m21

i

m21

n21

R

R

19

Role Deactivation

Deactivated when predicates no longer satisfied May lead to cascading deactivation OASIS has event infrastructure for triggers

. deactivate will of Revocation

rule. membership theis , enables If

-| , :Example

41

141

4121

rr

rrr

rrr

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

PR RP

RPprprDP ,|)(

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.

not. is wbound, are vandu

)(|),(?),,73(?),( wwvvu

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

Name Type Parameters

local_user(h_id) role h_id: local user id

employed_medic(h_id) appointment h_id: local user id

on_duty(h_id) environment h_id: local user id

doctor_on_duty(h_id) role h_id: local user id

duty(x))doctor_on_

on_duty(x) edic(x)employed_m er(x)x(local_us :Formula Logic

duty(h_id)doctor_on_ -|

id)on_duty(h_),edic(h_id?employed_m (h_id?),local_user :Policy

25

Another Example All patients in a ward are in the care of the doctor

currently on duty there.

Name Type Parameters

doctor_on_duty(h_id) role h_id: local user id

treating_doctor(h_id, pat_id) role h_id: local user id

pat_id: patient id

ward_patient(pat_id, t) environment pat_id: patient id

t: time of admission

pat_id) d,doctor(h_i treating_-|

t?)?,ent(pat_id ward_pati),duty(h_id?doctor_on_ :Policy

26

Appointment Certificate Example Doctor must be qualified and a current employee to

be on duty. Not all elements need be specifiedName Type Parameters

qualified(gmc_id, name, d, sp) appointment gmc_id: id

name: doctor’s name

d: date of registration

sp: specialization

emp_db_user(gmc_id, h_id) environment gmc_id: identifier

h_id: local user id

doctor(h_id) role h_id: local user id

d)doctor(h_i -|

h_id?) r(gmc_id,emp_db_use sp?), d?, name?, gmc_id?,qualified( :Policy

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.

Name Type Meaning and Parameters

read_EHR(y, f) privilege Read a field from a patient’s EHR

y: patient identifier

f: field name

check_field_td(f) environment check within rights of treating doctor

f: field name

f?) ?,read_EHR(y -| d_td(f)check_fiel y?), octor(x?,treating_d

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