Shibboleth 3 SAML Response Debugging

[Cantor, Scott]

On 7/16/15, 12:00 PM, "users on behalf of McKean, Brandon Scott - mckeanbs" <users-bounces at shibboleth.net on behalf of mckeanbs at jmu.edu> wrote:

>I'm equally baffled at this point. I did another test with the v2 IDP against testshib, and it produces an identical result at this point. However as far as testshib is concerned, both IDPs give it information without error.

But I don't know what result you're talking about. Nothing you posted provided that information except for one case which was almost certainly a signature failure, and which was not what you just posted today.

>Since the metadata still referred to SAML1, and most of our providers are using that rather than SAML2, I tried chopping out all SAML2 references from metadata and giving testshib that, to try to force it to use that instead.

Unless you push attributes, there's no way you can test that from a second server without touching the SPs.

>The results are particularly enlightening. While it still passes, the shibd.log results are a lot different. It seems that it tries to make a connection to the production Shibboleth at a different IP:

It does a query to whatever endpoint's in the metadata it has.

>That might explain why it's failing, I had assumed I could fully test it with host file edits.

You can't do that while relying on the back channel for attributes. If you're still on SAML 1 for a majority of services, there is essentially *no way* to test it with SPs you don't control except by pushing attributes.

> Would this explain anything?

I can't correlate "it doesn't work" to a cause. I need specifics.

A failure to get attributes will result, most of the time, in a successful login to an SP with no data. Beyond that, it's entirely dependent on the deployment of the SP what happens.

-- Scott