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

1

Rick Murphy, IT 862, Spring 2005

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

2

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

3

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

4

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

5

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

6

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

7

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

8

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

9

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

10

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

11

Definitions

A

role r



R

is a pair 

S



N

where

s



S

is a service and

n



N

is the name of a role defined by

s

.

Environmen A

privilege p

tal constraint 

P

is a pair s

ε



E

are evaluated   

O



A

at role activation time.

where

o



O

is a object and

a



A

is an access mode for the object

o

.

An

appointmen t certificat e

 is an instance of an appointmen t.

May include prerequisi te roles of the form σ : Ω  2

R

and environmen tal constraint s of the form  :   2

E

where A

role

Ω is the set of all

activation rule

is appointmen a sequent 

x 1,

t certificat

x 2

,...,

x n

 | es in the

r

 system.

where

x j

,1 

j



n

is a variable in

X



R

 

E

, and

r



R 12

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

13

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

14

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

: I u (

x

)       

true false

if if

x x

  if

x



R



E

is , otherwise.

and

u

and

u

active the is active possesses in all the the in evaluation role of

x x

, appointmen prerequisi te yields t certificat roles true.

r

  e (

x

and

x

), Note that activation rules do not include negation.

15

Role Activation

 Given, Γ, the set of role activation functions: A role

r



R

can be activated within a session

u



U

by the I activation u | 

x j

rule for all  1   (

x 1

,

x 2 j



n

, ,..., where

x n

-|

r

I u )   provided is the interpreta that tion function  for

u

at the time when the activation request is made.

  becomes the

current activation rule

for role

r

.

 Definition depends on context: session, environment.

 Deactivation may be automatic when

membership rule

no longer valid

16

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

17

Membership Rules

  Role membership is predicated on Membership Rules ( Λ) These must remain satisfied to remain active in role The

membership

for the

rule

associated with the activation rule (

x 1 ,x 2 ,...,x n

-|

r

)   role

r



R

is the sequent (

x 1 ,x 2 ,...,x m

-|

r

) for some

m



n

, where

x i

for which 1 

i



m

are the membership Suppose that a role

r



R

has current activation conditions rule  .

  , and that (

x 1 ,x 2 ,...,x m

-|

r

)   is the correspond ing membership rule.

Then

r

shall be deactivate d as soon as the context changes so that I u | 

x i

for some membership condition

x i

, where I u is the interpreta tion function for

u

.

18

Role Deactivation

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

Example :



r 1

,

r 2

  

1

-|

r 4

If

r 1

enables

r 4

,

r 1

is the membership rule.

Revocation of

r 1

will deactivate

r 4

.

19

    

Role-Privilege relation

RP 

R



P

Associates roles with privileges Many-to-Many relation Specified by security administrators Direct Privileges  Those assigned to role

r

directly:

DP

(

r

)  

p

|

r

, 

RP

  Effective Privileges Include those that session with user in

r

hold.

must necessarily    DP(

r

) EP(x) for prerequisite roles EP(p) for appointment certificates

20

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)

21

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

22

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.

 (

u

?),  ( 73 ,

v

?),  (

v

,

w

) |   (

w

) u and v are bound, w is not.

23



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

local_user(h_id) employed_medic(h_id) on_duty(h_id) doctor_on_duty(h_id)

Type

role appointment environment role

Parameters

h_id: local user id h_id: local user id h_id: local user id h_id: local user id Policy : local_user (h_id?), employed_m edic(h_id?

), on_duty(h_ id) -| doctor_on_ duty(h_id) Logic Formula :  x(local_us er(x)   doctor_on_ duty(x)) employed_m edic(x)  on_duty(x)

24



Another Example

All patients in a ward are in the care of the doctor currently on duty there.

Name

doctor_on_duty(h_id) treating_doctor(h_id, pat_id) ward_patient(pat_id, t)

Type

role role environment

Parameters

h_id: local user id h_id: local user id pat_id: patient id pat_id: patient id t: time of admission Policy : doctor_on_ duty(h_id?

), ward_pati ent(pat_id ?, t?) -| treating_ doctor(h_i d, pat_id)

25

 

Appointment Certificate Example

Doctor must be qualified and a current employee to be on duty.

Not all elements need be specified

Name

qualified(gmc_id, name, d, sp) emp_db_user(gmc_id, h_id) doctor(h_id)

Type

appointment environment role

Parameters

gmc_id: id name: doctor’s name d: date of registration sp: specialization gmc_id: identifier h_id: local user id h_id: local user id Policy : qualified( gmc_id?, name?, d?, sp?), emp_db_use r(gmc_id, h_id?) -| doctor(h_i d)

26

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

27



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

read_EHR(y, f) check_field_td(f) privilege environment

Meaning and Parameters

Read a field from a patient’s EHR y: patient identifier f: field name check within rights of treating doctor f: field name treating_d octor(x?, y?), check_fiel d_td(f) -| read_EHR(y ?, f?)

28

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

29

Case Studies

 Detailed case studies provided  Anonymity  Multidomain Healthcare System

30

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

31

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

32