<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
<blockquote type="cite">
<div>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.</div>
</blockquote>
<div><br>
</div>
<div>Ok, good to know. We have a few SPs that have a ton of different ones, but that's a place to start.</div>
<div><br>
</div>
<blockquote type="cite">
<div>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.</div>
</blockquote>
<div><br>
</div>
<div>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?</div>
<div><br>
</div>
<div>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?</div>
<div><br>
</div>
<blockquote type="cite">
<div>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.</div>
</blockquote>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>Thanks,</div>
<div><br>
</div>
<div>Brandon McKean</div>
<div><br>
</div>
<div>On Thu, 2015-08-06 at 15:59 +0000, Cantor, Scott wrote:</div>
<blockquote type="cite">
<pre>On 8/6/15, 9:40 AM, "users on behalf of McKean, Brandon Scott - mckeanbs" <<a href="mailto:users-bounces@shibboleth.net">users-bounces@shibboleth.net</a> on behalf of <a href="mailto:mckeanbs@jmu.edu">mckeanbs@jmu.edu</a>> wrote:
<blockquote type="cite">
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.
</blockquote>
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.
<blockquote type="cite">
2. What would cause the Unsupported Request bit?
</blockquote>
If it says the app isn't registered, that's strictly caused by a failure to find metadata, as far as I recall.
<blockquote type="cite">
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.
</blockquote>
I don't know of any other way to get that error, but ultimately, you have the logs.
<blockquote type="cite">
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.
</blockquote>
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.
<blockquote type="cite">
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.
</blockquote>
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
</pre>
</blockquote>
</body>
</html>