SP generated AssertionConsumerServiceURL not https

[Altgilbers, Ian M]

I thought it was something along those lines, but didn’t look far enough…  Some apache confg directives got moved around and my 443 virtual host was missing:

 SSLEngine on

D’oh!


Thank for the detailed answer and quick reply,


Ian




On Oct 26, 2018, at 4:25 PM, Nate Klingenstein <ndk at signet.id<mailto:ndk at signet.id>> wrote:

Ian,



Shibboleth constructs self-referential URL's when it needs to create redirects(such as the end AssertionConsumerService to place in an AuthnRequest) by pulling variables from the web environment to construct that URL.  However you're triggering the authentication request, it's apparently either coming in over http or you have something in your web server configuration that is forcing the scheme.  I don't know if you used the built-in metadata generator, but if you did and it generated http URL's, that indicates that you accessed the default metadata generator over http rather than https, as it does the same inspection of the inbound request.





You might look at how you're triggering the authentication request or re-configuring your web environment so that the proper scheme is returned, or you can enable handlerSSL="true" in the Sessions element, which will force all AssertionConsumerService endpoint generation to use the HTTPS scheme instead.



https://wiki.shibboleth.net/confluence/display/SP3/Sessions





Thanks,
Nate.





-----Original message-----
From: Altgilbers, Ian M
Sent: Friday, October 26 2018, 1:59 pm
To: users at shibboleth.net<mailto:users at shibboleth.net>
Subject: SP generated AssertionConsumerServiceURL not https

I am setting up a new RHEL7 server  with apache 2.4 and:
shibboleth-3.0.2-1.1.x86_64

I configured my shibboleth2.xml config file like I have on several other hosts (with shibboleth 2.x), but when I go to collect my SP metadata to provide to our IdP admins, all the the AssertionConsumerService Locations are http, instead of https.

Apache is only listening on port 80 in order to redirect to 443…  I have been able to get around this by having Apache do a 307 redirect to https, but that’s masking the problem.

I’ve tried setting the attribute:  allowedSchemes=“https” in <SPConfig>, but it didn’t seem to have any effect.

I tried manually updating the SP metadata with https urls.  Then, when I try to login, the AuthnRequest that the SP generates uses http:// for AssertionConsumerServiceURL, so the IdP can’t find a match and rejects me.


What could I be missing?   Why would the SP’s metadata generator be producing http:// URLs?   I’m accessing the SP over https...


Thanks,



Ian Altgilbers
Senior Systems Administrator
Educational Technology Services
Tufts Technology Services
Tufts University

Phone: 617.627.0388
http://it.tufts.edu/ests

--

For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg

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

--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net<mailto:users-unsubscribe at shibboleth.net>

Ian Altgilbers
Senior Systems Administrator
Educational Technology Services
Tufts Technology Services
Tufts University

Phone: 617.627.0388
http://it.tufts.edu/ests

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20181026/758388dc/attachment.html>