Relying Party - Common Error
740 views
Skip to first unread message
Chuck Kimber
Jul 26, 2011, 6:14:07 PM7/26/11
to us...@shibboleth.net
I've been trying to troubleshoot this one for a while now and need another pair of eyeballs, I guess.
This is a third-party SP, so I have no direct access to it and it appears to be a home-brewed SAML2 system, not a Shibboleth branded SP.
After IdP authentication I get the classic "No peer endpoint available to which to send SAML response"
I'm getting the following feedback in idp-process.log:
14:17:12.681 - DEBUG [org.opensaml.saml2.binding.AuthnResponseEndpointSelector:69] - Selecting endpoint by ACS URL 'https://test.SomePlace.com/apps/Router/ExternalAuth/SAML/Login/USU' and protocol binding 'urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST' for request '_db8221a6d2a56e5c61a26e7beed' from entity 'https://test.SomePlace.com'
14:17:12.682 - WARN [org.opensaml.saml2.binding.AuthnResponseEndpointSelector:202] - Relying party 'https://test.SomePlace.com' requested the response to be returned to endpoint with ACS URL 'https://test.SomePlace.com/apps/Router/ExternalAuth/ SAML/Login/USU' and binding 'urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST' however no endpoint, with that URL and using a supported binding, can be found in the relying party's metadata
First I check to see that I have no errors in the metadata file (my IdP), with case or reference url - but it looks good in the metadata and the metadata is properly up-to-date:
<md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://test.SomePlace.com/apps/Router/ExternalAuth/SAML/Login/USU" index="0" isDefault="true"/>
Next I check their assertion, just to be sure:
<saml2p:AuthnRequest xmlns:saml2p="urn:oasis:names:tc:SAML:2.0:protocol" AssertionConsumerServiceURL="https://test.SomePlace.com/apps/Router/ExternalAuth/SAML/Login/USU" Destination="https://shibtest.usu.edu/idp/profile/SAML2/POST/SSO" ID="_aeb9feb9ca1a7fd47bc21dfe4141f" IssueInstant="2011-07-26T16:29:31.693Z" ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Version="2.0">
Am I missing something obvious here? What else should I check on my side (IdP) before I start grilling them about their SP? Anything come to mind?
Chuck
--
To unsubscribe from this group, send email to
users+un...@shibboleth.net
This is a third-party SP, so I have no direct access to it and it appears to be a home-brewed SAML2 system, not a Shibboleth branded SP.
After IdP authentication I get the classic "No peer endpoint available to which to send SAML response"
I'm getting the following feedback in idp-process.log:
14:17:12.681 - DEBUG [org.opensaml.saml2.binding.AuthnResponseEndpointSelector:69] - Selecting endpoint by ACS URL 'https://test.SomePlace.com/apps/Router/ExternalAuth/SAML/Login/USU' and protocol binding 'urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST' for request '_db8221a6d2a56e5c61a26e7beed' from entity 'https://test.SomePlace.com'
14:17:12.682 - WARN [org.opensaml.saml2.binding.AuthnResponseEndpointSelector:202] - Relying party 'https://test.SomePlace.com' requested the response to be returned to endpoint with ACS URL 'https://test.SomePlace.com/apps/Router/ExternalAuth/ SAML/Login/USU' and binding 'urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST' however no endpoint, with that URL and using a supported binding, can be found in the relying party's metadata
First I check to see that I have no errors in the metadata file (my IdP), with case or reference url - but it looks good in the metadata and the metadata is properly up-to-date:
<md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://test.SomePlace.com/apps/Router/ExternalAuth/SAML/Login/USU" index="0" isDefault="true"/>
Next I check their assertion, just to be sure:
<saml2p:AuthnRequest xmlns:saml2p="urn:oasis:names:tc:SAML:2.0:protocol" AssertionConsumerServiceURL="https://test.SomePlace.com/apps/Router/ExternalAuth/SAML/Login/USU" Destination="https://shibtest.usu.edu/idp/profile/SAML2/POST/SSO" ID="_aeb9feb9ca1a7fd47bc21dfe4141f" IssueInstant="2011-07-26T16:29:31.693Z" ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Version="2.0">
Am I missing something obvious here? What else should I check on my side (IdP) before I start grilling them about their SP? Anything come to mind?
Chuck
--
To unsubscribe from this group, send email to
users+un...@shibboleth.net
Cantor, Scott E.
Jul 26, 2011, 6:24:58 PM7/26/11
to us...@shibboleth.net
On 7/26/11 6:14 PM, "Chuck Kimber" <chuck....@usu.edu> wrote:
>
>First I check to see that I have no errors in the metadata file (my IdP),
>with case or reference url - but it looks good in the metadata and the
>metadata is properly up-to-date:
>
>First I check to see that I have no errors in the metadata file (my IdP),
>with case or reference url - but it looks good in the metadata and the
>metadata is properly up-to-date:
Usually when it all looks correct, the solution is that you're not
actually using the metadata you think you are. Are you loading the SP's
metadata from a local file? Does the log verify it's loading?
-- Scott
Chuck Kimber
Jul 26, 2011, 7:41:18 PM7/26/11
to us...@shibboleth.net
-----------------
Usually when it all looks correct, the solution is that you're not actually using the metadata you think you are. Are you loading the SP's metadata from a local file? Does the log verify it's loading? -----------------
Thanks Scott,
My relying-party.xml has a very simple entry for it:
<metadata:MetadataProvider id="sciquestMD" xsi:type="metadata:FileBackedHTTPMetadataProvider"
metadataURL="https://test.SomePlace.com/apps/Router/SAMLMetadata/USU"
backingFile="/opt/shibboleth-idp/metadata/someplace-metadata.xml">
</metadata:MetadataProvider>
When all this began, the validUntil date in my someplace-metadata.xml was the very first thing I checked. It shows a recent update of the metadata, as the validUntil is some future date. (approx 24hrs since the first request in the morning for it)
<md:EntityDescriptor xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata" ID="_535c0455b0
b464f0718636ff0f" entityID="https://test.SomePlace.com" validUntil="2011-07-27T20:08:23.655Z">
Scrolling up in the debug information, as you've suggested, it does seem to find the entity in the metadata, but thinks it's expired?
14:17:12.677 - DEBUG [org.opensaml.saml2.metadata.provider.AbstractMetadataProvider:170] - Metadata document contained an EntityDescriptor with the ID https://test.SomePlace.com, but it was no longer valid
14:17:12.677 - DEBUG [org.opensaml.saml2.metadata.provider.ChainingMetadataProvider:199] - Checking child metadata provider for entity descriptor with entity ID: https://test.SomePlace.com
14:17:12.677 - DEBUG [org.opensaml.saml2.metadata.provider.AbstractMetadataProvider:509] - Searching for entity descriptor with an entity ID of https://test.SomePlace.com
14:17:12.678 - DEBUG [org.opensaml.saml2.metadata.provider.AbstractMetadataProvider:166] - Metadata document does not contain an EntityDescriptor with the ID https://test.SomePlace.com
14:17:12.678 - DEBUG [org.opensaml.saml2.metadata.provider.AbstractMetadataProvider:170] - Metadata document contained an EntityDescriptor with the ID https://test.SomePlace.com, but it was no longer valid
14:17:12.678 - DEBUG [org.opensaml.saml2.metadata.provider.ChainingMetadataProvider:199] - Checking child metadata provider for entity descriptor with entity ID: https://test.SomePlace.com
14:17:12.678 - DEBUG [org.opensaml.saml2.metadata.provider.AbstractMetadataProvider:509] - Searching for entity descriptor with an entity ID of https://test.SomePlace.com
14:17:12.678 - DEBUG [edu.internet2.middleware.shibboleth.common.relyingparty.provider.SAMLMDRelyingPartyConfigurationManager:155] - No custom or group-based relying party configuration found for https://test.SomePlace.com. Using default relying p
arty configuration.
This is indeed the last thing to happen, before it seems to give up. There is some signature foo it does here, successfully, then it's followed by what I've already posted:
14:17:12.681 - DEBUG [org.opensaml.saml2.binding.
AuthnResponseEndpointSelector:69] - Selecting endpoint by ACS URL 'https://test.SomePlace.com/apps/Router/ExternalAuth/SAML/Login/USU' and protocol binding 'urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST' for request '_db8221a6d2a56e5c61a26e7beed' from entity 'https://test.SomePlace.com'
14:17:12.682 - WARN [org.opensaml.saml2.binding.AuthnResponseEndpointSelector:202] - Relying party 'https://test.SomePlace.com' requested the response to be returned to endpoint with ACS URL 'https://test.SomePlace.com/apps/Router/ExternalAuth/
SAML/Login/USU' and binding 'urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST'
however no endpoint, with that URL and using a supported binding, can
be found in the relying party's metadata
Cantor, Scott E.
Jul 26, 2011, 9:14:04 PM7/26/11
to us...@shibboleth.net
On 7/26/11 7:41 PM, "Chuck Kimber" <chuck....@usu.edu> wrote:
>Thanks Scott,
>
>My relying-party.xml has a very simple entry for it:
>Thanks Scott,
>
>My relying-party.xml has a very simple entry for it:
You don't want to do that. There's no security there if you're asking
somebody to vouch for their own metadata. That's aside from the issue in
question.
>Scrolling up in the debug information, as you've suggested, it does seem
>to find the entity in the metadata, but thinks it's expired?
I'm not sure that's true, I think there are some spurious messages about
that, but I would bypass it for now by pulling it into a file, editing the
validUntil or removing it, and just seeing if that changes things.
-- Scott
Chuck Kimber
Jul 27, 2011, 5:12:38 PM7/27/11
to us...@shibboleth.net
On Tue, Jul 26, 2011 at 7:14 PM, Cantor, Scott E. <cant...@osu.edu> wrote:
I'm not sure that's true, I think there are some spurious messages about
that, but I would bypass it for now by pulling it into a file, editing the
validUntil or removing it, and just seeing if that changes things.
<metadata:MetadataProvider id="SomePlaceMD"
xsi:type="FilesystemMetadataProvider" xmlns="urn:mace:shibboleth:2.0:metadata"
metadataFile="/opt/shibboleth-idp/metadata/SomePlace-metadata.xml" />
Trying the experiment with a modified validUntil, a year in the future, and with removing it entirely, yield the same results as before.
14:49:35.935 - DEBUG [org.opensaml.saml2.metadata.provider.AbstractMetadataProvider:170] - Metadata document contained an EntityDescriptor with the ID https://test.SomePlace.com, but it was no longer valid
14:49:35.935 - DEBUG [org.opensaml.saml2.metadata.provider.ChainingMetadataProvider:199] - Checking child metadata provider for entity descriptor with entity ID: https://test.SomePlace.com
14:49:35.935 - DEBUG [org.opensaml.saml2.metadata.provider.AbstractMetadataProvider:509] - Searching for entity descriptor with an entity ID of https://test.SomePlace.com
14:49:35.936 - DEBUG [edu.internet2.middleware.shibboleth.common.relyingparty.provider.SAMLMDRelyingPartyConfigurationManager:155] - No custom or group-based relying party configuration found for https://test.SomePlace.com. Using default relying party configuration.
And shortly there after the "AHHHH! I don't know where to send them!!!"
14:49:35.943 - WARN [org.opensaml.saml2.binding.AuthnResponseEndpointSelector:202] - Relying party 'https://test.SomePlace.com' requested the response to be returned to endpoint with ACS URL 'https://test.SomePlace.com/apps/Router/ExternalAuth/SAML/Login/USU' and binding 'urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST' however no endpoint, with that URL and using asupported binding, can be found in the relying party's metadata
Now maybe this is more interesting:
14:49:26.096 - DEBUG [org.opensaml.saml2.metadata.provider.AbstractMetadataProvider:317] - Metadata document did not containany role descriptors of type {urn:oasis:names:tc:SAML:2.0:metadata}SPSSODescriptor for entity https://test.SomePlace.com
14:49:26.097 - DEBUG [org.opensaml.saml2.metadata.provider.AbstractMetadataProvider:286] - 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 https://test.SomePlace.com
14:49:26.097 - DEBUG [org.opensaml.saml2.metadata.provider.ChainingMetadataProvider:254] - Checking child metadata provider for entity descriptor with entity ID: https://test.SomePlace.com
.
.
.
I believe the SPSSODescriptor is part of the assertion made by the SP. Is it a required piece of information for the redirect back from the IdP to happen?
Tom Scavo
Jul 27, 2011, 7:59:42 PM7/27/11
to us...@shibboleth.net
On Wed, Jul 27, 2011 at 5:12 PM, Chuck Kimber <chuck....@usu.edu> wrote:
>
> I believe the SPSSODescriptor is part of the assertion made by the SP. Is
> it a required piece of information for the redirect back from the IdP to
> happen?
>
> I believe the SPSSODescriptor is part of the assertion made by the SP. Is
> it a required piece of information for the redirect back from the IdP to
> happen?
I'm not sure what you're asking. Does there need to be an
SPSSODescriptor in SP metadata? Most definitely, yes. Will the
exchange fail without it? Oh, yes, if the IdP can't verify the
endpoint location at the SP, it has no choice.
Tom
Chuck Kimber
Jul 28, 2011, 11:43:36 AM7/28/11
to us...@shibboleth.net
Thanks Tom. Yeah, I thought it was part of the assertion, but I took another look at the SP's metadata and found it is actually in there, so I'm confused why I'm getting feedback from the DEBUG saying it can't find it. Any thoughts?
Chuck Kimber
Jul 28, 2011, 1:03:37 PM7/28/11
to us...@shibboleth.net
I have found the problem, with much help from Scott offline (GO BUCKEYES!) and thought I should polish this thread off.
The following DEBUG did turn out to be telling us what was going wrong.
It turns out the vendor I was working with is a member of InCommon, as are we, and the InCommon metadata was taking precedence over the test SP metadata the vendor had me working with. So it turns out the IdP REALLY didn't know where to send the user when it was done authenticating them, as the vendors test SP wasn't registered in the InCommon metadata yet. Moving the vendor's test metadata registration to be the top metadata entry in my relyingparty.xml allowed things to take proper precedence and it's functioning as expected now. Later when the vendor includes the new SP in the InCommon metadata I will come back and remove my testing entry.
Thanks again to Scott and others who sent me so much great offline help!
The following DEBUG did turn out to be telling us what was going wrong.
On Wed, Jul 27, 2011 at 3:12 PM, Chuck Kimber <chuck....@usu.edu> wrote:
Now maybe this is more interesting:
14:49:26.096 - DEBUG [org.opensaml.saml2.metadata.provider.AbstractMetadataProvider:317] - Metadata document did not containany role descriptors of type {urn:oasis:names:tc:SAML:2.0:metadata}SPSSODescriptor for entity https://test.SomePlace.com
14:49:26.097 - DEBUG [org.opensaml.saml2.metadata.provider.AbstractMetadataProvider:286] - 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 https://test.SomePlace.com
14:49:26.097 - DEBUG [org.opensaml.saml2.metadata.provider.ChainingMetadataProvider:254] - Checking child metadata provider for entity descriptor with entity ID: https://test.SomePlace.com
It turns out the vendor I was working with is a member of InCommon, as are we, and the InCommon metadata was taking precedence over the test SP metadata the vendor had me working with. So it turns out the IdP REALLY didn't know where to send the user when it was done authenticating them, as the vendors test SP wasn't registered in the InCommon metadata yet. Moving the vendor's test metadata registration to be the top metadata entry in my relyingparty.xml allowed things to take proper precedence and it's functioning as expected now. Later when the vendor includes the new SP in the InCommon metadata I will come back and remove my testing entry.
Thanks again to Scott and others who sent me so much great offline help!
Reply all
Reply to author
Forward
0 new messages