Distributed Privacy Policy Enforcement David Chadwick, Kaniz Fatema - PowerPoint PPT Presentation

Distributed Privacy Policy Enforcement David Chadwick, Kaniz Fatema University of Kent

Scenario • A Subject submits some personal identifying information (PII) along with her privacy policy to a service provider (SP) • An SP user accesses the PII locally at the repository and Subject’s privacy policy is enforced • A third party SP retrieves the PII to its site and the sticky policy encompasses it • If third party SP cannot enforce the sticky policy its authz system refuses to accept the PII

Design Constraints • Minimum of alteration to existing applications that hold PII • Implement as much as possible of the functionality in an application independent authorisation infrastructure • Make it as standards compliant as possible • Release the code as open source • Make is usable by TAS3 project application demonstrators • Use Java as the language since this is where our expertise lies and we have a large amount of existing open source code that can be utilised

Assumptions • The application already holds PII in a proprietary data store • The application already has a protocol for transferring PII and can find an existing field in which to place a sticky policy • The application is able to make a call out to an application independent authorisation infrastructure • Each resource (e.g. PII) that is to be protected has a unique ID (RID)

Components of Advanced Authz Infrastructure • An Obligations Service that can enforce any arbitrary set of obligations (and new Obligation Services can be added to it) • An Application Independent PEP that will provide the new PEP functionality in an application independent way • A Policy Store that stores policies. Each policy is referenced via a unique PID. – Each PDP enforces a set of policies/PIDs • A Sticky Store that maps policies to resources i.e. PIDs to RIDs • A Master PDP that calls multiple subordinate PDPs and resolves conflicts between their decisions

Obligations Service • Coordinates the enforcement of a set of obligations • Because obligations can be enforced at different points and times, multiple Obligations Services are needed • Each obligation needs to say where it should be enforced and when – Obligation needs a Subject (URI of Obligations Service) – Obligation needs a temporal type (before, with, after) • Each obligation has a unique ID and the obligation service that enforces this registers with a particular Obligations Service

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

Will coordinate “with” Advanced Authz Infrastructure and “after” obligations 14 Obligations Will enforce Service Authz Decisions 13 0. User’s request AppDep 13 PEP Target 14 Resource 5 12 Other functions Will coordinate “before” 10 App Indep out of scope of obligation PEP current talk Obligations enforcement 11 Service PID RID 9 6 pid1 rid1 Sticky Will Enforce Master pid1 rid2 Store Conflict PDP …. … Resolution pidn ridm 7 Policy 8 Policy Policy Policy Will evaluate each Store PDP Policy PDP policy according to PDP the languages they support

Subject Submits PII and Sticky Policy 1. Subject enters PII and 13. Store PII Privacy Policy via some PII with Store application dependent GUI RID AppDep Sticky PEP Store 2. Authz Decision Req 11. Store + subject’s privacy policy 12. Granted PID + RID 10. Before obligations App Indep 5. Authz Decision Req Obligations PEP + set of PDPs/Policies to use Service 5. 9 Authz decision plus obligations 4. Create new 3. Store Master PDP instance with policy 8. Resolves conflicts PDP privacy policy 6. 7. Authz decision plus “before” obligations Policy Policy Policy Will evaluate each Store PDP Policy PDP policy according to PDP the languages they support

Third Party Local Access PII 1. User requests acess to 13. Read Store PII via application GUI PII AppDep PEP 2. Authz Decision Req to read PII 12. Granted Sticky 3. Any PIDs for RID? App Indep 7. Authz Decision Req Store PEP + set of PDPs/Policies to use 4. Return PIDs 7. 11. Authz decision plus optional obligations 6. Create new 5. Retrieve Master PDP instance(s) with Policy(ies) 10. Resolves conflicts PDP privacy policies 8. 9. Authz decisions plus optional obligations Policy Policy Policy Will evaluate each Store PDP Policy PDP policy according to PDP the languages they support

Transfer of PII to 3 rd Party SP Obligations 13. Enforce “with” Service obligations 14. Sticky policy 1. Request to retrieve PII 13. Retrieve PII PII AppDep 15. Sticky policy+PII PEP Store 2. Authz Decision Req to Retrieve PII 12. Granted + “with” obligations Sticky 3. Any PIDs for RID? App Indep 7. Authz Decision Req Store PEP + set of PDPs/Policies to use 4. Return PIDs 7. 11. Authz decision plus “with” obligations 6. Create new 5. Retrieve Master PDP instance(s) with policy(ies) 10. Resolves conflicts PDP privacy policy 8. 9. Authz decision plus “with” obligations Policy Policy Policy Will evaluate each Store PDP Policy PDP policy according to PDP the languages they support

Receipt of PII+Sticky Policy by SP 13. Store PII 1. Incoming PII with PII with Store sticky Privacy Policy RID AppDep Sticky PEP Store 2. Authz Decision Req 11. Store + sticky privacy policy 12. Granted PID + RID 10. Before obligations App Indep 5. Authz Decision Req Obligations PEP + set of PDPs/Policies to use Service 5. 9 Authz decision plus obligations 4. Create new 3. Store Master PDP instance with policy 8. Resolves conflicts PDP privacy policy 6. 7. Authz decision plus “before” obligations Policy Policy Policy Will evaluate each Store PDP Policy PDP policy according to PDP the languages they support

Master PDP • Interfaces to language specific PDPs – E.g. TU Eindhoven has a behavioural trust PDP whose language is SWI-Prolog • Uses recently enhanced SAMLv2 profile of XACML as standard interface from AIPEP – E.g. needs to pass sticky policies in any language in and out • Has a conflict resolution policy to determine outcome of multiple conflicting results • Can also supplement result with additional obligations

Master PDP • Has a manifest of all the available PDPs and the policies that they evaluate • Some of these are created at initialisation time, others dynamically by AIPEP • Has a set of conflict resolution policies that tell it which policies/PDPs to use for which resource types. Policies can be ordered or unordered • Ordered, first decision takes precedence – Higher authority overrides lower authority – Specific overrides general – New overrides old • Unordered, then all PDPs are queried and answer is based on rule combining algorithm – Grant overrules deny etc. – Obligations are merged

Conflict Resolution Hierarchy • Higher Authority � Lower Authority • � • Specific � General • � • New � Old • � • Grant � Deny • � • Merge Obligations

Authority Hierarchy What the law says trumps Law everything else Depends on PII e.g. University for Issuer degree, Doctor for Health Record, Subject for favourite drink Data Subject Cannot overrule issuer Keeper

Standard Interfaces • The PEP-AIPEP and AIPEP-Master PDP protocols are an enhanced OASIS "SAML 2.0 Profile of XACML, Version 2.0". Committee Draft 1, 16 April 2009 • The Master PDP – subordinate PDP protocol is the XACMLv2 request-response context • Obligations are encoded as per the XACMLv2 specification • Sticky Policy is a TAS3 specific encoding (at the moment) • Policies can be in any language – XACMLv3 has been enhanced to support policies in any language

Any Questions?