CONCLUSIONES Y RECOMENDACIONES Este apartado recoge las principales conclusiones que

The high level conceptual mode described in Chapter 3 treats the authorisation service as a black box with a set of defined functionalities. The most important component at this level is the specification of the standard protocol that will be used to communicate with the authorisation service. The application developers will use this protocol for sending the request to the authorisation system (assumption 5 of Section 3.2). The policy needs to be passed dynamically along with the decision request to the authorisation service so that the data subject, or the application acting on her behalf, does not need to access the PAP for storing the policy prior to the authorisation decision. The chosen protocol should be able to pass policies in any policy language (assumption 1 of Section 3.2) along with the request context. The inability of the XACML request/response context to pass policies makes this OASIS standard (XACMLv2 2005, XACMLv3 2013) unsuitable for this purpose. However, the SAML 2.0 Profile of XACML, Version 2.0, Committee Specification 01, 10 August 2010 (SAML2.0 2010) does allow policies and credentials to be securely transferred with a request context, so this was chosen as the best fit for our requirements. However, this protocol has one major drawback in that it only supports policies written in the XACML policy language, and we required support for multiple policy languages. Professor Chadwick, who is a member of OASIS, therefore entered into discussions with the OASIS XACML working group about adding support for multiple policy languages to the SAML 2.0 Profile. After much discussion the

working group agreed in 2011 to add this support to the SAML 2.0 profile by adding an extension to it (see Table 5.1). The revised Committee Specification was eventually published in August 2014 (SAMLv2.0 2014).

Table 5.1: Schema for SAML 2.0 elements used for passing policy to AIPEP (2014

version)

http://docs.oasis-open.org/xacml/3.0/xacml-3.0-profile-saml2.0-v2-schema-protocol-wd-13.xsd

</sequence>

</complexContent> </complexType>

<element name="Extensions" xsi:type="xacml-samlp:ExtensionsType"/> <complexType name="ExtensionsType">

<sequence>

<any namespace="##any" processContents="strict" minOccurs="0" maxOccurs="unbounded"/> </sequence>

</complexType>

In the SAML profile of XACML a new element called XACMLAuthzDecisionQuery has been defined which allows the PEP to combine the XACML authorisation decision request with the policy that is to be used by the PDP. This facility is helpful for enforcing sticky privacy policies where the PDP needs to be told which privacy policy to use for taking the access decision. The new Extensions element, shown in bold in Table 5.1, allows policies in languages other than XACML to be passed along with the request context. The SAML assertion XACMLAuthzDecisionStatementType (not shown) allows the XACML response context to optionally contain obligations and to be returned as a SAML response. This also facilitates the enforcement of privacy by including obligations with the access decision.

Table 5.2 shows an example request context for passing a sticky policy in the PERMIS policy language to the authorisation service along with the authorisation request. The resource attribute “rid” defines the RID of the resource to be access controlled (as defined in Section 3.3.2.5). The value “SUBMIT” for action attribute “action-id” indicates that this request is for submitting some new personal data (identified by the RID) along with a sticky policy to the authorisation service. The <Extensions> element contains the sticky policy as a <StickyPolicy> element. In the <StickyPolicy> element the PolicyID attribute is the PID (as defined in Section 3.3.2.5) and the PolicyLanguage attribute defines the policy language to use whereas the

<PolicyContents> contains the actual policy written in the specified language.

Table 5.2: An example request context for passing a PERMIS policy to the AIPEP

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"> <soapenv:Header/> <soapenv:Body> <XACMLAuthzDecisionQuery xmlns="urn:oasis:names:tc:xacml:2.0:profile:saml2.0:v2:schema:protocol:cd-01" ID="A2010-12-13T12.58.12" Version="2.0" IssueInstant="2010-12-13T12:58:12.209Z"> <xacml-context:Request xmlns:xacml-context="X"> <xacml-context:Subject xmlns="X"> </xacml-context:Subject> <xacml-context:Resource xmlns="X"> <xacml-context:Attribute AttributeId="rid" DataType="Y#string"> <xacml-context:AttributeValue>LC01</xacml-context:AttributeValue> </xacml-context:Attribute> </xacml-context:Resource> <xacml-context:Action xmlns="X"> <xacml-context:Attribute AttributeId="action-id" DataType="Y#string"> <xacml-context:AttributeValue>SUBMIT</xacml-context:AttributeValue> </xacml-context:Attribute> </xacml-context:Action> <xacml-context:Environment xmlns="X"/> </xacml-context:Request> <Extensions><sp:StickyPolicy PolicyID="PID123” PolicyLanguage="PERMIS" PolicyType="Authorization" TimeOfCreation="2010-08-09T00:00:00Z" xmlns:sp="http://sec.cs.kent.ac.uk/stickypolicy"> <sp:PolicyAuthor> <sp:AuthorType>DataSubject</sp:AuthorType> </sp:PolicyAuthor> <sp:PolicyResourceTypes> <sp:ResourceType>personal:preferences</sp:ResourceType> </sp:PolicyResourceTypes> <sp:PolicyContents> <SubjectPolicy> <SubjectDomainSpec ID="everywhere"> <Include LDAPDN=""/> </SubjectDomainSpec> </SubjectPolicy> <RoleHierarchyPolicy>

</RoleSpec>

</RoleHierarchyPolicy> <SOAPolicy>

96 <Delegate Depth="0"/> <SOA ID="anyone"/> <Validity/> </RoleAssignment> </RoleAssignmentPolicy> <TargetPolicy> <TargetDomainSpec ID="UK"> <Include LDAPDN="c=gb"/> </TargetDomainSpec> </TargetPolicy> <ActionPolicy>

<Obligation ObligationId=”http://sec.cs.kent.ac.uk/obligations/AttachStickyPolicy” FulfillOn="Permit"/> </Obligations> </TargetAccess> </TargetAccessPolicy> </X.509_PMI_RBAC_Policy> </sp:PolicyContents> </sp:StickyPolicy> </Extensions> </XACMLAuthzDecisionQuery> </soapenv:Body> </soapenv:Envelope > X= urn:oasis:names:tc:xacml:2.0:context:schema:os Y= http://www.w3.org/2001/XMLSchema

In order to transfer the data and policy together between the user’s client and the application, or application to application, we defined the StickyPAD schema, which is presented in Appendix 9. For the implementation of the sticky transfer mechanism (Chadwick and Lievens

2008) we used the Application Protocol Enhancement Model, whereby the PEP augments the

existing application protocol to make it capable of sending data with policies. The authoritative source combines the data/resources and policies together and signs the combined elements. The digital signature could be the XML signature defined in the StickyPAD or an externally provided one e.g. by using SSL/TLS to transfer it.

The protocol used for communicating between the AIPEP and the CVS is based on WS-TRUST (OASIS 2007) and SAMLv2 (SAMLv2.0 2010) and is documented in the OGF specification (Chadwick and Su 2009). Once the CVS has finished validating the subject’s credentials, these are returned to the AIPEP as XACML formatted attributes and passed to the Master PDP. We needed to choose a standard API between the AIPEP and the Master PDP. Since policies are being passed with the SAML-XACML protocol and the AIPEP is storing the policy in the policy store, then we do not need to consider passing the policy via the API. There are a

number of PDP APIs available, for example, the C authorisation API (Authorization C API Developer Reference 2003), the XACML Java API (Sun's XACML Implementation 2006) and the PERMIS Java API (Otenko, Chadwick and Thornton 2002). We chose to use the XAMCL API as it is only API that has come from a recognized standards organisation, OASIS.

Due to the deadline of the EU TAS3 project (an IST FP7 funded Integrated Project) which funded this research, the complex design needed to be implemented in a short period of time and that required help from other project team members. The majority of the implementation of the authorization service was done by Dr. Stijn Lievens and can be found on (PERMIS Standalone Authorisation Server 2011). The authorisation system is implemented as a web service running in a servlet container (Apache Tomcat). The portions of the system that are implemented by the candidate, namely the PEP and Contract Validation Service, are described in the next sections. Here a brief description is presented for the configuration of the authorisation service.

5.2.1.1 Configuration of the authorisation service

The administrator of an organisation willing to use the authorisation service needs to download it from our open source repository (PERMIS Standalone Authorisation Server 2011). After installing the authorisation service the administrator needs to configure it. The administrator has full control over 1) the database configuration 2) the obligations service configuration and 3) the Master PDP configuration.

In the database configuration the administrator defines where to store the sticky policies. It can be a file system or a relational database. To use a file system backed storage the following two attributes have to be used: “directory” and “filePath”. The directory attribute should give an existing (writable) folder on the file system which is the policy store defined in 3.3.2.5. New sticky policies will be stored inside this folder with a file name that is a (SHA-1) hash of the sticky policy’s identifier. The filePath attribute should give a file that contains the mapping between resource identifiers and sticky policies, which is the sticky store defined in 3.3.2.5. When a relational database is used the database configuration simply points to a configuration file containing the necessary information to connect to the database.

The MasterPDPConfiguration element allows configuring the actual PDPs that will be used by the AIPEP. The administrator needs to specify the locations of the Legal and controller’s access control policies and the conflict resolution policy, along with the PDPs to use them (e.g. PERMIS PDP or XACML PDP). When the LegalPDP or ControllerPDP element is missing, this is interpreted as having a PDP that always returns NotApplicable.

The optional ObligationsServiceConfiguration element allows the administrator to specify their own obligations.

In document VALORACIÓN DE LA SOSTENIBILIDAD DE LA ACUICULTURA EN ESPAÑA (página 88-102)