ROWLBAC

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, ltRoleNamegt and ltActiveRoleNamegt

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
  rbacPermittedAction
• 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