Testing SAML2 Support

[Cantor, Scott]

On 8/6/15, 9:40 AM, "users on behalf of McKean, Brandon Scott - mckeanbs" <users-bounces at shibboleth.net on behalf of mckeanbs at jmu.edu> wrote:



>1. With respect to testing, is using /idp/profile/SAML2/Unsolicited/SSO?providerId=encoded.url.here&shire=encoded.assertionconsumerserviceurlhere, the correct way to go about it? I've tried so far without the shire bit but I plan to go through and test
> others too.

You shouldn't need the shire parameter most of the time, but if the SP has a lot of vhosts and different endpoints, you might. Don't even ask why it's called that.

>2. What would cause the Unsupported Request bit?

If it says the app isn't registered, that's strictly caused by a failure to find metadata, as far as I recall.

> This same service works fine when logging in through their link that uses the same entityID url according to the logs, and another entityID of the same vendor in the metadata doesn't produce this error.

I don't know of any other way to get that error, but ultimately, you have the logs.

> I do see logs in both cases claiming the metadata backing store doesn't contain any entity descriptions with the ID, but I know for a fact it's in the metadata.

If you see the message when it ultimately finds the metadata and works, then you're confusing a DEBUG log message from one metadata source that doesn't have the entity with the more general problem. What matters is what it ultimately logs as a problem.

>3. Are their SPs configured to just not support this sort of testing? Some just have generic errors after logging in. If so I'm not sure how they would be tested.

If you get an error at the SP, then what you know is you have a problem to look into. It isn't going to just work, and you have to know a lot about SAML and a lot about how to probe for issues to identify what the problem is, or you have to call them and start asking questions.

-- Scott