Meteor.js and Shibboleth IP

[Truby Voglund]

Peter,

Thank you so much for the help.  I have now got the ACS Url to not be dynamic.  But I monitor all calls to my SP and do not see any coming from the Shibboleth IdP (testShib).

Seems like Shibboleth isn't redirecting back to my HTTP-POST I specified as my AssertionConsumerService.  As is defined below.

      <AssertionConsumerService index="1" isDefault="true"
              Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"
              Location="http://tuadevshibbolet.cloudapp.net/_saml/validate/shibboleth-idp/1ed79ec15dfd"/>

Anymore ideas would be fantastic. 

Thanks again, you are very helpful.

Truby

________________________________________
From: users <users-bounces at shibboleth.net> on behalf of Peter Schober <peter.schober at univie.ac.at>
Sent: Tuesday, June 30, 2015 9:42 AM
To: users at shibboleth.net
Subject: Re: Meteor.js and Shibboleth IP

* 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
--
To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net