Getting "No peer endpoint" on new installation

Nate Klingenstein ndk at
Sat May 18 14:10:14 EDT 2013


You're probably starting the authentication process by access instead of

Your metadata file is uploaded and trusted and fine.  The problem is somewhere else.

[testshib-user-metadata]$ grep rmtcentral *
Meda_George_Data:<md:EntityDescriptor xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata" xmlns:mdui="urn:oasis:names:tc:SAML:metadata:ui" ID="_19d9edf1851c00adc2a634793a1f9e536282b96c" entityID="">
Meda_George_Data:    <md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="" index="1"/>

If you intend to have users access your site using cookies over http://, you can add that endpoint to your metadata and re-upload it, but this generally makes sniffing and replaying cookies/sessions easy.


On May 18, 2013, at 16:51 , George Boney wrote:

Yes, I noticed that.  But (and I may not understand how this works) the metadata file says "use https", but the reason it sends it to "http" is "No custom or group-based relying party configuration found"(from log).   I interpret this to mean it can't find "george.." in Metadata, so it used the default ("Using default relying party configuration" http) which doesn't work.

     I want it to use what is in the Meta file I uploaded (Plus I don't understand why it does not find the data I uploaded it --- or is that what a normal log file looks like?)  Could I have an error in the Metadata file?

On 5/17/2013 10:41 PM, Michael A Grady wrote:
Note that the endpoint listed in those log entries for where the response is supposed to be sent is:

but the endpoint corresponding to the SAML2 Post binding in the metadata entry is:

Note the difference -- one is http, one is https. The endpoint that is requested in the authn request does *not* match a registered endpoint in your metadata.

On May 17, 2013, at 8:19 PM, George Boney wrote:

Hello there,
     I have an issue I cannot seem to fix and I would appreciate any help you can provide.   I am using Shibboleth on a CentOS system (the SP) and<> as the IDP.  Here is basically what happens
a)    Try to access ‘secure’ page
b)    Presented with login – login as myself
c)    Get error “No Peer Endpoint”

I am at a loss at what more I can do to debug this.   It appears the IDP cannot find the system name in the metadata.  I have reloaded the metadata a couple of times, and recopied Shibboleth2.xml, restart shib and  http, etc.  (Though the last few times the Shibboleth2.xml has not had any changes in it.)

Any help or suggestions about how to troubleshoot that you can provide would be appreciated.

Low Priority:  I also have a question about how to set this up so I can use different IDP’s for different URL (/secure/dir1/* goes to IDP-A, /secure/dir2/* goes to IDP-B).   If you could recommend a good web source, white paper, book, etc.  that discusses this, I would appreciate it.
George Boney

Detailed Flow and description.
Try to access URL   “”
 (BTW, you can access “” just to see the expected result)
It asks for a login (myself/myself) and then presents a page that says:
Something horrible happened. …
Error Message: No peer endpoint available to which to send SAML response
The log file says:
20:26:39.906 - DEBUG [edu.internet2.middleware.shibboleth.idp.profile.saml2.SSOProfileHandler:170] - Incoming request contains a login context and indicates principal was authenticated, processing second leg of request
20:26:39.907 - DEBUG [edu.internet2.middleware.shibboleth.common.relyingparty.provider.SAMLMDRelyingPartyConfigurationManager:128] - Looking up relying party configuration for
20:26:39.907 - DEBUG [edu.internet2.middleware.shibboleth.common.relyingparty.provider.SAMLMDRelyingPartyConfigurationManager:134] - No custom relying party configuration found for, looking up configuration based on metadata groups.
20:26:39.908 - DEBUG [edu.internet2.middleware.shibboleth.common.relyingparty.provider.SAMLMDRelyingPartyConfigurationManager:157] - No custom or group-based relying party configuration found for Using default relying party configuration.
20:26:39.909 - WARN [org.opensaml.saml2.binding.AuthnResponseEndpointSelector:206] - Relying party '' requested the response to be returned to endpoint with ACS URL ''  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
20:26:39.909 - ERROR [edu.internet2.middleware.shibboleth.idp.profile.AbstractSAMLProfileHandler:429] - No return endpoint available for relying party
The metadata file (“Meda_George_Data.”  Attached) shows
<!--This is example metadata only. Do *NOT* supply it as is without review, and do *NOT* provide it in real time to your partners.-->
<md:EntityDescriptor xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata" xmlns:mdui="urn:oasis:names:tc:SAML:metadata:ui" ID="_19d9edf1851c00adc2a634793a1f9e536282b96c" entityID=""<>>
  <md:Extensions xmlns:
        <md:SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" Location=""<>/>
    <md:SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location=""<>/>
    <md:SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Artifact" Location=""<>/>
    <md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location=""<> index="1"/>
    <md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST-SimpleSign" Location=""<> index="2"/>
    <md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:1.0:profiles:artifact-01" Location=""<> index="6"/>

To unsubscribe from this list send an email to users-unsubscribe at<mailto:users-unsubscribe at>

Michael A. Grady
Senior IAM Consultant, Unicon, Inc.

To unsubscribe from this list send an email to users-unsubscribe at<mailto:users-unsubscribe at>

To unsubscribe from this list send an email to users-unsubscribe at<mailto:users-unsubscribe at>

-------------- next part --------------
An HTML attachment was scrubbed...

More information about the users mailing list