<div dir="ltr">It does look like my problem might be related to running under Kubernetes, specifically that http headers are being set by the nginx proxy.<br><br>When I load the Logout url again while in the network tab in chrome's developer console I can see the following response headers:<br>cache-control: no-store<br>content-encoding: gzip<br>content-language: en-CA<br>content-security-policy: frame-ancestors 'none';<br>content-type: text/html;charset=utf-8<br>date: Tue, 16 Apr 2019 13:24:29 GMT<br>server: nginx/1.15.6<br>status: 200<br>strict-transport-security: max-age=15724800; includeSubDomains<br>vary: Accept-Encoding<br>x-frame-options: DENY<br><div><br></div><div>I would expect SAMEORIGIN and self based on my current idp.properties file so I'm almost certain now that these are being set in the proxy. I should be able to define these headers by adding a Ingress ConfigMap and now that I think I know where the problem lies I'm starting to find solutions when searching. It would be easy to have headers uniformly set for the entire application but I think it's also possible to have different headers set for specific urls.</div><div><br></div><div>Hopefully this may have been been a help to anyone else running under Kubernetes/OpenShift or possibly any other reverse proxy.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Apr 16, 2019 at 9:27 AM Cantor, Scott <<a href="mailto:cantor.2@osu.edu">cantor.2@osu.edu</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 4/16/19, 9:10 AM, "users on behalf of Darren Boss" <<a href="mailto:users-bounces@shibboleth.net" target="_blank">users-bounces@shibboleth.net</a> on behalf of <a href="mailto:darren.boss@computecanada.ca" target="_blank">darren.boss@computecanada.ca</a>> wrote:<br>
<br>
> I'm having no luck with SLO either and it also seems related to CSP configuration issues.<br>
<br>
I don't know CSP so I have no insight other than to continue to point out that the SAML SLO and propagation flow paths are not configured in web.xml to apply those headers in the responses. If the parent frame's *own* option headers affect things, then I have no idea how that's supposed to work, but web.xml is where the paths impacted are set and it's possible to exclude more of them, aside from simply changing the headers.<br>
<br>
It also doesn't work like this during testing.<br>
<br>
> I was thinking about starting a new thread but I feel like my setup might be similar to Bob's. We have a fairly new<br>
> deployment that doesn't have a huge amount of configuration legacy so should be pretty simple to get SLO working.<br>
<br>
There is nothing simple about SLO.<br>
<br>
> Refused to display '<a href="https://myidpurl/idp/profile/PropagateLogout?SessionKey=1" rel="noreferrer" target="_blank">https://myidpurl/idp/profile/PropagateLogout?SessionKey=1</a>' in a frame because an ancestor<br>
> violates the following Content Security Policy directive: "frame-ancestors 'none'".<br>
<br>
If the ancestor's frame options impact child frames inside the actual page with the headers, then a solution is to exclude the non-SAML logout path from the web.xml configuration that applies the response headers. The SAML paths are already unlisted.<br>
<br>
I've tested with Chrome in the past with the headers in place, and I don't believe that to be true but perhaps it changed. It should prevent framing of that page *itself*, not the child frames it creates. But the web and I don't get along so I probably don't understand how any of it works.<br>
<br>
> I had been migrating configuration so I was missing the commented out configuration for frameoptions and scp.<br>
<br>
That would default them, and the defaults are non-empty.<br>
<br>
Setting the properties works and you can trace the requests yourself to verify what they're being set to. Setting them to an empty value will prevent the header from appearing.<br>
<br>
-- Scott<br>
<br>
<br>
-- <br>
For Consortium Member technical support, see <a href="https://wiki.shibboleth.net/confluence/x/coFAAg" rel="noreferrer" target="_blank">https://wiki.shibboleth.net/confluence/x/coFAAg</a><br>
To unsubscribe from this list send an email to <a href="mailto:users-unsubscribe@shibboleth.net" target="_blank">users-unsubscribe@shibboleth.net</a><br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><p style="margin-bottom:0in;line-height:13px"><font color="#ff0000"><font face="arial, sans-serif"><font style="font-size:10pt"><b>Darren Boss</b></font></font></font></p><font style="font-size:10pt"><i>Senior Programmer/Analyst</i></font><font style="font-size:10pt"><i><br>Programmeur-analyste principal</i></font><font style="font-size:10pt"><i><br><a href="mailto:darren.boss@computecanada.ca" style="color:rgb(17,85,204)" target="_blank">darren.boss@computecanada.ca</a></i></font><font style="font-size:10pt"><i><br>(o) 416.228.1234 x </i></font><font color="#000000"><font style="font-size:10pt">230<br></font></font></div><font color="#000000"><font style="font-size:10pt"><i>(c) 919.525.0083</i></font></font></div></div></div></div>