1 / 39

Scalable and Efficient Reasoning for Enforcing Role-Based Access Control

Scalable and Efficient Reasoning for Enforcing Role-Based Access Control. Tyrone Cadenhead Murat Kantarcioglu, and Bhavani Thuraisingham. Overview. Motivation Contributions Approach Theoretical Background: RBAC, TRBAC, Description Logics, SWRL

meagan
Download Presentation

Scalable and Efficient Reasoning for Enforcing Role-Based Access Control

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. Scalable and Efficient Reasoning for Enforcing Role-Based Access Control Tyrone Cadenhead Murat Kantarcioglu, and Bhavani Thuraisingham

  2. Overview • Motivation • Contributions • Approach • Theoretical Background: • RBAC, TRBAC, Description Logics, SWRL • Detailed Overview of Approach and Optimizations • Example • Experimental Results

  3. Motivation • Organizations tend to generate large amount of data (or resources) • Users need only partial access to resources • Pairs: (user, role) (role, permission) (action, resource) • nu users and nr roles  at most nu ×nr mappings • Scalable access control model • Exchange expertise among experts, between systems • Heterogeneity in system • Make decision with data • Formal Semantics of Data

  4. Motivation (cont’d) • RBAC simplifies Security Management • But Roles are statically defined • TRBAC extends RBAC • Roles are dynamically defined and have a temporal dimension • Does not address Heterogeneity inherent in organization information systems • Ontology has a Common Vocabulary • Conforms to a Description Logic (DL) formalism • Description Logic (DL) Reasoning Service • Can be Distributed as over a set of Knowledge Bases

  5. Why Flexible RBAC • Physician Sam allowed access to Bob record • When Bob is under is care • Emergency: Sam is off duty, Kelly in emergency room: • Bob needs immediate treatment • Kelly not pre-assigned to view/update Bob’s record • Temporal RBAC

  6. Why Flexible TRBAC • Kelly needs to collaborate with different specialist from different expertise • Sharing of data across wards, departments • Seamless and unambiguous exchange of information • Ontologies • Common Vocabulary • Enable reconciliation and translation between different standards

  7. Automation • Kelly and team make decisions • Using Bob medical history • Access is needed Temporarily • Accuracy and efficiency critical • Automated Tool • Access granted in Emergency session • Apply policy rules over relevant data in Bob’s record • Verify the decisions based on formal logic • Make access decisions efficiently

  8. Main Contributions • TRBAC Implementation using existing semantic technologies • Reasoning Service for access control over large numbers of data instances in DL Knowledge Bases (KBs) • Efficiently and accurately reason about access rights

  9. Approach • Transform temporal access control policies to rules : • Semantic web rule language (SWRL) • Partitioning the Knowledge Base (KB) • - Terminological Box (TBox) • - Assertional Box (ABox) • A Knowledge Base consists of a TBox and ABox

  10. Approach (cont’d) • Achieves: 1. Scalability – support many users, roles, sessions, permissions; combinations w.r.t access control policies 2. Efficiency - determines the response time to make a decision in milliseconds 3. Correct reasoning – ensure all data assertions available when applying the security policies

  11. Theoretical Background • RBAC • TRBAC • Description Logic Language (ALCQ) • SWRL

  12. RBAC

  13. (Mappings) • Connect individuals from two domain modules: • RBAC assignments: • Think of mappings as relations of form P(i, j) with valid pairs (i, j) user-role, role-user, role-permission, permission-role, session-user, role-role and session-role • a binary relationship of form P(x, y), a restriction on values assigned to (x, y) pairs • Hospital extensions: • the mappings patient-user, user-patient and patient-session • Patient-Record constraint: • the one-to-one mappings patient-record and record-patient

  14. TRBAC • Extension of RBAC • Supports temporal access • Expressed by means of role triggers • Constrains the set of roles that a particular user can activate at a given time instant • Triggers • Firing a trigger cause a role to be enabled/disabled • Conflict Resolution • Simultaneous enabling and disabling of a role • Priorities

  15. Description Logics • Formally build our domain concepts and the relationships between them. • Add semantics (reasoning) • Use a knowledge representation language • We can formally say a doctor is a user, a surgeon is a doctor, a doctor has a medical degree.

  16. Description Logics

  17. SWRL Semantic Web Rule language (SWRL) • W3C recommendation. • A SWRL rule has the form: hi, bj are atoms of the form C(x), P(x, y) , sameAs(x,y), or differentFrom(x,y), where C is an OWL description, P is an OWL property, and x, y are Datalog variables, OWL individuals, or OWL data values

  18. Overview

  19. Intuition • a user assigned to role : • User attributes (name, sex, id) in partition • Details relating to role in partition • Session related details in partition • Query : • Optimization:

  20. Step 1 • Build step offline • Restrict each partition size: ensures each KB fits into the memory on the machine

  21. Step 2 • Load the policy rules into a new knowledge base . • Rules determine which assertions are relevant to determine any policy objective. • Adding rules to more efficient • Experimental results: • Impact on the reasoning time vs. adding rules to • Rules apply to a small subset of triples • Reduced number of symbols in the ABox

  22. Step 3 RBAC:

  23. Inference Stage • When there is an access request for a specific patient, start executing steps 2 and 3. • Steps 2 and 3 are our inferencing stages where we enforce the security policies. • These can also be executed concurrently for many patients, as desired.

  24. TBox • RBAC: • The sets and are atomic concepts in • Mappings and are formalized as DL roles • Employees are Users • Primary Physicians are employees with at least one patient • We can Conclude primary physicians are users.

  25. ABox

  26. RDF • W3C recommendation • Make assertions about any resources on the semantic Web • We can say Bob is a doctor • Doctor(Bob)  (Bob rdf:type Doctor) • Bob attended Harvard • (Bob, attended, “Harvard”)

  27. Distributed Reasoning

  28. Home Partition

  29. Connecting Partitions

  30. Distributed Reasoning • Physicians can be both a primary or emergency-room physician, and restricted to two roles. • Verify Bob does not exceed two roles • Execute query over is sufficient • Primary Physicians attend to at most five patients at a time • Query each one at a time is sufficient

  31. Temporal RBAC Reasoning • Implement TRBAC as triggers • TBox • ABox

  32. Temporal RBAC Reasoning • Periodic Event • Trigger: • doctor-on-day-duty must be enabled during the night • nurse-on-night-duty must be enabled whenever the role doctor-on-night-duty is

  33. Advantages

  34. Optimization • Two types of indexing: • indexing the assertions • Allow finding triple by subject (s), a predicate (p) or an object (o), • without the cost of a linear search over all the triples in a partition • creating a high level index. • points to the location of the partitions on disk • At most linear with respect to the number of partitions

  35. Policy Query

  36. Example

  37. Trace

  38. Experiments

  39. Experiments

More Related