Son funciones de las Secciones Departamentales:

TÍTULO III. ORGANIZACIÓN DEL CONSEJO

Artículo 10.- Son funciones de las Secciones Departamentales:

An application is implemented with PHP which provides a user interface at the front end and the PEP at the back end for calling the authorisation service using the right protocol on behalf of the user (or user’s application). This PHP application runs under an Apache web service and

calls the authorisation service using the SOAP protocol. The application performs the following functionalities –

i) When it is provided with an access request in SAML-XACML it passes the request via

the PEP to the authorisation system which is running as a web service in another machine using the SOAP protocol and gets the response from that.

ii) When it receives a data item (along with the policy) to store, it assigns a locally unique

RID (Resource Identifier) to identify the resource and passes an authorisation request to the AIPEP via the PEP with the policy. When it receives a Grant response it stores the data and the resource attributes (such as, resource type, validity time, identity attributes of the issuer and the data subject) in a MySQL table.

iii) When a request for accessing a data item identified by a specific RID is received it makes a MySQL query to retrieve the resource attributes attached to that resource. It formats each of the resource attributes to place them in the SAML-XACML request context. It then passes the request context to the authorisation system’s AIPEP via the PEP with a SOAP call. After receiving the Grant (or Deny) response from the AIPEP, it either retrieves the Data (with the RID) and passes that to the requester or sends a Deny to the requester.

iv) When it receives an access request for any personal data item along with a signed

digital contract it calls the ConVS to validate the contract. When it receives a response from the ConVS it formats the received data to form attributes of the SAML-XACML request context and passes the request context to the AIPEP via the PEP. The application/ the PEP also does necessary changes to the attributes’ names to match with the attributes presented in the policy. For example, in the policy the Resource- Type attribute obtained from the contract is named as ContractResourceType to avoid confusion with the ResourceType obtained from the stored resource attributes of the requested resource. Therefore, the ResourceType attribute obtained from the contract is renamed as ContractResourceType. Similarly, the E-mail address of the first signer of contract obtained from the ConVS is renamed by as <ContractPartyOne’sE- mail> and the E-mail address of the second signer of contract is renamed as <ContractPartyTwo’sE-mail>.

v) Since the application is also intended to provide an interface to receive policies (in the

form of preferences) from the user, based on a scenario of registering a person for a medical service at a medical service provider, a set of XACML policies is prepared. When a user registers at a medical service provider (e.g. Kent Health Centre) the person is provided with an electronic form, mainly with tick boxes, for giving his/her choices about who can access his/her medical record. Each of these tick boxes is converted into machine executable XACML policies as shown next.

Figure 5-1. Conversion of choices (from tick boxes) into an XACML policy set

The user registers with the Kent Health Centre for getting services from it. The user first authenticates him/herself to the Kent Health Centre and then is given a registration form. During registration, the person is also given an electronic policy preference form (with tick boxes) which presents some options to choose about allowing others to access his/her medical data. These choices are converted into machine executable policies using the XACML policy language. In this example scenario the person is given 6 options (see Figure 5-1) to choose from to indicate with who he/she wants to share his/her medical data. The options are –

1. Dr. _ _ _ of Kent Health Centre 2. Any Dr. of Kent Health Centre 3. Dr. of other organisation _ _ _ . 4. Health Insurance Company _ _ _. 5. Researcher

100

6. Other Organisation _ _ _.

Some of these options contain spaces for providing extra information such as the name of a Dr., the name of another organisation and so on.

There is a pre-defined policy for each of these choices. Depending on the person’s choices the policies are combined into a policy set and used in the data subject’s PDP. For example if a person only chooses policies no 1 and 3, then only 1 and 3 will be put into the final policy set and be used in the data subject’s PDP. If the person chooses option no 1 and writes the name of Dr. D in the space provided for that option then the XACML policy is formed as the policy presented in Table 5.3. This grants READ access to ResourceType =medical data to a subject with Name=Dr. D, working for Organisation Kent Health Centre with a Role of Medical Professional.

Table 5.3: Policy for option 1

<Policy PolicyId="PolicyNo1forMedicalData"

RuleCombiningAlgId="urn:oasis:names:tc:xacml:1.0:rule-combining-algorithm:deny-overrides"> <Target/>

<Description>Medical Professional of this organisation can read the medical data </Description> <Target>

<SubjectMatch MatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal"> <AttributeValue

DataType= "http://www.w3.org/2001/XMLSchema#string">Medical Professional</AttributeValue>

</Subject> <Subject>

<SubjectMatch MatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal"> <AttributeValue

DataType="http://www.w3.org/2001/XMLSchema#string">Kent Health Centre</AttributeValue> <SubjectAttributeDesignator AttributeId="Organisation" DataType="http://www.w3.org/2001/XMLSchema#string"/> </SubjectMatch> </Subject> <Subject> <SubjectMatch MatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal">

<AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">Dr. D</AttributeValue>

101 <ActionMatch MatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal"> <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">READ</AttributeValue> <ActionAttributeDesignator DataType="http://www.w3.org/2001/XMLSchema#string" AttributeId="urn:oasis:names:tc:xacml:1.0:action:action-id"/> </ActionMatch> </Action> </Target> </Rule> </Policy>

When the user chooses option 5 to allow a researcher to access his/her medical data, an obligation is added in the policy to anonymise the data. The user can be informed about this in the form. Option 5 creates the policy presented in Table 5.4.

Table 5.4: Policy for option 5

<Policy PolicyId="PolicyNo5forMedicalData"

RuleCombiningAlgId="urn:oasis:names:tc:xacml:1.0:rule-combining-algorithm:deny-overrides"> <Target/>

<Rule RuleId="MedicalDataAccessByReseracher" Effect="Permit"> <Description>Researcher can read the medical data </Description> <Target>

<AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">Reaseracher</AttributeValue> <SubjectAttributeDesignator AttributeId=Role DataType="http://www.w3.org/2001/XMLSchema#string"/> </SubjectMatch> </Subject> </Subjects> <Resources> <Resource> <ResourceMatch MatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal">

<AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">Medical Data</AttributeValue> <ResourceAttributeDesignator DataType="http://www.w3.org/2001/XMLSchema#string" AttributeId="ResourceType"/> </ResourceMatch> </Resource> </Resources> <Actions> <Action> <ActionMatch MatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal"> <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">READ</AttributeValue> <ActionAttributeDesignator DataType="http://www.w3.org/2001/XMLSchema#string" AttributeId="urn:oasis:names:tc:xacml:1.0:action:action-id"/> </ActionMatch> </Action> </Target> </Rule> <Obligations>

</Policy>

When these 2 policies are put into one policy set it creates the full policy in XACML as presented in Table 5.5. The default policy combining rule is DenyOverrides. It can also be obtained from the data subject by providing him/her with a set of policy combining algorithms

102

(such as FirstApplicable, DenyOverrides, PermitOverride and so on) to choose from and the chosen combining algorithm can be used to combine the chosen policies.

Table 5.5: Combined policy from option 1 and 5

User friendly interfaces and comprehensible texts can be provided with the options, so that the user can understand the options he/she is choosing without worrying about the complex policy languages underneath.

In document ÍNDICE REGLAMENTO DE RÉGIMEN INTERNO DEL CONSEJO DE DEPARTAMENTO DE ANATOMÍA, BIOLOGÍA CELULAR Y ZOOLOGÍA DE LA UNIVERSIDAD DE EXTREMADURA.. (página 43-46)