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
• ur 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
• bligations (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
• bligations
• 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
• bligation service that enforces this registers

with a particular Obligations Service

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

Obligations Service

XACML Formatted Obligations

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 Other functions

• ut of scope of

current talk

Advanced Authz Infrastructure

Policy Store Sticky Store

… …. ridm pidn rid2 pid1 rid1 pid1 RID PID

Subject Submits PII and Sticky Policy

AppDep PEP App Indep PEP Master PDP Policy PDP Policy PDP Policy PDP

• 8. Resolves conflicts

Will evaluate each policy according to the languages they support

• 1. Subject enters PII and

Privacy Policy via some application dependent GUI Obligations Service 6.

• 7. Authz decision plus “before” obligations

9 Authz decision plus obligations

• 10. Before obligations
• 12. Granted

PII Store

• 13. Store

PII with RID Policy Store Sticky Store

• 2. Authz Decision Req

+ subject’s privacy policy

• 11. Store

PID + RID

• 3. Store

policy

• 4. Create new

PDP instance with privacy policy

• 5. Authz Decision Req

+ set of PDPs/Policies to use 5.

Third Party Local Access

AppDep PEP App Indep PEP Master PDP Policy PDP Policy PDP Policy PDP

• 10. Resolves conflicts

Will evaluate each policy according to the languages they support 8.

• 9. Authz decisions plus optional obligations
• 11. Authz decision plus optional obligations
• 12. Granted

PII Store

• 13. Read

PII Policy Store Sticky Store

• 2. Authz Decision

Req to read PII

• 5. Retrieve

Policy(ies)

• 6. Create new

PDP instance(s) with privacy policies

• 7. Authz Decision Req

+ set of PDPs/Policies to use 7.

• 3. Any PIDs for RID?
• 4. Return PIDs
• 1. User requests acess to

PII via application GUI

Transfer of PII to 3rd Party SP

AppDep PEP App Indep PEP Master PDP Policy PDP Policy PDP Policy PDP

• 10. Resolves conflicts

Will evaluate each policy according to the languages they support

• 11. Authz decision plus “with” obligations
• 12. Granted + “with” obligations

PII Store Policy Store

• 2. Authz Decision

Req to Retrieve PII

• 5. Retrieve

policy(ies)

• 6. Create new

PDP instance(s) with privacy policy

• 7. Authz Decision Req

+ set of PDPs/Policies to use 7.

• 1. Request to retrieve PII

Sticky Store

• 3. Any PIDs for RID?
• 4. Return PIDs

Obligations Service 8.

• 9. Authz decision plus “with” obligations
• 13. Retrieve PII
• 13. Enforce “with”
• bligations
• 14. Sticky policy
• 15. Sticky policy+PII

Receipt of PII+Sticky Policy by SP

AppDep PEP App Indep PEP Master PDP Policy PDP Policy PDP Policy PDP

• 8. Resolves conflicts

Will evaluate each policy according to the languages they support

• 1. Incoming PII with

sticky Privacy Policy Obligations Service 6.

• 7. Authz decision plus “before” obligations

9 Authz decision plus obligations

• 10. Before obligations
• 12. Granted

PII Store

• 13. Store

PII with RID Policy Store Sticky Store

• 2. Authz Decision Req

+ sticky privacy policy

• 11. Store

PID + RID

• 3. Store

policy

• 4. Create new

PDP instance with privacy policy

• 5. Authz Decision Req

+ set of PDPs/Policies to use 5.

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
• utcome of multiple conflicting results
• Can also supplement result with additional
• bligations

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

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

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?