Shibboleth Developers

["Howard Gilbert" <>]

In Monday's conference call I was asked to circulate a more complete proposal:

 

When a Shibboleth ID Provider or Service Provider is initially configured, there are a number of potential configuration errors that are hard to test. They require that the configuration of remote sites agrees with your Metadata, and that Credentials at remote sites agrees with your Trust.

 

However, at any given moment everyone is connected through the Internet, so it should be possible to connect a Browser to a Servlet and test the connectivity implied by the Metadata.

 

The testable elements are the SSO IDP (formerly the HS), the AA, and the Authentication Assertion Consumer (formerly SHIRE). At least these seem to be the remote URLs that you can get out of Metadata that are worth "pinging".

 

In this context, a "ping" is either a differently named URL or a differently formed request. We can debate this later.

 

The SSO IDP is a URL to which the WAYF can redirect a Browser. However, in normal use it is interactive, requires a userid and password, and then comes back to the SHIRE URL. The proposal is that there be another form of the URL to which you can essentially ask the question, "If I redirected a Browser to your real service URL would you be able to perform a Shibboleth logon". If the connection times out, or the response is 404, or the data returned is unrecognized, then the Metadata was wrong.

 

There is a second check that can be included in the same transaction. A real Redirect to the SSO IDP includes the SP Entity identifier and the SHIRE (Authentication Assertion Consumer URL).  It also contains a target=, but that doesn't get checked by anyone. However, the IDP plausibly will look in its Metadata to find an entry for the SP Entity name, and then it might (must? Its not clear) match the SHIRE URL to the endpoint of one of the Authentication Assertion Consumer entries in the Metadata. So these two parameters might be added to the previous request, and the response could then be checked for Metadata inconsistency errors (my Metadata doesn't match your Metadata).

 

There is a third check that can be included. There is no particular format required of the response, but I can imagine that SAML is a good choice. I would propose that the success message be signed (if possible). I see no reason why it not be the same response to all successes, so the nobody will get much information about the signing key from the ability to get one signed constant message from a network URL over and over again. However, this gives a real SP the opportunity to validate the private key the IDP got from its Credentials against the public key the SP gets from its Trust.

 

Now consider roughly the same exchange for an AA. Ideally, I create SAML Request that requests no attributes about anyone in particular, sign some constant part of it, send it to the configured AA URL, and get back (if successful) an empty Response with no attributes for nobody but with some similarly signed constant piece.

 

These two checks are Service Provider driven. There is a corresponding IDP side sanity check, but it is a bit more controversial.

 

I would propose some code that goes through the IDP Metadata looking for Authentication Assertion Consumer URLs. The test code then generates a special format transient Authentication Assertion that it can POST (over a Commons HTTPClient class, not using a real Browser). Essentially it says "Nobody in particular wants to logon to a completely temporary session for which you will fetch attributes and then toss the entire thing away, and by the way there is no target=". As indicated, the SP processes the request, immediately requests Attributes for the dummy user from the AA (no lazy sessions here), then discards the Session object and returns a success indicator in response to the POST. Plausibly the Authentication Assertion, Attribute Request, and Attribute Response could contain signed constants to test Credentials and Trust at both ends.

 

At either end, at the end of the test the administrator is presented with a Web page with a list of the Entities and Endpoints tested and any failure reasons. He gets to diagnose configuration problems at once rather than finding them piecemeal as users complain that particular institutions are not responding properly.