SLO Problems

[Darren Boss]

It does look like my problem might be related to running under Kubernetes,
specifically that http headers are being set by the nginx proxy.

When I load the Logout url again while in the network tab in chrome's
developer console I can see the following response headers:
cache-control: no-store
content-encoding: gzip
content-language: en-CA
content-security-policy: frame-ancestors 'none';
content-type: text/html;charset=utf-8
date: Tue, 16 Apr 2019 13:24:29 GMT
server: nginx/1.15.6
status: 200
strict-transport-security: max-age=15724800; includeSubDomains
vary: Accept-Encoding
x-frame-options: DENY

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.

Hopefully this may have been been a help to anyone else running under
Kubernetes/OpenShift or possibly any other reverse proxy.

On Tue, Apr 16, 2019 at 9:27 AM Cantor, Scott <cantor.2 at osu.edu> wrote:

> On 4/16/19, 9:10 AM, "users on behalf of Darren Boss" <
> users-bounces at shibboleth.net on behalf of darren.boss at computecanada.ca>
> wrote:
>
> > I'm having no luck with SLO either and it also seems related to CSP
> configuration issues.
>
> 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.
>
> It also doesn't work like this during testing.
>
> > 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
> > deployment that doesn't have a huge amount of configuration legacy so
> should be pretty simple to get SLO working.
>
> There is nothing simple about SLO.
>
> > Refused to display '
> https://myidpurl/idp/profile/PropagateLogout?SessionKey=1' in a frame
> because an ancestor
> > violates the following Content Security Policy directive:
> "frame-ancestors 'none'".
>
> 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.
>
> 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.
>
> > I had been migrating configuration so I was missing the commented out
> configuration for frameoptions and scp.
>
> That would default them, and the defaults are non-empty.
>
> 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.
>
> -- Scott
>
>
> --
> 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
>


-- 

*Darren Boss*
*Senior Programmer/Analyst*
*Programmeur-analyste principal*
*darren.boss at computecanada.ca <darren.boss at computecanada.ca>*
*(o) 416.228.1234 x *230
*(c) 919.525.0083*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20190416/c5bfa163/attachment.html>