Obligation Standardization David Chadwick, Mario Lischka - - PowerPoint PPT Presentation

Obligation Standardization

Mario Lischka NEC Laboratories Europe

17./18.Nov. 2009 1 Presentation on W3C Workshop, Luxembourg

David Chadwick, University of Kent

Problems with Existing Model

 Obligations have not been handled fully, they are simply

attribute assignments which are consumed by an Obligations Service and must be evaluated simultaneously with the user’s action

 In reality we have 3 different temporal types of

• bligations, Before, With and After each with their own

semantics

 Some obligations need handling by remote systems  Thus multiple places for obligations to be enforced  Many obligations are application independent so don’t

need to handled by the application dependent PEP

 Syntax and semantic of obligations are not specified  Conflicts among obligations are neither specified nor

handled

17./18.Nov. 2009 2 Presentation on W3C Workshop, Luxembourg

Contribution/Proposal

17./18.Nov. 2009 Presentation on W3C Workshop, Luxembourg 3

 Obligation Conceptual Model

 Obligation subject  T

emporal constraints

 Fall backs

 Obligation specification & conflict resolution

Problems with existing XACML obligation model and language

 No standardised parameters for conceptual entities

 Subject to perform obligation  Action to be performed  Target of obligation  Constraints?  Failure Semantics

 No temporal positioning of the obligation

 Before, With or After the user’s action

 No failure semantics

 If obligation fails then Exception/Fall backs/Final Decision

 No ability to direct the obligation to an enforcement subject  No ability to have delayed obligations

 Do X in one week’s time  PEP still needs acknowledgment that the obligation has been recorded 17./18.Nov. 2009 4 Presentation on W3C Workshop, Luxembourg

17./18.Nov. 2009 Presentation on W3C Workshop, Luxembourg 2008/6/13 Slide 5 AppDep PEP App Indep PEP Master PDP Policy PDP Policy PDP Policy PDP 5 6 Will Enforce Conflict Resolution Policy Will evaluate each policy according to the languages they support Will enforce Authz Decisions

• 0. User’s request

Obligations Service 7 8 9 10 11 12 Will coordinate “before”

• bligation

enforcement Obligations Service Will coordinate “with” and “after” obligations Target Resource 13 14 13 14

2a 3 4 1a CVS Will validate presented credentials and pull more AA AA AA 1b 2b

Obligations Service Obligation Service Secure Stable Storage Event Handler Obligation Service Email Service Obligation Service Audit Service Obligation Service Etc.

17./18.Nov. 2009 6 Presentation on W3C Workshop, Luxembourg

Direct communications Indirect communications via sticky policies

Site A

Obligations Service Obligation Service Secure Stable Storage Event Handler Obligation Service Email Service Obligation Service Audit Service Obligation Service Etc. Obligation Service Event Handler Obligations Service Obligation Service Audit Service Obligation Service Etc. Stable Storage Obligation Service Email Service Obligation Service Event Handler Obligations Service Obligation Service Audit Service Obligation Service Etc. Stable Storage Obligation Service Email Service

Site C Site B

17./18.Nov. 2009 7 Presentation on W3C Workshop, Luxembourg

17./18.Nov. 2009 Presentation on W3C Workshop, Luxembourg 8

Obligation Specification

 Schema which allows the description of obligations  Specification of generic obligations used in the

policies

 Negotiation of supported obligations between PDP and

PEP Examples for Types of Obligations

 resource control (read/write locks, logging)  Obfuscation/Transformation  Dynamic process workflow

Obligation Schema Policy Schema (new version) Policy Schema (current version) extension inclusion based on based on Policy Specification Policy Specification Policy Specification Obligation Specification Obligation Specification Obligation Specification refers to

Obligation on granted (or denied access) are recognized in XACML, but specification is completely open → Problems as Obligations Service (PEP) and Obligation Writer (PDP/PAP) should agree how to handle Obligations

17./18.Nov. 2009 Presentation on W3C Workshop, Luxembourg 9

Initialization of Obligation Handling

 PEP/Obligations Service and PDP

can agree on common obligations supported by each side

 pre-check of supported obligations

Request supported Policy Specification Obligation Specification

PDP PEP

read supported Reply Obligation

 PDP does not have to analyze the obligation semantic/ only works on syntactical

level



PDP can verify the support of obligation during parsing of the policies



implementation parsing verification could be done generic i.e. independent of the

• bligations used in any instance



additional obligation could be specified without modification of the PDP

17./18.Nov. 2009 Presentation on W3C Workshop, Luxembourg 10

Conflicts

 Conflict detection

 on the set of combined obligations  Based on Specification of conflicts

 Generic Conflict resolution for

 Inclusion  Subordinated/super-ordinated

 Relation between Obligations

 Unrelated  Conflict  Contradiction  Inclusion,  subordinated/super-ordinated

 Conflict between two

• bligations defined on

 as general  partial obligation values  all obligation values

Conclusion

17./18.Nov. 2009 Presentation on W3C Workshop, Luxembourg 11

 temporal types of obligations (Before, With and After) are

required

 Obligations handling by remote systems, enforcement at

multiple places

 Syntax and semantic of obligations and relation among

them have to be specified