ROWLBAC Representing Role Based Access Control in OWL

T. Finin A. Joshi J. Niu R. Sandhu W. Winsborough B. Thuraisingham a presentation by Jeremy Clark ROWLBAC Representing Role Based Access Control in OWL

Introduction This paper examines the relationship between RBAC Role-based Access Control OWL Web Ontology Language

Outline 1. OWL DL + RDFS 2. N3 Rules 3. Access Control in general and RBAC 4. ROWLBAC putting it together

Part 1 OWL

OWL A web ontology language built from DAML+OIL Three species of OWL: OWL Lite SHOIN(D) OWL DL SHIF(D) OWL Full OWL DL + arbitrary RDFS triples

OWL

OWL: Concept Constructors Note: P is property (i.e., role) Can also do things like hasvalue Can use concrete properties

OWL: Axioms

Part 2 N3

N3 Notation3 is a human readable and non-xml language for expressing RDF/RDFS triples. x : C y : D (x,y) : R Is expressed as, :C x R :D y. [ :firstname "Ora" ] dc:read [ dc:title "Moby Dick" ].

N3 Notation3 also includes notation for: Anonymous nodes Renaming/Tags Domain/Range Equivalence Quoting Et cetera...

N3Logic N3Logic extends RDF to allow rule expression. For formulas F, G: F log:includes G F log:notincludes G F log:implies G

How is the weather in Boston? A Rule: Assertions: @forall x, y, z. { x wrote y. y log:includes {z weather w}. x home z } log:implies { z weather w } Bob lives Boston. Alice lives Adelaide. Bob wrote { Boston weather sunny }. Alice wrote { Boston weather cold }.

How is the weather in Boston? A Rule: Assertions: @forall x, y, z. { x wrote y. y log:includes {z weather w}. x home z } log:implies { z weather w } Bob lives Boston. Alice lives Adelaide. Bob wrote { Boston weather sunny }. Alice wrote { Boston weather cold }. Valid Inference: Boston weather sunny.

N3Logic More... F log:supports G F log:conclusion G c log:semantics F c log:says F

Part 3 ACCESS CONTROL

Access Control Given subjects and resources: who gets to access what (and how)? Answer: Access Control Access Control exists at many scales: 1) Computer: Kernel/OS 2) Building: Locks/RFID Cards/Biometrics 3) Organization: Intranet/Branch Communication 4) Internet

Example Access Control Policies Unix filesystem: rwxrwxrwx, chmod, sudo Military classification: Top Secret, Secret, Confidential, Unclassified

Access Control Matrix Printer File Account Network Closet Payroll Jiang 100 pages R/W Deposit Access N/A Alice N/A RO W/D N/A N/A Sanjay Unlimited X N/A N/A N/A Mohammad N/A R/W W/D N/A N/A Carol 200 pages RO N/A N/A N/A Bob 100 pages RO N/A N/A N/A Jerome N/A R/W N/A N/A N/A Kira 100 pages X N/A Access N/A David 200 pages RO W/D N/A Access O(mn)

Using Languages Goal: Optimize among one of these lines Compactness Expressiveness, fine-grain control Fast or easy management: Reasoning, adding new users, revoking users, delegation, etc. Compatibility (cross, backward,...) Ability to enforce

Using Languages Goal: Optimize among one of these lines Compactness Expressiveness, fine-grain control Fast or easy management: Reasoning, adding new users, revoking users, delegation, etc. Compatibility (cross, backward,...) Ability to enforce

Policy Enforcement An access control policy is just words on paper if there is no means to enforce it There are technical limits to what can be enforced There the expressiveness of a policy needs to be constrained to the limits of enforceability

Policy Enforcement Point (PEP) Subject Request Decision Resource Subject Attributes Resource Attributes Environmental Attributes Policy Attributes

RBAC Concepts Subjects and Roles Permissions (anti-permissions) Role Hierarchy Role Assignment, Revocation, and Delegation Role Activation and Deactivation Separation of Duties: 1. Static: Two role assignments are mutually exclusive 2. Dynamic: Two role activations are mutually exclusive

RBAC S,R,P: Subjects, Roles, Permissions PA P R (permission assignment) SA S R (subject assignment) Subjects: 100, Resources: 1000, Permissions: 10 AC List: 1,000,000 Rules Roles: 2, Resource Groups: 4 Generalized RBAC: 80 Rules

Part 4 ROWLBAC

ROWLBAC An effort to combine OWL and RBAC Why OWL? Used in policy languages, want to constrain roles/properties, want translational properties for analysis/execution. Why RBAC? Widely deployed.

T-Box Subject a rdfs:class. Object a rdfs:class. Action a rdfs:class. subject a rdfs:property, owl:functionalproperty; rdfs:domain Action; rdfs:range Subject. object a rdfs:property, owl:functionalproperty; rdfs:domain Action; rdfs:range Object.

T-Box (2) PermittedAction rdfs:subclassof Action; owl:disjointwith ProhibitedAction. ProhibitedAction rdfs:subclassof Action; owl:disjointwith PermittedAction. Action owl:equivalentclass [ a owl:class; owl:unionof (PermittedAction ProhibitedAction) ].

Approach 1 The first approach defines roles as classes: rbac:role a owl:class. rbac:activerole a owl:class. Then we can formulate an A-Box: <RoleName> rdfs:subclassof rbac:role. <ActiveRoleName> rdfs:subclassof rbac:activerole; rdfs:subclassof <RoleName>. <RoleName> rbac:activeform <ActiveRoleName>.

Approach 1 Hierarchical Roles: <RoleName> rdfs:subclassof <SuperRoleName>. Separation of Duties: <RoleName> owl:disjointwith <RoleName>. <ActiveRoleName> owl:disjointwith <ActiveRoleName>.

Approach 1 Add Permission to a Role: SomePermittedAction a rdfs:class; rdfs:subclassof rbac:permittedaction; owl:equivalentclass [ a owl:class; owl:intersectionof ( SomeAction [ a owl:restriction; owl:allvaluesfrom ex:activerolename; owl:onproperty rbac:subject ] ) ].

Approach 1 Enforce Separation of Duties with N3Logic: {?A a ActivateRole; subject?s; object?rnew.?rnew activeform?arnew.?s a?rcurrent.?rcurrent activeform?arcurrent.?arnew owl:disjointwith?arcurrent. } => {?A a ProhibitedRoleActivation; subject?s; object?rnew; role?rcurrent; justification "Violates DSOD constraint".}.

Approach 1 Role Activation with N3Logic: {?ACTION a ActivateRole; subject?subj; object?role.?subj a?role.?role activeform?arole.?arole rdfs:subclassof ActiveRole. } => {?ACTION a PermittedRoleActivation; subject?subj; object?role.?subj a?arole }.

Approach 2 The second approach defines roles as values: rbac:role a owl:class. rbac:role a owl:objectproperty; rdfs:domain rbac:subject; rdfs:range rbac;role. rbac:activerole rdfs:subpropertyof rbac:role. Then we can formulate an A-Box: <RoleName> a rbac:role.

Approach 2 Hierarchical Roles: rbac:subrole a owl:transitiveproperty; rdfs:domain rbac:role; rdfs:range rbac:role. <RoleName> rbac:subrole <SuperRoleName> Separation of Duties: rbac:ssod a owl:symmetricproperty, owl:transitiveproperty; rdfs:domain rbac:role; rdfs:range rbac:role. rbac:dsod a owl:symmetricproperty, owl:transitiveproperty; rdfs:domain rbac:role; rdfs:range rbac:role.

Approach 2 Add Permission to a Role: rbac:permitted a rdfs:property; rdfs:domain Role; rdfs:range Action. rbac:prohibited a rdfs:property; rdfs:domain Role; rdfs:range Action.

Approach 2 Enforce Separation of Duties with N3Logic: {?S role?role1,?role2.?role1 ssod?role2. } => { [] a SSODConflict; subject?s; ssod-role?role1; ssod-role?role2}. {?A a?raction; subject?s.?raction a Action.?ROLE permitted?raction.?s activerole?role. } => {?A a PermittedAction; role?role; action?raction; subject?s }.

Approach 2 Role Activation with N3Logic: # role inheritance. {?S role?r.?r subrole?r2 } => {?S role?r2.}. # activerole inheritance. {?S activerole?r.?r subrole?r2 } => {?S activerole?r2.}.

Comparison Approach 1: More complex but faster DL reasoning Approach 2: More concise but slower rule-based reasoning

Limits to RBAC Subjects: Known and Concrete Roles: Predefined Resources: Predefined and atomic Actions: Predefined and atomic ABAC Attribute-based access control allows for permissions to be granted to sets of attributes

ABAC Example: University member can use any device 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 }. Trouble: Role-value-map which is undecidable

Security Properties Security Properties: Safety and Availability Safety: Can a resource ever be accessed by a role even if a set of changes is made? Availability: Can a resource ever be prevented from access even if a set of changes is made? Restrictions: Grow and shrink restricted roles RT: Distributed trust language with set of 4 rules

Take home message

1. something as seemingly simple as access control runs against the wall quickly

2. open world assumption creates problems