Shibboleth Developers

["David L. Wasley" <>]

Sounds useful.  Here's just a minor thought:  I always worry about "a 
separate URL"  getting out of sync or otherwise being different from 
"the real URL."  Would it be possible to have a "reserved logon ID" 
that would result in performing the checks ("pings") that you suggest 
but at the real URL?  (I hear the flames already but I think it's 
worth considering.)  I don't see why it might be considered dangerous 
- it's just returning information that should be "safe" for public 
consumption anyway.  It also might be easier to maintain, etc.

        David

-----
At 2:54 PM -0500 on 2/2/05, Howard Gilbert wrote:

> 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.