Shibboleth user attribute encryption

Question

How does Shibboleth guarantee that 3rd parties do not get access to user attributes contained in SAML 2.0 assertion exchanged between IdP and SP?

Is it correct that all user attributes are encrypted when transferred from IdP to SP? Are the user attributes encrypted with a symmetric key which is also included in the assertion but encrypted with the public key of the SP?

Answer 1

The best I could dig up was here:

https://wiki.shibboleth.net/confluence/display/SHIB2/FlowsAndConfig#FlowsAndConfig-4IdPIssuesResponsetoSP

It looks like security is provided by:

• IdP limits what it gives to the SP based on how it'll be transmitted

• Yes, for SAML 2.0 assertions, the IdP encrypts it's response to the SP

The way this is written, it sounds like encryption is provided specifically on SAML 2.0 assertions, not on everything. And I'm specifically reading the Shibboleth 2.0 documentation as that seems to be what supports SAML 2.0.

Answer 2

I haven't used Shibboleth for a while, so I'm not sure if the following is always the case, but here is how I've used Shibboleth in the past.

The SP makes a (signed) SAML request to the IdP, which is propagated between the two by the user's browser. The IdP gives a signed SAML response, not necessarily encrypted, with an identifier. Upon reception, the SP makes a attribute request directly to the IdP.

This back-end connection is usually done via HTTPS and the connection is therefore encrypted. It doesn't go at all via the user's browser, but the SP becomes a direct client to the IdP. Using message-level encryption on top of SSL/TLS here wouldn't add much, if the SP is properly authenticated of course, this can be done using client-certificate authentication (configured in the SP using CredentialResolver IIRC).

This is represented in steps 6 and 7 in this diagram (UK Federation).

There may be slight differences in the configuration of the Attribute Service (usually run on the IdP and queried by the SP) between Shibboleth 1.x and Shibboleth 2.x. These attribute services are configured along with the other IdP settings as part of the federation metadata given to the SPs.

As far as I'm aware, this mechanism is one of the specificities of Shibboleth, compared with other SAML-based systems.