Testing SAML2 Support

Thu Aug 6 16:12:44 EDT 2015

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.

Ok, good to know. We have a few SPs that have a ton of different ones, but that's a place to start.

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.

I believe you're right here. Thanks for pointing that out, I do see the line a couple times which would be consistent with metadata sources. I don't suppose it's possible to have Shibboleth specify which metadata store it is referring to in those type of errors?

Anyway, taking a fresh look at the log with what you've noted in mind, I notice a line mentioning, in part, "...Metadata document does not contain a role of type {urn:oasis:names:tc:SAML:2.0:metadata}SPSSODescriptor supporting protocol urn:oasis:names:tc:SAML:2.0:protocol for entity..." I'm suspecting that means that this SP does not publish SAML2 support in their metadata, and Shibboleth is essentially saying that it can't find SAML2 metadata to use to handle the request?

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.

Good to know. I'll have to get my line of questioning in order on that though. I'm guessing it will largely consist of asking them what their logs show and working something out from there? I've never contacted a vendor in this capacity so I'd just like an idea of what I'll be getting into.

Thanks,

Brandon McKean

On Thu, 2015-08-06 at 15:59 +0000, Cantor, Scott wrote:

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20150806/0dbb21bd/attachment-0001.html>