Obligation Standardization David Chadwick, Mario Lischka - PowerPoint PPT Presentation

Obligation Standardization David Chadwick, Mario Lischka University of Kent NEC Laboratories Europe 1 Presentation on W3C Workshop, 17./18.Nov. 2009 Luxembourg

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 obligations, 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 2 Presentation on W3C Workshop, 17./18.Nov. 2009 Luxembourg

Contribution/Proposal  Obligation Conceptual Model  Obligation subject  T emporal constraints  Fall backs  Obligation specification & conflict resolution 3 Presentation on W3C Workshop, 17./18.Nov. 2009 Luxembourg

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 4 Presentation on W3C Workshop, 17./18.Nov. 2009 Luxembourg

14 Obligations Will enforce Service Authz Decisions 13 0. User’s request AppDep Will coordinate “with” 13 PEP and “after” obligations Target 1a 14 Resource 5 12 2a Will coordinate “before” 10 App Indep obligation Will validate 1b PEP Obligations enforcement 11 presented CVS Service 2b credentials 9 6 and pull more Will Enforce Master 3 Conflict PDP 4 Resolution 7 Policy AA AA 8 AA Policy Will evaluate each Policy PDP policy according to Policy PDP the languages they PDP support Presentation on W3C Workshop, 17./18.Nov. 2009 2008/6/13 Slide 5 Luxembourg

Event Handler Obligation Secure Service Stable Storage Obligations Service Obligation Email Service Service Obligation Audit Service Service Obligation Etc. Service 6 Presentation on W3C Workshop, 17./18.Nov. 2009 Luxembourg

Event Handler Direct communications Obligation Site A Indirect communications via Service Stable sticky policies Storage Obligations Event Obligation Service Email Handler Service Service Site B Obligation Service Secure Audit Obligation Stable Service Storage Service Obligations Service Obligation Obligation Etc. Email Service Service Service Obligation Audit Event Service Site C Handler Service Obligation Obligation Service Etc. Stable Service Storage Obligations Obligation Service Email Service Service Audit Obligation Service Service Obligation Etc. Service 7 Presentation on W3C Workshop, 17./18.Nov. 2009 Luxembourg

Obligation Specification Obligation on granted (or denied access) are recognized in XACML, Policy but specification is completely open Schema (current version) → Problems as Obligations Service (PEP) and Obligation Writer (PDP/PAP) should agree how to handle Obligations extension  Schema which allows the description of obligations  Specification of generic obligations used in the Obligation Policy Schema Schema policies (new version) inclusion  Negotiation of supported obligations between PDP and PEP based on based on Examples for Types of Obligations  resource control (read/write locks, logging) Policy Obligation Policy Obligation Specification Policy Specification Obligation Specification Specification Specification  Obfuscation/Transformation Specification refers to  Dynamic process workflow 8 Presentation on W3C Workshop, 17./18.Nov. 2009 Luxembourg

Initialization of Obligation Handling Policy Specification Obligation  PEP/Obligations Service and PDP Specification can agree on common obligations supported by each side  pre-check of supported obligations supported supported read Request PDP PEP 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  obligations used in any instance additional obligation could be specified without modification of the PDP  9 Presentation on W3C Workshop, 17./18.Nov. 2009 Luxembourg

Conflicts  Relation between Obligations  Conflict detection  on the set of combined obligations  Unrelated  Based on Specification of conflicts  Conflict  Contradiction  Generic Conflict resolution for  Inclusion,  Inclusion  subordinated/super-ordinated  Subordinated/super-ordinated  Conflict between two obligations defined on  as general  partial obligation values  all obligation values 10 Presentation on W3C Workshop, 17./18.Nov. 2009 Luxembourg

Conclusion  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 11 Presentation on W3C Workshop, 17./18.Nov. 2009 Luxembourg