Role Based Access Control and OWL

Tim Finin, Anupam Joshi (UMBC)
Lalana Kagal (MIT)
Jianwei Niu, William Winsborough, Ravi Sandhu (UTSA)
Bhavani Thuraisingham (UTD)

1 April, 2008



Decentralized Information Group
MIT Computer Science and Artificial Intelligence Laboratory

Overview

• Developed OWL ontologies to represent the NIST RBAC security model
• Used these ontologies to specify and implement access control systems
• Two approaches: roles as classes, and roles as values
• Explored use of OWL for attribute based access control

Motivation

• There have been two prominent themes in security research
  • Formal security models - NIST RBAC (Role Based Access Control), RT (Role-based Trust management), and UCON (Usage Control)
  • Expressive policy languages - XACML, WS-Policy, KAoS, Rei
• A model may not have the machinery to express all the policy details of a given system
• A policy language without ties to a model gives the designer too much freedom and no guidance
• These parallel efforts need to develop synergy to enable the development of security infrastructures with verifiable security properties for emerging open, and dynamic environments.

RBAC Concepts

• Principals or subjects
• Roles
• Permissions and Prohibitions
• Role hierarchies
• Role assignment
• Role activate/deactivate
• Separation of Duty Constraints
  • Static: A person cannot have assignments of two ssod roles
  • Dynamic: A person cannot activate two roles that are in dsod

US Persons Scenario

Two main classes USPerson and ForeignPerson USPerson is further divided into Citizen, Resident, and Visitor and Residents can be either Permanent Residents, Permanent Residency Applicants, or Temporary Residents Instances: Alice & Bob Alice: Citizen and Permanent Resident Bob: Visitor and Temporary Resident

US Persons Scenario

• SSOD: Resident and Citizen
• Alice's assignments violate this because she is assigned Citizen and PermanentResident, which is a subclass/subrole of Resident

US Persons Scenario

• DSOD: Visitor and Resident
• If Bob activates both his roles, Visitor and Temporary Resident, he will violate this DSOD

ROWLBAC - RBAC in OWL

• Common elements
  • Actions: Permitted and Prohibitted Actions
    PermittedAction rdfs:subClassOf Action;
    owl:disjointWith ProhibitedAction.
    ProhibitedAction rdfs:subClassOf Action;
    owl:disjointWith PermittedAction.
    Action owl:equivalentClass [ a owl:Class; owl:unionOf (PermittedAction ProhibitedAction) ].
  • Subjects and Objects
• Two approaches
  • Roles as classes
  • Roles as values

Roles as Classes

• A natural way to represent RBAC roles in OWL is as classes to which individual subjects can belong
• Need 2 classes (Role, ActiveRole) and a property (activeForm) to capture RBAC roles

       rbac:Role a owl:Class.
       rbac:ActiveRole a owl:Class.
       activeForm a owl:FunctionalProperty, owl:InverseFunctionalProperty;
          rdfs:domain Role;
          rdfs:range ActiveRole.

• Example: US Person can be defined as

         USPerson rdfs:subClassOf rbac:Role.
         ActiveUSPerson rdfs:subClassOf rbac:ActiveRole,
            rdfs:subClassOf USPerson.
         USPerson rbac:activeForm ActiveUSPerson.

• Example: Alice is in the Citizen role and has activated it, and Bob is in Visitor and Resident role

         Alice a Citizen, ActiveCitizen.  
         Bob a Visitor, Resident.

• We represent role hierarchies by OWL class hierarchies using rdfs:subClassOf

         Citizen rdfs:subclassOf USPerson.
         Resident rdfs:subclassOf USPerson.
  
         PermanentResident rdfs:subclassOf Resident.
       

Roles as Classes

• Static Separation of Duty: using owl:disjointWith between Roles

  Citizen owl:disjointWith Resident

• Dynamic Separation of Duty: using owl:disjointWith between ActiveRoles

  ActiveVisitor owl:disjointWith ActiveResident

• Associating Permissions with Roles: use OWL class expressions to create classes of permitted or prohibited action

         PermittedVoteAction a rdfs:Class;
            rdfs:subClassOf rbac:PermittedAction;
               owl:equivalentClass [
                 a owl:Class;
                 owl:intersectionOf
                 ( Vote
                   [ a owl:Restriction;
                     owl:allValuesFrom ex:ActiveCitizen;
                     owl:onProperty rbac:subject
                    ]
                   )
                 ] .

Roles as Classes

• Enforcing RBAC policies
  • DL subsumption reasoning to figure out permitted/prohibited actions of a subject
  • Need rules for enforcing static separation of duty and dynamic separation of duty constraints, and for role activation and deactivation

    	   { ?ACTION a ActivateRole;
    	       subject ?SUBJ;
    	       object ?RNEW.
    	     ?RNEW activeForm ?ARNEW.
    	     ?S a ?RCURRENT.
    	     ?RCURRENT activeForm ?ARCURRENT.
    	     ?ARNEW owl:disjointWith ?ARCURRENT. 
    	   } => {?ACTION a ProhibitedRoleActivation;
    	           subject ?SUBJ; object ?RNEW; role ?RCURRENT;
    	           justification "Violates DSOD constraint".}.

  • We use N3Logic for rules, other rule languages could be used

Roles as Values

• Simpler representation than earlier approach
• All roles are instances of a Role class. Use two properties to assign subjects to roles and to activate roles: role and activeRole

         rbac:Role a owl:Class.
         rbac:role a owl:ObjectProperty;
            rdfs:domain rbac:Subject;
            rdfs:range rbac:Role.
         rbac:activeRole rdfs:subPropertyOf rbac:role.
       

• Example: US person

         USPerson a rbac:Role.

• Example: Alice is in the Citizen role and has activated it, and Bob is in Visitor and Resident role

         Alice rbac:role Citizen; rbac:activeRole Citizen.  
         Bob rbac:role Visitor, Resident.
       

• We represent role hierarchies using subRole property, which holds between two roles to state that one is the sub-role (child) of the other (parent)

         rbac:subRole a owl:TransitiveProperty;
            rdfs:domain rbac:Role;
            rdfs:range rbac:Role.

• Example

         Citizen rbac:subRole USPerson.
         Resident rbac:subRole USPerson.
  
         PermanentResident rbac:subRole Resident.
         TemporaryResident rbac:subRole Resident
       

Roles as Values

• Static separation of duty: property called ssod

         rbac:ssod a owl:SymmetricProperty, owl:TransitiveProperty;
            rdfs:domain rbac:Role;
            rdfs:range rbac:Role.
  
         Resident rbac:ssod Citizen. 

• Dynamic separation of duty: similarly defined property called dsod

  Visitor rbac:dsod Resident

• Associating permissions with roles: Two properties, permitted and prohibited

         rbac:permitted a rdfs:Property;
            rdfs:domain Role;
            rdfs:range Action.
         
         Example: Citizen rbac:permitted Vote, Work, JuryDuty. 

Roles as Values

• Enforcing RBAC policies
  • Unable to utilize DL reasoning significantly
  • Role hierarchies, separation of duty, permissions/prohibitions, and role activation require rules
  • Example: permission checking

    	   { ?A a ?RACTION; subject ?S.
    	     ?RACTION a Action.
    	     ?ROLE permitted ?RACTION.
    	     ?S activeRole ?ROLE.
    	   } => { ?A a PermittedAction;
    	            role ?ROLE;
    	            action ?RACTION;
    	            subject ?S }.

ROWLBAC Issues

• Monotonicity
  • Need to record state changes
• Closed world reasoning
  • Eg. if not dsod then permitted role activation

Comparing the two approaches

Beyond RBAC

• The RBAC model is simple, with grants involving
  • Known subjects assigned to a set of pre-defined roles (classes of individuals)
  • A set of atomic objects (e.g., files, DB tables)
  • A small set of predefined, atomic actions (e.g., access, write)
• More elaborate models are of interest, though the security field is conservative by nature
  • OWL has the machinery to support these and more

Attribute-Based Access Control

• Many open applications don’t involve known principals, e.g., pervasive computing
• ABAC associates privileges with a set of attributes associated with an individual
  • e.g., Anyone showing a valid UMBC ID card is allowed to use the UMCP library
• DL makes it natural to generalize this to associating privileges with descriptions of subjects, objects and actions

ABAC Example

• A university member can use any device that is located in her office

         { ?A a rbac:Action;
              rbac:subject ?S;
              rbac:object ?O.
            ?S a UniversityPerson; office ?L,
            ?O a Device; location ?L.
         } => { ?A a rbac:PermittedAction }.
       

• Note the use of a 'equality role-value-map', which seems natural in such examples. This is not currently supported in OWL, but is part of other DL-based systems

Assuring Dynamic Security Properties

• We’d like to prove that certain security properties hold (or do not hold) given a policy
• And to do so even as changes are made, e.g., adding new subjects & objects, (re-) assigning subjects to roles, delegating rights, etc.
• An Administrative policy may constrain what changes can be made
  • E.g., only an Admin can assign to the HR Manager role

Verifying Security Properties

• Security properties characterize reachable states
  • Safety: can someone outside the company ever access the secret plans?
  • Availability: can anyone besides me prevent my guys from accessing the current build?
• Need techniques to evaluate
  • Efficient algorithms
  • Model checking can sometimes give useful information for properties that are in general intractable
• Administrative models should be designed with an eye to efficient evaluation of security properties

Example: RT Language

• RT is a simple distributed trust language in which a subject can define her own rules (e.g. friend, co-worked) and make simple assignments to them via rules
It has four kinds of rules

1 alice.friend <- bob                         ;Bob is a friend of Alice
2 alice.friend <- bob.friend                  ;Alice's friends include Bob's friends
3 alice.friend <- carol.enemy.enemy           ;..and Carol's enemies' enemies
4 alice.friend <- umbc.student & iit.alumnus  ;..and UMBC students who are IIT alumni
     

• RT rules of types 1, 2 and 4 can be easily encoded in OWL. Type 3 rules require role chains, another DL feature not currently in OWL

RT Policy Example

HQ.marketing <- HR.managers
HQ.marketing <- HQ.stales
HQ.marketing <- HR.sales
HQ.marketing <- HQ.marketingDelg ^ HR.employee
HQ.ops <- HR.managers
HQ.ops <- HR.manufacturing
HQ.marketingDelg <- HR.managers.access
HR.employee <- HR.managers
HR.employee <- HR.sales
HR.employee <- HR.manufacturing
HR.employee <- HR.researchDev
HQ.staff <- HR.managers
HQ.staff <- HQ.specialPanel ^ HR.researchDev
HR.manager <- Alice
HR.researchDev <- Bob

Growth and shrink restricted roles: HQ.marketing, HQ.ops, HR.employee,
HQ.marketingDelg, HQ.staff

Research Challenges

• We hope to study how to build policy systems using Semantic Web languages and associated reasoners along with FSM representations and model checking that support
  • Using OWL to model domain concepts and constraints
  • RIF-compatible language to encode policy rules
  • DL reasoning for enforcement decisions
  • Policy design-time analysis to assure security properties using model checking techniques

More Information

• This presentation: http://dig.csail.mit.edu/2008/Talks/0401-OWLED-lk/
• Running examples: http://dig.csail.mit.edu/2007/rowlbac/

Why OWL ?

• SW-based policy languages allow policies to be described over heterogeneous domain data and promote common understanding among participants who might not use the same information model
• OWL is a W3C standard and has been widely widely used for defining domain vocabularies
• OWL has not been specifically designed for expressing authorization policies
• But has been used for this purpose in previous work such as KAoS and Rei