ROWLBAC08 - Prof. Ravi Sandhu

snufflevoicelessInternet and Web Development

Oct 22, 2013 (3 years and 11 months ago)

95 views

R
OWL
BAC


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