ROWLBAC – Representing Role Based Access Control in OWL Tim Finin, Anupam Joshi, UMBC Lalana Kagal, MIT Jianwei Niu, Ravi Sandhu, William Winsborough,

ROWLBAC – Representing Role Based Access Control in OWL

Tim Finin, Anupam Joshi, UMBCLalana Kagal, MIT

Jianwei Niu, Ravi Sandhu, William Winsborough, UTSABhavani 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 ClassesRole

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