Discusión de los resultados

For accessing federated services from a SAML SP using a PPIdP, the PPIdP needs to be fed- erated with the SP by utilising the previously described mechanisms for creating a dynamic federation. The protocol flow for creating such a federation and accessing services from the PPIdP is illustrated in Figure 6.6 and is discussed below:

1. First, a PPIdP needs to create a Type 1 PIF with an SP. For this, the user visits the PAS of the PPIdP and generates a temporary code.

2. The user visits the SP and she is forwarded to the WAYF page of the SP. Therefore, the user is presented with a form to allow her to create a dynamic federation.

6.4. Prototype Implementation 116

6.4. Prototype Implementation 117

3. The user inputs the entity ID of the PPIdP along with the temporary code.

4. The previously described mechanism for exchanging metadata takes place and in the end, the PPIdP and the SP becomes a part of the PIF.

5. The user visits the SP using her preferred mobile browser.

6. The SP forwards the user to the WAYF Page where she chooses the PPIdP.

7. The SP creates a SAML authentication request and forwards the request to the PPIdP. As discussed before, the request is submitted automatically to the locally hosted PPIdP using an embedded XHTML form and JavaScript.

8. The respective end point of the PPIdP receives the request and presents a login form to the user.

9. The user logs in using her username/password.

10. Once the authentication is successful, a form with all user attributes is presented to the user. The PAS has the option to create a pre-configured Attribute Release Policy (ARP) for any specific SP using the Set/Reset/View/Edit Authorisation option of the PAS main control panel (Figure 6.2). The PPIdP will use the ARP to filter out any attributes before they are shown to the user. The user selects the attributes that she wants to release to the SP and clicks the Submit button.

11. A SAML assertion including the selected attributes is created and returned to the SP.

12. The SP validates the assertion, retrieves the user attributes and makes an authorisation decision with respect to the user accessing the requested service (Figure 6.7).

Since the PPIdP has been federated with the SP using the mechanism of a dynamic feder- ation, the SP must treat it as an untrusted entity even if the IdP acts honestly. In this way, the SAML implementation of the IdP will essentially act equivalently to OpenID. Thus, this technique will be suitable for general SPs which do not require user attributes coming from a highly trusted IdP. Interestingly, some attributes (such as credit card information) are self- certifiable. It does not matter if they are coming from a highly trusted IdP or an untrusted IdP since the SP can verify the authenticity of those attributes, and hence use them to decide whether to allow users to access sensitive services.

Another scenario has been deployed in which the PPIdP can be federated with a trusted IdP to create a Type 2 PIF. Here, the fully trusted IdP would act like a Proxy IdP as described in [106] and would delegate the authentication task to the PPIdP which is hidden from the SP. The PPIdP will essentially act as an authentication source for the trusted IdP (Figure 6.8). A SAML IdP and a SAML SP have been deployed using simpleSAMLphp. Their metadata has

6.4. Prototype Implementation 118

Figure 6.7: Released attributes in Type 1 Federation.

Figure 6.8: Two authentication sources at the trusted IdP.

been exchanged beforehand to ensure they are considered fully trusted to each other. The PPIdP has been added to the trusted IdP as an authentication source using the mechanism of dynamic federations. With this setting, the protocol flow for this deployment is illustrated in Figure 6.9 and discussed below:

1. The user visits the SP using her preferred mobile browser to access its services.

2. The user is forwarded to the WAYF page where the user selects the trusted IdP.

3. A SAML authentication request is sent to the trusted IdP and the user is presented with a selection of authentication sources: The PPIdP (Mobile IdP in Figure 6.8) or the trusted IdP itself (example-sql in Figure 6.8).

4. Assuming the user selects the PPIdP, a SAML authentication request is forwarded to the PPIdP and the usual SAML protocol flow takes place.

5. A SAML assertion with the selected attributes is sent back to the trusted IdP.

6. The trusted IdP validates the assertion, retrieves the attributes and creates a SAML assertion with those attributes. To reflect the fact that these attributes have come from the PPIdP, it also inserts a LoA value of 1 for this assertion.

7. A response with the assertion is sent back from the trusted IdP to the SP.

8. The SP validates the assertion, retrieves the attributes and determines if the user is authorised to access the requested service using the released attributes with a LoA value of 1 (Figure 6.10). If the user had chosen the trusted IdP, the assertion would contain a LoA value of 2 to indicate a higher trust on the trusted IdP. This could have allowed users to access more restricted services (Figure 6.11).

6.4. Prototype Implementation 119

Figure 6.9: PIF Type 2 Protocol flow in SAML.

Figure 6.10: LoA 1 for attributes from the PPIdP.

Figure 6.11: LoA 2 for attributes from the trusted IdP.