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
Recommend
More recommend
