A Model of OASIS RoleBased Access Control and Its Support for Active Security

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

Note that activation rules do not include
negation.
16
Role Activation

• Given, G, 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

25
Another Example

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

26
Appointment Certificate Example

• Doctor must be qualified and a current employee
  to be on duty.
• Not all elements need be specified

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.

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