The P-PAAS receives user’s (or application’s) requests via an application dependent interface. The format of the interface depends on the application and we do not discuss this here. The application handling user’s interface converts the application request into a standard format
76
before sending the request context to the AIPEP via the PEP. However, we require that all resources are identified by a Resource identifier (RID) by the PEP. It is assumed that either the application requesting to access a resource specifies the RID or the PEP maps the requested resource to a particular RID in the system e.g. by database lookup to find the unique key of an entry. The application also maintains a database for storing the identifying attributes of a resource (e.g. name, RID, owner, location, type etc.) which are discussed in detail in Chapter 4. The application passes the resource attributes which are appropriate to the requested access, to the AIPEP in the request context via the PEP.
After receiving the request context from the PEP, the AIPEP first validates any subject credentials in the request, before passing the (possibly modified) request to the Master PDP. If the request context contains any sticky policy the AIPEP stores it in the policy store (discussed in Section 3.3.2.5) and stores the policy identifier (PID) along with the related information of the policy such as the policy author, language, type (authorisation policy / conflict resolution policy) and so on in the sticky-store before sending the request to the Master PDP. A request context containing sticky policies is presented in Appendix 5.
The Master PDP retrieves the relevant policies and policy related information from the sticky store with the RID from the request context. It then evaluates the conflict resolution policies (identified from the policy type information attached) in the sequence of law, issuer, data subject, controller and the default one (input at configuration time) and gets a decision combining algorithm (DCA) (explained in Section 3.4.2).
The Master PDP enforces all the authorisation policies retrieved with the RID (if any), and the law and controller policies which are specified during the configuration of the system, by calling the appropriate PDP object for each policy based on the policy language information specified. If the PEP’s authorisation request does not contain a RID, then the Master PDP only calls the law and controller PDPs that the system is configured with, and does not call any sticky policy PDPs. The evaluation of each policy in a PDP depends on the policy engine it is configured with. How the PDP does this is of no concern to the Master PDP, since it assumes that every PDP knows precisely how to evaluate the policies that it has been written for (otherwise it would not be fit for purpose). The only requirement that is placed on a PDP is that it can support a standard request and response format. The Master PDP gathers the decisions and obligations returned by the PDPs. It then resolves any conflicts in these decisions, based on the previously selected DCR and returns all the obligations that are associated with the final decision to the AIPEP.
The AIPEP gets the decision with obligations and sees if it can enforce any of the “before” type ones (as discussed in Section 3.3.2.4). The AIPEP enforces an obligation if it has been configured to understand it; otherwise it returns that to the PEP. Since each obligation contains a globally unique ID, then it is trivial for the obligation engine to determine which ones it can enforce. The AIPEP can enforce application independent obligations such as sending an email to someone, attaching a sticky policy to the decision returned by the Master PDP, and writing information to a secure audit trail. How the PEP enforces the remaining obligations depends on the application.
77
3.6 Conclusion
In this chapter, the design of the P-PAAS is discussed. P-PAAS provides a generic infrastructure for providing privacy for various types of personal data based on privacy policies written by a number of authorities, possibly in different policy languages. Access to any data or resource of an organisation can be authorised by this system. The system is capable of storing policies and maintaining a link between the policy and the resource ID so that when a request for a resource (by the RID) is received all the policies related to that RID are consulted for making an authorisation decision. The system allows co–ordination of policies from multiple authorities (law, issuer, data subject and controller) written in different languages and resolving conflicts among them with a sophisticated, automated, dynamic conflict resolution strategy. The proposed strategy allows our system to choose a different combing algorithm based on the request context while allowing the policies written by different authorities to be separate and independent of each other. The separation of policies facilitates the easy integration of policies in a new system while the personal data are transferred to a different system along with them. Furthermore the proposed system allows us to integrate obligations (as a part of policies) written by different authorities which the current XACML policy combining strategy is unable to do. The system is integrated with a new component ConVS that facilitates the contract based access to personal data. Using this component some of the Legal data access rights mentioned in the EU DPD is made automated. The system also provides distributed enforcement of the privacy policies by transferring them along with the data and starting PDP with them so that they can be enforced while taking a decision on accessing that data. The system also enforces the application independent ‘before’ obligations (such as e-mail, secure audit trail) so that the application developer does not need to enforce them and thus it reduces the burden on them. Many other systems might have some of these features but to our knowledge no other system has a combination of all of these features. We do not claim to make each of the components better than other similar one (of fewer) system components, rather we claim that the combinations of all such features are not available in any other one system.
78
Chapter 4
4 Extraction of Machine Executable Rules
From the EU DPD
4.1 Introduction
In order to ensure the enforcement of Legal rules our designed authorisation system, Privacy- Protecting Advanced Authorisation System (P-PAAS), has included a separate Legal PDP (Policy Decision Point) in its architecture. This Legal PDP contains all the authorisation rules obtained from legislation. Having a Legal PDP that is capable of giving automated authorisation decisions helps to enforce the legislative rights automatically. Furthermore, the separation of the Legal PDP helps to prioritise the enforcement of Legal rules so that no other PDP decisions can override the rights mentioned in the Legal PDP. In this chapter we present the research that has been performed on the extraction of the authorisation rules from one particular legislation, the EU DPD (European Union Data Protection Directive) (Directive 95/46/EC 1995), so that a PDP can evaluate those rules to provide automated decisions on behalf of the legislation. We conducted a manual examination of the EU DPD following a structured methodology which is described below, in order to obtain the automated access
control or authorisation rules2 from it. In this chapter, the methodology that we have used to
obtain the authorisation rules from the EU DPD is described.
For the example of obtaining access control rules from legislation, we considered the EU DPD (Directive 95/46/EC 1995) as it contains all the important privacy features. Privacy legislation, on the other hand, of other regions such as the USA is not as strong as the EU DPD. In fact, in the USA there is neither comprehensive privacy law for the private sectors nor a supervisory authority to monitor the privacy protection which the EU DPD has (Fischer-Hubner 2001). The strengths of the EU DPD are discussed in the review of the directive provided to the Information Commissioner’s Office (Robinson, et al. 2009) and some of those strengths are: • sets out the basic framework of data protection in a comprehensive manner.
• sets standards which are widely regarded as “high”. • sets out important and usable rights of humans. • its principles are proven to be stable over time.
79
• is largely neutral in terms of technology.
• has helped to harmonise data protection rules across the European Union and provides an international reference model for good practice.