Follow

ERROR from IdP logs: Unable to locate satisfiable bearer SubjectConfirmation in
assertion.

2010-05-25 14:36:12 ERROR OpenSAML.SecurityPolicyRule.BearerConfirmation
[5]: bearer confirmation failed with recipient mismatch
2010-05-25 14:36:12 WARN Shibboleth.SSO.SAML2 [5]: detected a problem with
assertion: Unable to locate satisfiable bearer SubjectConfirmation in
assertion.

Details

CAUSE

This relates directly to SSL offloading via Layer 7 switches or similar.

An example subject confirmation:

<saml:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
<saml:SubjectConfirmationData Address="131.181.125.115" InResponseTo="_1253d4aadec1143fe542a6adfbd06206" NotOnOrAfter="2010-05-25T06:09:49.050Z" Recipient="https://mysqp.example.com.au/Shibboleth.sso/SAML2/Artifact"/>
</saml:SubjectConfirmation>

The recipient IdP is sending an entityID value of "https://mysqp.example.com.au". Due to offloading the Shibboleth daemon is generating a comparison string of "http://mysqp.example.com.au" (note the lack of S in http). This obviously fails the match and the assertion is discarded.

SOLUTION

Sometimes, the server runs behind a device that processes SSL, such as a reverse proxy, load balancer or SSL offload appliance. When this is the case, specify the https:// scheme and the port number to which the clients connect in the ServerName directive to make sure that the server generates the correct self-referential URLs. 

Update the Apache configuration element "ServerName" entry.
FROM: http://mysp.example.com.au
TO: https://mysp.example.com.au

Note: This solution may not translate to IIS since it may not support the virtualisation of web server configuration in the same way that Apache does. IIS appears not to have the equivalently configurable item as Apache's ServerName directive.

Links

http://httpd.apache.org/docs/2.2/mod/core.html#servername