1 / 32

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

A Model of OASIS Role-Based Access Control and Its Support for Active Security. 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

Mercy
Download Presentation

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

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


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

More Related