Testing SAML2 Support

[McKean, Brandon Scott - mckeanbs]

Hi Everyone,

I followed Scott's advice and altered our metadata to just expose a SAML2 endpoint for testing. So far I've been testing this using Shibboleth's Unsolicited SSO, as documented here:

https://wiki.shibboleth.net/confluence/display/SHIB2/IdPUnsolicitedSSO

So far, some of the SPs work with this, some don't seem to like sessions started that way, and one of them even produces an error from our IDP, namely saying the application is not registered for use with the service. A commonality between all of them seem to be that they do publish SAML2 support in their metadata already.

I have a few questions as a result of this.

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.

2. What would cause the Unsupported Request bit? 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 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.

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.

Thanks for any guidance you can provide.




--
Brandon McKean
IT / Systems
Linux Administrator
(540)568-4235
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20150806/76921590/attachment-0001.html>