ACS url when running daemon in linux sockets?

[Br LRd]

Turns out I was sending the incorrect assertion to my SP. Apparently there
are 2, first is send to IdP-s ACS, and the second one is sent to SP. Trying
to curl the first assertion to IDP destination gives a "State Information
Lost" (SimpleSAML_Error_NoState: NOSTATE), so there's still something to
figure out there.

And why not? I send user agent to url i get from /Login, somehow post the
assertions, get shibcookie, use shibcookie to get user attributes from
/Session. No web server needed...

On Wed, Dec 28, 2016 at 4:47 PM, Cantor, Scott <cantor.2 at osu.edu> wrote:

> On 12/28/16, 5:40 AM, "users on behalf of Br LRd" <
> users-bounces at shibboleth.net on behalf of blasterradius at gmail.com> wrote:
>
> > So I guess new question is, if 'http://localhost/Shibboleth.
> sso/SAML2/POST' is the incorrect url, where is it trying to send
> > assertions / where should it send them to?
>
> I don't know what you're doing, but FastCGI support does not allow you to
> suddenly not be using a web server. The sAML request comes from the web
> server operating the SP and the response is sent back to whatever URL it
> requests, assuming its a validated endpoint in the SP's metadata. For the
> SP to work, the endpoint has to share a cookie domain with the resource(s)
> its protecting and the endpoint URL(s) are based on that.
>
> -- Scott
>
>
>
>
>
> --
> To unsubscribe from this list send an email to
> users-unsubscribe at shibboleth.net
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20161229/d999df53/attachment.html>