Previous: Shibboleth: controlling access to resources

In this section I discuss non-trivial issues that arose when I tried to integrate Shibboleth with my IdP. Since I procrastinated too much, I only remember three issues worth noting:

1. Shibboleth considers it an exception when it receives a SAML response with AuthnFailed error code. You get a nasty page that looks like a bug report. The normal workflow is to have user authenticated and deny or allow access based on user’s attributes. If users is known, but access is denied Shibboleth will return a civilized 401 Unauthorized.

2. Message “URL is malformed” may happen if IdP incorrectly handles the RelayState, e.g. base64-encodes it twice. Shibboleth expects RelayState to be in certain format, and when it finds that RelayState is broken, it will say “URL is malformed” without much explanation in the logs. If you see this message, ensure that RelayState that comes back in SAML response is exactly the same as RelayState that was sent in SAML request.

3. Hosts/DNS names are very important, because Shibboleth uses cookies to keep state, and cookies are attached to hosts, not IP addresses. If your secure site is http://mypc.mydomain.com/secure/, but you try to access it via http://localhost/secure, or http://1.23.45.67/secure, it will “almost” work, but Shibboleth cookie will be lost in the redirects, and Shibboleth will land you at http://mypc.mydomain.com/.