United Kingdom SAML Detailed Analysis
As described in Figure 1 the GOV.UK Verify protocol contains multiple SAML messages exchanged between the SP, IdP, Hub and MS. These messages will be described in more detail.
Figure 1: Architecture of "GOV.UK Verify" and protocol flow[1]
The AuthnRequest is generated by the SP and sent through the user’s browser to the Hub. According to the profile[2] in Section 2.1.3.3 the AuthnRequest must be signed and sent via HTTP POST Binding. The encryption of the AuthnRequest or parts of it does not take place.
The AuthnRequest is generated by the Hub and sent through the user’s browser to the selected IdP. According to the profile[2] in Section 2.1.3.6 the AuthnRequest must be signed and sent via HTTP POST Binding. The encryption of the AuthnRequest or parts of it does not take place.
During the generation of the AuthnRequest the Hub must define any specific elements that were included in the AuthnRequest received from the SP, e.g. ForceAuth. On the other side, the Hub must exclude parameters revealing the identity of the SP, e.g. Issuer, RelayState.
After the user’s authentication on the IdP, the Response will be generated and sent through the user’s browser to the Hub. According to the profile[2] in Section 2.1.3.8 the Response contains two Assertions, which are first signed and then encrypted. In addition, the Response must be signed. Summarized, the Response can be depicted as follows:
SAML Response = signIdP(Response (encHub(signIdP(Assertion1))) || encHub(signIdP(Assertion2))), where signx(element) means that the element is signed with the private key of X, and
encx(element) means that the element is encrypted with the public key of X.
The one assertion contains a matching data set sent later to the Matching Service (MS) and the second assertion contains contextual information related to the authentication event.
Once the Hub receives the SAML Response from the IdP, it calls the MS to retrieve the identity of the user on the SP, see (Pegman, Cooper, & Dunn, 2015)[2] Section 2.1.3.20. For this purpose, the Hub sends an AttributeQuery request, which is a SAML SOAP message using the SAML SOAP binding.
SAML AttributeQuery = signHub(AttributeQuery (encMS(signIdP(Assertion1))))
The AttributeQuery is signed by the hub and contains the encrypted and signed Assertion needed by the MS to provide the local user matching.
In case that the MS found a match of the user, it generates a SAML Response containing all specified information, see (Pegman, Cooper, & Dunn, 2015)[2] Section 2.1.3.25. The SAML Response issued by the MS contains information about the matched user and his/her identity on the SP in the Assertion.
SAML Response = signMS(Response (encHub(signMS(Assertion))))
The SAML Response must be signed and the Assertion must be signed and then encrypted for the Hub.
The SAML Response sent by the Hub is used to authenticate the user at the SP. With respect to the cryptographic protection of the Response, the documentation can be misled: “To ensure that the assertion is for the specific target SP the Assertion must also be encrypted by the hub service after it is signed using the service provider’s public key.” It is unclear how the Assertion must be signed and especially with which key. We assume that the Response is defined as follows:
SAML Response = signHub(Response (encSP(signHub(Assertion))))
Once the SAML Response is received, the SP verifies it and logs the user in.
1. ^ Team, I. A. (November 2015). Identity Assurance Documentation. Identity Assurance Documentation.
2. ^ ^ ^ ^ ^ Pegman, M., Cooper, A., & Dunn, S. (August 2015). Identity Assurance Hub Service SAML 2.0 Profile v1.2a. Identity Assurance Hub Service SAML 2.0 Profile v1.2a.
