Shibboleth Developers

[Jim Fox <>]

We generally don't allow 'pings' of any sort from the outside world
to our secure systems.  In a similar vein I doubt we'd want just any
attacker (incorrect metadata) asking our IdPs a lot of questions -
and getting answers.

For the first two shib pings:  When we help a new SP configure we
generally provide them with one or more test userids and passwords.
This allows them to supercede  the "if I redirected..." with a better
"Here's a real login attempt."  Any failure means metadata doesn't match
- as described in detail in the logs.  Likewise the AA test follows,
but again with a real request.  For us at least, any legitimate 'ping'
involves a real SP, who either already has ids to test with, or else to
whom we will give out test ids.

For occasional or continual testing of particular SPs: we do that with
scripts and, again, with 'real' userids and passwords, thus verifying
a complete and legitimate shib login.

Jim


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