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



Activation Hierarchies are one solution


Senior roles inherit, violating least privilege
Conflicting constraints
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 activates subset of potential roles



User Credentials
Environmental State
Prerequisite 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





Active security uses time-based constraints
Parametric model based on first-order logic


Prerequisite Roles (Session-based)
Appointments
Constraints (Separation of duties, etc.)
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



Role delegation associated with task assignment
Appointer may not themselves have role


Some models allow partial delegation
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


Appointer-role


Manager delegates and monitors
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
A role r  R is a pair s , n  S  N
where s  S is a service and n  N is the name of a role defined by s.
Environmen tal constraint s ε  E are evaluated at role activation time.
A privilege p  P is a pair o , a  O  A
where o  O is a object and a  A is an access mode for the object o.
An appointment certificate  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  :   2E
where Ω is the set of all appointmen t certificat es in the system.
A role activation rule is a sequent x1, x2 ,..., xn | r 
where x j ,1  j  n is a variable in X R  Ω E , and r  R
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:
true


I u ( x)  


false
if x  R and u is active in role x,
if x  , u possesses the appointmen t certificat e x and
is active in all the prerequisi te roles r   ( x),
if x  E and the evaluation of x yields true.
otherwise.
Note that activation rules do not include negation.
16
Role Activation

Given, Γ, the set of role activation functions:
A role r  R can be activated within a session u  U by the
activation rule   ( x1 , x2 ,..., xn |- r )   provided that
I u | x j for all 1  j  n, where I u is the interpreta 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
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
The membership rule associated with the activation rule ( x1 ,x2 ,...,xn |- r )  
for the role r  R is the sequent ( x1 ,x2 ,...,xm |- r ) for some m  n,
where xi for which 1  i  m are the membership conditions .
Suppose that a role r  R has current activation rule   , and that
( x1 ,x2 ,...,xm |- r )   is the correspond ing membership rule. Then
r shall be deactivate d as soon as the context changes so that I u | xi for
some membership condition xi , where I u is the interpreta tion function for u.
19
Role Deactivation



Deactivated when predicates no longer satisfied
May lead to cascading deactivation
OASIS has event infrastructure for triggers
Example : r1 , r2    1 |- r4
If r1 enables r4 , r1 is the membership rule.
Revocation of r1 will deactivate r4 .
20
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 , p   RP
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, crossdomain)
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



Parameter modes: in and out


Allows static checking
Variables, constants, functions
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.
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
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)  employed_m edic(x)  on_duty(x)
 doctor_on_ duty(x))
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
Policy : doctor_on_ duty(h_id? ), ward_pati ent(pat_id ?, t?)
|- treating_ doctor(h_i d, pat_id)
26
Appointment Certificate Example


Doctor must be qualified and a current employee to
be on duty.
Not all elements need be specified
Name
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
Policy : qualified( gmc_id?, name?, d?, sp?), emp_db_use r(gmc_id, h_id?)
|- doctor(h_i d)
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
treating_d octor(x?, y?), check_fiel d_td(f) |- read_EHR(y ?, f?)
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.]


Team-Based Access Control [Thomas;
Georgiadis]


OASIS uses environmental triggers
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