All entries for Friday 26 July 2013

Shibboleth IdP authentication context class

Yeah, with a blog title like that you’d better get your brain ready.

We recently had an SP whose authentication attempts were failing, and returning no user. We found the difference in the SAML request was that it was requesting a particular authentication context class, which describes what level of logging in a user might be doing, e.g. username/password; username/password + HTTP; Certificate, etc.

The RemoteUser login handler by default doesn’t specify any class, which means it’ll be used if the SP doesn’t ask for anything in particular, but will never match if it does. No problem; we change the value in handler.xml to PasswordProtectedTransport, since we take passwords over HTTPS. But this particular SP still doesn’t work because it’s requesting simply Password and nothing else. The IdP supports multiple values so we just add that value too – it’s a generalisation of the PasswordProtectedTransport so it’s still true to say that we support both.

That fixed it for the SP, but now when logging in through any other SP, the authentication method in the final SAML response is Password, not PasswordProtectedTransport. This might not bother most SPs, but it’s inaccurate so I’d like it to report the “best” method we provide by default. It doesn’t seem to matter what order I specify them in handler.xml. A bit of searching through the documentation gives the answer:

If the IdP is configured for one or more of the methods requested by the SP, then that method may be used. If the Service Provider does not specify a particular method, and the user does not have an existing session, then the default method identified on the relying party’s configuration is used. If no default is identified there, the IdP will choose one of the available methods; the way this choice is made is unspecified and you should not rely on it being the same from release to release.

- https://wiki.shibboleth.net/confluence/display/SHIB2/IdPUserAuthn

So without any default specified in the relying party, the IdP is just picking at random, probably the first alphabetically. I’ve specified PasswordProtectedTransport in the relying party and that’s fixed that; the final SAML response reports that it used PasswordProtectedTransport as the authentication method.

Nick Howes : 26 Jul 2013 14:29 |  Tags: Idp Shibboleth |  Comments (0) |  Close comments |  Report a problem