Meteor.js and Shibboleth IP
Peter Schober
peter.schober at univie.ac.at
Tue Jun 30 11:42:10 EDT 2015
* Truby Voglund <tvoglund at mocodevco.com> [2015-06-30 09:06]:
> I have gotten past the timestamp issues and now I am receiving the
> error "No return endpoint available for relying party ". Seems like
> from my research that I need to define the endpoint. But unsure how
> to define it in my metadata file.
When I just tried it your SAML SP requested responses to be sent to
this address:
http://tuadevshibbolet.cloudapp.net/_saml/validate/shibboleth-idp/EGdarQqR3YkamW4WL
When I tried it again a moment later, it wanted responses sent to
this address:
http://tuadevshibbolet.cloudapp.net/_saml/validate/shibboleth-idp/uASN37XfmWvuxgS3B
So your SP is doing something rather unusual (and unhelpful): It's
dynamically generating the URL it wants to recieve the response at.
That prevents an IDP from making sure reponses can only be requested
to be sent to URLs that are known beforehand, via SAML Metadata.
The obvious way to fix that is stop the software from overloading the
ACS URL with internal state (which I'm assuming here it's trying to do
here, instead of using RelayState as designed).
Just how you'd do that is not a topic for the Shibboleth lists.
The other way to work around that problem would be to get your SAML SP
to sign the SAML authentication request and then configure the
Shibboleth IDP to ignore the unkown ACS URL for signed requests from
this very SP. Of course if you're using Testshib that's not an option
(unless the people running the Testshib IDP would consider making that
a default setting. It isn't in any released Shib IDP code.)
If you can change neither (static ACS URLs nor signed requests +
changed IDP config) you've officially ran out of options.
-peter
More information about the users
mailing list