Upload
rebecca-whitehead
View
214
Download
0
Tags:
Embed Size (px)
Citation preview
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