270 likes | 284 Views
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.
E N D
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
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)
Why RBAC? • Role Based Access Control • NIST Standard • Real world success • Extensive academic study
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
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
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
RBAC in OWL: RBAC Ontology Basics • Actions • Subjects • Objects
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
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>
Roles as Classes • OWL specification assigns static and activated roles • Role hierarchy is represented using the class hierarchy
Roles as Classes Role hierarchy is represented upside down by class hierarchy
Roles as Classes • Separation of duty • OWL directly supports ssod and dsod via the OWL property, disjointWith
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
Roles as Classes • Permission-role assignments are supported via rbac:PermittedAction • Domain-specific ontology example:
Roles as Classes • Enforcing dsod constraints • User attempts to create a ActivateRole action Consider all currently active roles
Roles as Values • Roles are modeled as instances of a generic Role class
Roles as Values • Example:
Roles as Values • Role hierarchy • RBAC ontology: • Domain-specific ontology:
Roles as Values • Reasoning about inheritance
Roles as Values • Separation of duty • RBAC ontology: • Domain-specific ontology:
Roles as Values • Detecting separation of duty violations
Roles as Values • Permission-role assignment • RBAC ontology: • Domain-specific ontology:
Roles as Values • Determining whether an action is permitted
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
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
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
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