1 / 27

R OWL BAC – Representing Role Based Access Control in OWL

This thesis explores how Role-Based Access Control (RBAC) can be supported by OWL, focusing on utilizing class hierarchy, cardinality constraints, and logic grounding. It covers RBAC ontology basics, representing roles, and enforcing separation of duty constraints.

Download Presentation

R OWL BAC – Representing Role Based Access Control in OWL

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. ROWLBAC – Representing Role Based Access Control in OWL Tim Finin, Anupam Joshi, UMBC Lalana Kagal, MIT Jianwei Niu, Ravi Sandhu, William Winsborough, UTSA Bhavani Thuraisingham, UTD

  2. Our Thesis • Semantic Web technology provides an good framework for enhancing interoperability and portability of authorization policy • We show how RBAC can be supported by OWL (Web Ontology Language)

  3. Why RBAC? • Role Based Access Control • NIST Standard • Real world success • Extensive academic study

  4. What is OWL? • OWL • A family of knowledge representation languages • Based on Description Logic (DL) • XML-based representation in Resource Description Framework (RDF) • W3C standard • Widely used for defining domain vocabularies called ontologies • Used for developing policy languages for Web

  5. Why Support RBAC in OWL? • OWL has features needed in distributed, decentralized environments • Cooperating organizations have their own native schemas and data models • OWL provides an appropriate framework in which to agree on and specify ontologies for roles, actions, and resources • Class hierarchy and other ontological restrictions make OWL particularly effective • Cardinality and disjointness • Grounding in logic facilitates translating among formalisms for analysis or execution

  6. Outline • RBAC in OWL • Basics • Two approaches to representing roles • Each has its own rbac ontology • Domain-specific ontologies • Additional stuff in the paper: • Attribute-based Access Control (ABAC) in OWL • Role-based Trust management (RT) and its security analysis in OWL

  7. RBAC in OWL: RBAC Ontology Basics • Actions • Subjects • Objects

  8. RBAC in OWL: Representing Roles • Two approaches to representing roles • Roles as classes • Roles as values • Each approach is supported by its own ontology • Differ in generality of queries that DL reasoning can support

  9. Roles as Classes • Each RBAC role is represented by two OWL classes: • Static assignment to the role (e.g., PermanentResident) • Dynamic activation of the role (e.g., ActivePermanentResident) • These each have two parent classes: • For each RBAC role, the domain-specific ontology has two classes, <RoleName> and <ActiveRoleName>

  10. Roles as Classes • OWL specification assigns static and activated roles • Role hierarchy is represented using the class hierarchy

  11. Roles as Classes Role hierarchy is represented upside down by class hierarchy

  12. Roles as Classes • Separation of duty • OWL directly supports ssod and dsod via the OWL property, disjointWith

  13. Roles as Classes • Permitted and prohibited subclasses of actions • Each action is an instance of exactly one subclass • PEP can query which one a given action belongs to

  14. Roles as Classes • Permission-role assignments are supported via rbac:PermittedAction • Domain-specific ontology example:

  15. Roles as Classes • Enforcing dsod constraints • User attempts to create a ActivateRole action Consider all currently active roles

  16. Roles as Values • Roles are modeled as instances of a generic Role class

  17. Roles as Values • Example:

  18. Roles as Values • Role hierarchy • RBAC ontology: • Domain-specific ontology:

  19. Roles as Values • Reasoning about inheritance

  20. Roles as Values • Separation of duty • RBAC ontology: • Domain-specific ontology:

  21. Roles as Values • Detecting separation of duty violations

  22. Roles as Values • Permission-role assignment • RBAC ontology: • Domain-specific ontology:

  23. Roles as Values • Determining whether an action is permitted

  24. Comparison of Approaches • Roles-as-classes supports more general queries • Can ask whether a specific user can access a specific resource • But, can also ask whether all members of a given role can access a class of resources • Roles-as-values • Can only ask whether a specific user can access a specific resource • Domain-specific ontologies for roles as values is simpler

  25. Changing State • Changes in the RBAC system have to be modeled by changing the set of OWL clauses • Adding clauses can be done efficiently • Adding a user to a role • A user activating a role • Removing clauses can lead to a lot of reevaluation • Removing a user from a role • A user deactivating a role

  26. Other Stuff • The paper also talks about supporting • Attribute Based Access Control • Object attributes such as location • Partial support of Role-based Trust management (RT) • Partial support of security analysis in RT

  27. Conclusion • OWL provides many features that support RBAC, ABAC, RT, and security analysis • It also easily supports nice extensions • Class hierarchy of objects • Reasons • The logical semantics of OWL • Powerful features such as transitive properties, class hierarchy, cardinality constraints, disjoint classes, equivalent classes

More Related