ROWLBAC Representing Role Based Access Control in OWL

Size: px

Start display at page:

Download "ROWLBAC Representing Role Based Access Control in OWL"

Adrian Stevens
6 years ago
Views:

1 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

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

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

4 Part 1 OWL

5 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

6 OWL

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

8 OWL: Axioms

9 Part 2 N3

10 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" ].

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

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

13 How is the weather in Boston? A Rule: 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 }.

14 How is the weather in Boston? A Rule: 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.

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

16 Part 3 ACCESS CONTROL

17 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

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

19 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)

20 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

21 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

22 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

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

24 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

25 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

26 Part 4 ROWLBAC

27 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.

28 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.

29 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) ].

30 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>.

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

32 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 ] ) ].

33 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".}.

34 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 }.

35 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.

36 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.

37 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.

38 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 }.

39 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.}.

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

41 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

42 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

43 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

44 Take home message

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

46 2. open world assumption creates problems

Semantic Technologies

Semantic Technologies Part 14: Werner Nutt Acknowledgment These slides are based on the Latex version of slides by Markus Krötzsch of TU Dresden W. Nutt Semantic Technologies 2014/2015 (1/66) OWL W. Nutt