SLO Problems

classic Classic list List threaded Threaded
15 messages Options
Reply | Threaded
Open this post in threaded view
|

SLO Problems

Bob Allison
To get my environment up and running, I am running a single instance of IdP v3.4.3 and a single Apache instance connected to SP 3.0.4.

I have gotten everything configured so that the IdP logout page asks if I want to logout all my SP sessions and lists the SP as someplace I have visited during the session. I have been avoiding changing any of the views until I can get the basic functionality working.

When I click the "Yes" button, the attempt to log out of the SP session immediately fails. In the browser's console, I see the following two messages (I removed the SAML response from the first message as its probably not a part of the problem):
>> Refused to load https://www.mail.allisonr.us:4443/idp/profile/SAML2/Redirect/SLO?SAMLResponse=... because it does not appear in the frame-ancestors directive of the Content Security Policy.
>> Sandbox access violation: Blocked a frame at "https://www.mail.allisonr.us:4443" from accessing a frame at "null".  The frame being accessed is sandboxed and lacks the "allow-same-origin" flag.

When I tried to set values in idp.frameoptions and idp.csp to adjust the frame options, the values I placed in the properties appears to be ignored.

Does anyone have some pointers on how to make this work? I have been searching through the documentation but I seem to be missing something important.

There are two other things on my to-do list for desired functionality, any pointers on these would also be appreciated:
>> Get the SP to notify my application of the logout so it can clear its session (I am failing to be able to place a <Notify /> tag in the right place)
>> Adjust the logout process so that, as I see at most of the banks and health care sites I visit, the SAML SLO is a series of blank pages ending with a page that just says "You are logged out. Please close your browser."
--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

RE: SLO Problems

Cantor, Scott E.
> >> Refused to load
> https://www.mail.allisonr.us:4443/idp/profile/SAML2/Redirect/SLO?SAMLRes
> ponse=... because it does not appear in the frame-ancestors directive of the
> Content Security Policy.

The logout endpoint isn't itself implemented under the denial headers, so that doesn't make any sense unless you have unreleased pre-3.4 code in web.xml that hadn't been corrected to exclude the SLO paths. That was fixed before 3.4.0 was done according to the history in git.

> When I tried to set values in idp.frameoptions and idp.csp to adjust the frame
> options, the values I placed in the properties appears to be ignored.

It does not ignore them, though it's not reloadable.

> There are two other things on my to-do list for desired functionality, any
> pointers on these would also be appreciated:
> >> Get the SP to notify my application of the logout so it can clear its
> >> session (I am failing to be able to place a <Notify /> tag in the right place)

The right place is wherever its documented to go. I have no memory of that, but whatever the schema says and the documentation says is where it goes. I don't think it's very strict.

> Adjust the logout process so that, as I see at most of the banks and health care
> sites I visit, the SAML SLO is a series of blank pages ending with a page that just
> says "You are logged out. Please close your browser."

Full frame redirects are a non-starter. That terminates at the first broken system. Logout is aso not interoperable, the specification does not cover the UI sufficiently to make it work. But propagation is only passably acceptable when it's done with frames, and that means the IdP has to control the UI, and SP to IdP is the only full window redirect expected within the UI implemented by these two software products. The SP is more agnostic about it, but it works well enough because there is no particular UI implemented in it anyway and it clears its own state first before giving up control.

-- Scott

--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: SLO Problems

Darren Boss
I'm having no luck with SLO either and it also seems related to CSP configuration issues.

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. I set idp.session.trackSPSessions = true and tried SLO by entering the the https://myidpurl/idp/profile/Logout. After choosing Yes I get the view that shows the attempt to log out of my test SP was unsuccessful and see the red x beside the SP EntityId. In the chrome dev tools I see this error:
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'".

I had been migrating configuration so I was missing the commented out configuration for frameoptions and scp. I recently added this to my idp.properties and tested SLO again
idp.frameoptions = SAMEORIGIN
idp.csp = frame-ancestors 'self';

I also tried with
idp.csp =

No dice and the exact same error messages are displayed in chrome dev console. I tried with firefox as well and I don't see the red X but SLO also fails with the console message:
Content Security Policy: Ignoring ‘x-frame-options’ because of ‘frame-ancestors’ directive.
Content Security Policy: The page’s settings blocked the loading of a resource at https://myidpurl/idp/profile/Logout?execution=e2s2 (“frame-ancestors”).

The only weird thing about my Shibboleth IdP setup is we run it in a Docker container under Kubernetes. TLS is terminated by the ingress controller (Nginx reverse proxy) and there is a HAProxy in front of the entire cluster.

On Mon, Apr 15, 2019 at 9:24 PM Cantor, Scott <[hidden email]> wrote:
> >> Refused to load
> https://www.mail.allisonr.us:4443/idp/profile/SAML2/Redirect/SLO?SAMLRes
> ponse=... because it does not appear in the frame-ancestors directive of the
> Content Security Policy.

The logout endpoint isn't itself implemented under the denial headers, so that doesn't make any sense unless you have unreleased pre-3.4 code in web.xml that hadn't been corrected to exclude the SLO paths. That was fixed before 3.4.0 was done according to the history in git.

> When I tried to set values in idp.frameoptions and idp.csp to adjust the frame
> options, the values I placed in the properties appears to be ignored.

It does not ignore them, though it's not reloadable.

> There are two other things on my to-do list for desired functionality, any
> pointers on these would also be appreciated:
> >> Get the SP to notify my application of the logout so it can clear its
> >> session (I am failing to be able to place a <Notify /> tag in the right place)

The right place is wherever its documented to go. I have no memory of that, but whatever the schema says and the documentation says is where it goes. I don't think it's very strict.

> Adjust the logout process so that, as I see at most of the banks and health care
> sites I visit, the SAML SLO is a series of blank pages ending with a page that just
> says "You are logged out. Please close your browser."

Full frame redirects are a non-starter. That terminates at the first broken system. Logout is aso not interoperable, the specification does not cover the UI sufficiently to make it work. But propagation is only passably acceptable when it's done with frames, and that means the IdP has to control the UI, and SP to IdP is the only full window redirect expected within the UI implemented by these two software products. The SP is more agnostic about it, but it works well enough because there is no particular UI implemented in it anyway and it clears its own state first before giving up control.

-- Scott

--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]


--

Darren Boss

Senior Programmer/Analyst
Programmeur-analyste principal

[hidden email]

(o) 416.228.1234 x 
230
(c) 919.525.0083

--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: SLO Problems

Cantor, Scott E.
On 4/16/19, 9:10 AM, "users on behalf of Darren Boss" <[hidden email] on behalf of [hidden email]> 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 [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: 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 <[hidden email]> wrote:
On 4/16/19, 9:10 AM, "users on behalf of Darren Boss" <[hidden email] on behalf of [hidden email]> 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 [hidden email]


--

Darren Boss

Senior Programmer/Analyst
Programmeur-analyste principal

[hidden email]

(o) 416.228.1234 x 
230
(c) 919.525.0083

--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: SLO Problems

Cantor, Scott E.
On 4/16/19, 9:43 AM, "users on behalf of Darren Boss" <[hidden email] on behalf of [hidden email]> wrote:

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

That doesn't inherently mean the headers are in fact correctly usable out of the box, there still might be a mistake in our understanding.

You should NOT need to alter the headers to make logout work, and I have never had to do so in any testing scenarios I've attempted. So either my testing is artificial and doesn't match a real world issue in some way, or people are mistaken somewhere about what Chrome is really saying.

-- Scott


--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: SLO Problems

Darren Boss
So I think I tracked it down to Jetty configuration. I'm using the Unicon shibboleth-idp-dockerized image although I rebuild it and I do make some minor tweaks as a layer on top of their image.


I think that's the culprit and that last addRule can be removed. If it works I'll create a PR to their project.

On Tue, Apr 16, 2019 at 11:19 AM Cantor, Scott <[hidden email]> wrote:
On 4/16/19, 9:43 AM, "users on behalf of Darren Boss" <[hidden email] on behalf of [hidden email]> wrote:

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

That doesn't inherently mean the headers are in fact correctly usable out of the box, there still might be a mistake in our understanding.

You should NOT need to alter the headers to make logout work, and I have never had to do so in any testing scenarios I've attempted. So either my testing is artificial and doesn't match a real world issue in some way, or people are mistaken somewhere about what Chrome is really saying.

-- Scott


--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]


--

Darren Boss

Senior Programmer/Analyst
Programmeur-analyste principal

[hidden email]

(o) 416.228.1234 x 
230
(c) 919.525.0083

--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: SLO Problems

Bob Allison
I am also using that image. I confirmed that removing jetty-rewrite.xml completely solved my problems. Only removing the last addRule was not enough for me. I guess the question is if there is any reason to have the file at all if both rules have been removed.

On Apr 16, 2019, at 13:07, Darren Boss <[hidden email]> wrote:

So I think I tracked it down to Jetty configuration. I'm using the Unicon shibboleth-idp-dockerized image although I rebuild it and I do make some minor tweaks as a layer on top of their image.


I think that's the culprit and that last addRule can be removed. If it works I'll create a PR to their project.

On Tue, Apr 16, 2019 at 11:19 AM Cantor, Scott <[hidden email]> wrote:
On 4/16/19, 9:43 AM, "users on behalf of Darren Boss" <[hidden email] on behalf of [hidden email]> wrote:

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

That doesn't inherently mean the headers are in fact correctly usable out of the box, there still might be a mistake in our understanding.

You should NOT need to alter the headers to make logout work, and I have never had to do so in any testing scenarios I've attempted. So either my testing is artificial and doesn't match a real world issue in some way, or people are mistaken somewhere about what Chrome is really saying.

-- Scott


--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]


--

Darren Boss

Senior Programmer/Analyst
Programmeur-analyste principal

[hidden email]

(o) 416.228.1234 x 
230
(c) 919.525.0083
--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]


--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: SLO Problems

Darren Boss
I was starting to feel bad about hijacking this thread but turns out we really were working on the same issue! I'm still having issue even when removing the jetty-rewrite.xml completely but now I'm closer to a working configuration. I see a status 502 for PropagateLogout (PropagateLogout?SessionKey=N) url when I use the developer console in chrome. In Firefox the logout now gets to the point where the red x is now displayed beside each SP and in both browsers I no longer see the error messages I reported before. I also confirmed in the dev console that the csp and frameoptions http headers are no longer there.

I wasn't sure that there were many using the Unicon image but I noticed that it was still getting quickly updated when a new release of the IdP came out and they recently started using multi-stage builds so it's still being supported and even if it wasn't it's pretty simple to tweak the Dockerfile to target new versions of Jetty, Shib IdP or Java and rebuild.


On Tue, Apr 16, 2019 at 7:41 PM Bob Allison <[hidden email]> wrote:
I am also using that image. I confirmed that removing jetty-rewrite.xml completely solved my problems. Only removing the last addRule was not enough for me. I guess the question is if there is any reason to have the file at all if both rules have been removed.

On Apr 16, 2019, at 13:07, Darren Boss <[hidden email]> wrote:

So I think I tracked it down to Jetty configuration. I'm using the Unicon shibboleth-idp-dockerized image although I rebuild it and I do make some minor tweaks as a layer on top of their image.


I think that's the culprit and that last addRule can be removed. If it works I'll create a PR to their project.

On Tue, Apr 16, 2019 at 11:19 AM Cantor, Scott <[hidden email]> wrote:
On 4/16/19, 9:43 AM, "users on behalf of Darren Boss" <[hidden email] on behalf of [hidden email]> wrote:

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

That doesn't inherently mean the headers are in fact correctly usable out of the box, there still might be a mistake in our understanding.

You should NOT need to alter the headers to make logout work, and I have never had to do so in any testing scenarios I've attempted. So either my testing is artificial and doesn't match a real world issue in some way, or people are mistaken somewhere about what Chrome is really saying.

-- Scott


--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]


--

Darren Boss

Senior Programmer/Analyst
Programmeur-analyste principal

[hidden email]

(o) 416.228.1234 x 
230
(c) 919.525.0083
--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]

--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]


--

Darren Boss

Senior Programmer/Analyst
Programmeur-analyste principal

[hidden email]

(o) 416.228.1234 x 
230
(c) 919.525.0083

--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

RE: SLO Problems

Paul Caskey

Hi Darren-

 

InCommon also maintains containers for Shibboleth IdP, SP (both Windows and Linux) and Grouper and COmanage.

 

See here for more info: <a href="https://spaces.at.internet2.edu/display/ITAP/InCommon&#43;Trusted&#43;Access&#43;Platform&#43;Release"> https://spaces.at.internet2.edu/display/ITAP/InCommon+Trusted+Access+Platform+Release

 

 

TTYL

 

From: users <[hidden email]> On Behalf Of Darren Boss
Sent: Wednesday, April 17, 2019 8:14 AM
To: Shib Users <[hidden email]>
Subject: Re: SLO Problems

 

I was starting to feel bad about hijacking this thread but turns out we really were working on the same issue! I'm still having issue even when removing the jetty-rewrite.xml completely but now I'm closer to a working configuration. I see a status 502 for PropagateLogout (PropagateLogout?SessionKey=N) url when I use the developer console in chrome. In Firefox the logout now gets to the point where the red x is now displayed beside each SP and in both browsers I no longer see the error messages I reported before. I also confirmed in the dev console that the csp and frameoptions http headers are no longer there.

 

I wasn't sure that there were many using the Unicon image but I noticed that it was still getting quickly updated when a new release of the IdP came out and they recently started using multi-stage builds so it's still being supported and even if it wasn't it's pretty simple to tweak the Dockerfile to target new versions of Jetty, Shib IdP or Java and rebuild.

 

 

On Tue, Apr 16, 2019 at 7:41 PM Bob Allison <[hidden email]> wrote:

I am also using that image. I confirmed that removing jetty-rewrite.xml completely solved my problems. Only removing the last addRule was not enough for me. I guess the question is if there is any reason to have the file at all if both rules have been removed.



On Apr 16, 2019, at 13:07, Darren Boss <[hidden email]> wrote:

 

So I think I tracked it down to Jetty configuration. I'm using the Unicon shibboleth-idp-dockerized image although I rebuild it and I do make some minor tweaks as a layer on top of their image.

 

 

I think that's the culprit and that last addRule can be removed. If it works I'll create a PR to their project.

 

On Tue, Apr 16, 2019 at 11:19 AM Cantor, Scott <[hidden email]> wrote:

On 4/16/19, 9:43 AM, "users on behalf of Darren Boss" <[hidden email] on behalf of [hidden email]> wrote:

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

That doesn't inherently mean the headers are in fact correctly usable out of the box, there still might be a mistake in our understanding.

You should NOT need to alter the headers to make logout work, and I have never had to do so in any testing scenarios I've attempted. So either my testing is artificial and doesn't match a real world issue in some way, or people are mistaken somewhere about what Chrome is really saying.

-- Scott


--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]


 

--

Darren Boss

Senior Programmer/Analyst
Programmeur-analyste principal
[hidden email]
(o) 416.228.1234 x 
230

(c) 919.525.0083

--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]

 

--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]


 

--

Darren Boss

Senior Programmer/Analyst
Programmeur-analyste principal
[hidden email]
(o) 416.228.1234 x 
230

(c) 919.525.0083


--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: SLO Problems

Darren Boss
Yes, I was aware. It's on my long to do list to try the TIER Shibboleth IdP image. At the time we were setting up our IdP I think the TIER images were still wrapped up bulky VM images and it wasn't what we were looking for but I understand that this is not the case anymore.

I can't recall if I've already taken a brief look at the TIER Shibboleth IdP image and determined that it was more difficult to implement the Kubernetes deployment we are doing. We use a alpine based git initContainer to do a single branch clone from our git repo for the Shib configuration and that gets mounted into various locations in the IdP image (metadata, messages, conf, etc). This makes for nicely versioned configuration and easy to rollback quickly to a previous configuration if something breaks. When I get around to it and if I run into problems I'll probably jump over the the Internet2 slack channels to discuss.

On Wed, Apr 17, 2019 at 9:18 AM Paul Caskey <[hidden email]> wrote:

Hi Darren-

 

InCommon also maintains containers for Shibboleth IdP, SP (both Windows and Linux) and Grouper and COmanage.

 

See here for more info: https://spaces.at.internet2.edu/display/ITAP/InCommon+Trusted+Access+Platform+Release

 

 

TTYL

 

From: users <[hidden email]> On Behalf Of Darren Boss
Sent: Wednesday, April 17, 2019 8:14 AM
To: Shib Users <[hidden email]>
Subject: Re: SLO Problems

 

I was starting to feel bad about hijacking this thread but turns out we really were working on the same issue! I'm still having issue even when removing the jetty-rewrite.xml completely but now I'm closer to a working configuration. I see a status 502 for PropagateLogout (PropagateLogout?SessionKey=N) url when I use the developer console in chrome. In Firefox the logout now gets to the point where the red x is now displayed beside each SP and in both browsers I no longer see the error messages I reported before. I also confirmed in the dev console that the csp and frameoptions http headers are no longer there.

 

I wasn't sure that there were many using the Unicon image but I noticed that it was still getting quickly updated when a new release of the IdP came out and they recently started using multi-stage builds so it's still being supported and even if it wasn't it's pretty simple to tweak the Dockerfile to target new versions of Jetty, Shib IdP or Java and rebuild.

 

 

On Tue, Apr 16, 2019 at 7:41 PM Bob Allison <[hidden email]> wrote:

I am also using that image. I confirmed that removing jetty-rewrite.xml completely solved my problems. Only removing the last addRule was not enough for me. I guess the question is if there is any reason to have the file at all if both rules have been removed.



On Apr 16, 2019, at 13:07, Darren Boss <[hidden email]> wrote:

 

So I think I tracked it down to Jetty configuration. I'm using the Unicon shibboleth-idp-dockerized image although I rebuild it and I do make some minor tweaks as a layer on top of their image.

 

 

I think that's the culprit and that last addRule can be removed. If it works I'll create a PR to their project.

 

On Tue, Apr 16, 2019 at 11:19 AM Cantor, Scott <[hidden email]> wrote:

On 4/16/19, 9:43 AM, "users on behalf of Darren Boss" <[hidden email] on behalf of [hidden email]> wrote:

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

That doesn't inherently mean the headers are in fact correctly usable out of the box, there still might be a mistake in our understanding.

You should NOT need to alter the headers to make logout work, and I have never had to do so in any testing scenarios I've attempted. So either my testing is artificial and doesn't match a real world issue in some way, or people are mistaken somewhere about what Chrome is really saying.

-- Scott


--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]


 

--

Darren Boss

Senior Programmer/Analyst
Programmeur-analyste principal
[hidden email]
(o) 416.228.1234 x 
230

(c) 919.525.0083

--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]

 

--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]


 

--

Darren Boss

Senior Programmer/Analyst
Programmeur-analyste principal
[hidden email]
(o) 416.228.1234 x 
230

(c) 919.525.0083

--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]


--

Darren Boss

Senior Programmer/Analyst
Programmeur-analyste principal

[hidden email]

(o) 416.228.1234 x 
230
(c) 919.525.0083

--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

RE: SLO Problems

Paul Caskey

Excellent!  I agree the VM images were bulky.  Everything is in docker hub nowadays.

 

Let us know if we can help or if you have any feedback!

 

 

 

From: users <[hidden email]> On Behalf Of Darren Boss
Sent: Wednesday, April 17, 2019 9:11 AM
To: Shib Users <[hidden email]>
Subject: Re: SLO Problems

 

Yes, I was aware. It's on my long to do list to try the TIER Shibboleth IdP image. At the time we were setting up our IdP I think the TIER images were still wrapped up bulky VM images and it wasn't what we were looking for but I understand that this is not the case anymore.

 

I can't recall if I've already taken a brief look at the TIER Shibboleth IdP image and determined that it was more difficult to implement the Kubernetes deployment we are doing. We use a alpine based git initContainer to do a single branch clone from our git repo for the Shib configuration and that gets mounted into various locations in the IdP image (metadata, messages, conf, etc). This makes for nicely versioned configuration and easy to rollback quickly to a previous configuration if something breaks. When I get around to it and if I run into problems I'll probably jump over the the Internet2 slack channels to discuss.

 

On Wed, Apr 17, 2019 at 9:18 AM Paul Caskey <[hidden email]> wrote:

Hi Darren-

 

InCommon also maintains containers for Shibboleth IdP, SP (both Windows and Linux) and Grouper and COmanage.

 

See here for more info: <a href="https://spaces.at.internet2.edu/display/ITAP/InCommon&#43;Trusted&#43;Access&#43;Platform&#43;Release" target="_blank"> https://spaces.at.internet2.edu/display/ITAP/InCommon+Trusted+Access+Platform+Release

 

 

TTYL

 

From: users <[hidden email]> On Behalf Of Darren Boss
Sent: Wednesday, April 17, 2019 8:14 AM
To: Shib Users <[hidden email]>
Subject: Re: SLO Problems

 

I was starting to feel bad about hijacking this thread but turns out we really were working on the same issue! I'm still having issue even when removing the jetty-rewrite.xml completely but now I'm closer to a working configuration. I see a status 502 for PropagateLogout (PropagateLogout?SessionKey=N) url when I use the developer console in chrome. In Firefox the logout now gets to the point where the red x is now displayed beside each SP and in both browsers I no longer see the error messages I reported before. I also confirmed in the dev console that the csp and frameoptions http headers are no longer there.

 

I wasn't sure that there were many using the Unicon image but I noticed that it was still getting quickly updated when a new release of the IdP came out and they recently started using multi-stage builds so it's still being supported and even if it wasn't it's pretty simple to tweak the Dockerfile to target new versions of Jetty, Shib IdP or Java and rebuild.

 

 

On Tue, Apr 16, 2019 at 7:41 PM Bob Allison <[hidden email]> wrote:

I am also using that image. I confirmed that removing jetty-rewrite.xml completely solved my problems. Only removing the last addRule was not enough for me. I guess the question is if there is any reason to have the file at all if both rules have been removed.

 

On Apr 16, 2019, at 13:07, Darren Boss <[hidden email]> wrote:

 

So I think I tracked it down to Jetty configuration. I'm using the Unicon shibboleth-idp-dockerized image although I rebuild it and I do make some minor tweaks as a layer on top of their image.

 

 

I think that's the culprit and that last addRule can be removed. If it works I'll create a PR to their project.

 

On Tue, Apr 16, 2019 at 11:19 AM Cantor, Scott <[hidden email]> wrote:

On 4/16/19, 9:43 AM, "users on behalf of Darren Boss" <[hidden email] on behalf of [hidden email]> wrote:

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

That doesn't inherently mean the headers are in fact correctly usable out of the box, there still might be a mistake in our understanding.

You should NOT need to alter the headers to make logout work, and I have never had to do so in any testing scenarios I've attempted. So either my testing is artificial and doesn't match a real world issue in some way, or people are mistaken somewhere about what Chrome is really saying.

-- Scott


--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]


 

--

Darren Boss

Senior Programmer/Analyst
Programmeur-analyste principal
[hidden email]
(o) 416.228.1234 x 
230

(c) 919.525.0083

--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]

 

--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]


 

--

Darren Boss

Senior Programmer/Analyst
Programmeur-analyste principal
[hidden email]
(o) 416.228.1234 x 
230

(c) 919.525.0083

--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]


 

--

Darren Boss

Senior Programmer/Analyst
Programmeur-analyste principal
[hidden email]
(o) 416.228.1234 x 
230

(c) 919.525.0083


--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: SLO Problems

Darren Boss
I sort of agree but I still distrust the majority of the images in docker hub and I'd still like to rebuild any of the images I deploy in our infrastructure. That being said you are likely going to trust some base image that gets pulled from Dockerhub or Quay.

Are the TEIR images tested working for features like SLO and ECP? That might be a compelling reason for me to switch.

I think I've almost got SLO working for the Unicon image working under Kubernetes. I'm seeing this in my nginx ingress controllers logs:
2019/04/18 18:24:06 [error] 328#328: *4351387 upstream sent too big header while reading response header from upstream, client: xxx.xxx.xxx.xxx, server: xxx.xxx.xxx.xxx, request: "GET /idp/profile/PropagateLogout?SessionKey=1 HTTP/2.0", upstream: "http://xxx.xxx.xxx.xxx:8080/idp/profile/PropagateLogout?SessionKey=1", host: "xxx.xxx.xxx.xxx", referrer: "https://xxx.xxx.xxx.xxx/idp/profile/Logout?execution=e4s2"

TLS gets terminated at the ingress controller in case someone was goign to point out the http url. Crossing fingers that some minor tweaking of the configuration for the nginx reverse proxy will solve the problem.

On Wed, Apr 17, 2019 at 10:13 AM Paul Caskey <[hidden email]> wrote:

Excellent!  I agree the VM images were bulky.  Everything is in docker hub nowadays.

 

Let us know if we can help or if you have any feedback!

 

 

 

From: users <[hidden email]> On Behalf Of Darren Boss
Sent: Wednesday, April 17, 2019 9:11 AM
To: Shib Users <[hidden email]>
Subject: Re: SLO Problems

 

Yes, I was aware. It's on my long to do list to try the TIER Shibboleth IdP image. At the time we were setting up our IdP I think the TIER images were still wrapped up bulky VM images and it wasn't what we were looking for but I understand that this is not the case anymore.

 

I can't recall if I've already taken a brief look at the TIER Shibboleth IdP image and determined that it was more difficult to implement the Kubernetes deployment we are doing. We use a alpine based git initContainer to do a single branch clone from our git repo for the Shib configuration and that gets mounted into various locations in the IdP image (metadata, messages, conf, etc). This makes for nicely versioned configuration and easy to rollback quickly to a previous configuration if something breaks. When I get around to it and if I run into problems I'll probably jump over the the Internet2 slack channels to discuss.

 

On Wed, Apr 17, 2019 at 9:18 AM Paul Caskey <[hidden email]> wrote:

Hi Darren-

 

InCommon also maintains containers for Shibboleth IdP, SP (both Windows and Linux) and Grouper and COmanage.

 

See here for more info: https://spaces.at.internet2.edu/display/ITAP/InCommon+Trusted+Access+Platform+Release

 

 

TTYL

 

From: users <[hidden email]> On Behalf Of Darren Boss
Sent: Wednesday, April 17, 2019 8:14 AM
To: Shib Users <[hidden email]>
Subject: Re: SLO Problems

 

I was starting to feel bad about hijacking this thread but turns out we really were working on the same issue! I'm still having issue even when removing the jetty-rewrite.xml completely but now I'm closer to a working configuration. I see a status 502 for PropagateLogout (PropagateLogout?SessionKey=N) url when I use the developer console in chrome. In Firefox the logout now gets to the point where the red x is now displayed beside each SP and in both browsers I no longer see the error messages I reported before. I also confirmed in the dev console that the csp and frameoptions http headers are no longer there.

 

I wasn't sure that there were many using the Unicon image but I noticed that it was still getting quickly updated when a new release of the IdP came out and they recently started using multi-stage builds so it's still being supported and even if it wasn't it's pretty simple to tweak the Dockerfile to target new versions of Jetty, Shib IdP or Java and rebuild.

 

 

On Tue, Apr 16, 2019 at 7:41 PM Bob Allison <[hidden email]> wrote:

I am also using that image. I confirmed that removing jetty-rewrite.xml completely solved my problems. Only removing the last addRule was not enough for me. I guess the question is if there is any reason to have the file at all if both rules have been removed.

 

On Apr 16, 2019, at 13:07, Darren Boss <[hidden email]> wrote:

 

So I think I tracked it down to Jetty configuration. I'm using the Unicon shibboleth-idp-dockerized image although I rebuild it and I do make some minor tweaks as a layer on top of their image.

 

 

I think that's the culprit and that last addRule can be removed. If it works I'll create a PR to their project.

 

On Tue, Apr 16, 2019 at 11:19 AM Cantor, Scott <[hidden email]> wrote:

On 4/16/19, 9:43 AM, "users on behalf of Darren Boss" <[hidden email] on behalf of [hidden email]> wrote:

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

That doesn't inherently mean the headers are in fact correctly usable out of the box, there still might be a mistake in our understanding.

You should NOT need to alter the headers to make logout work, and I have never had to do so in any testing scenarios I've attempted. So either my testing is artificial and doesn't match a real world issue in some way, or people are mistaken somewhere about what Chrome is really saying.

-- Scott


--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]


 

--

Darren Boss

Senior Programmer/Analyst
Programmeur-analyste principal
[hidden email]
(o) 416.228.1234 x 
230

(c) 919.525.0083

--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]

 

--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]


 

--

Darren Boss

Senior Programmer/Analyst
Programmeur-analyste principal
[hidden email]
(o) 416.228.1234 x 
230

(c) 919.525.0083

--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]


 

--

Darren Boss

Senior Programmer/Analyst
Programmeur-analyste principal
[hidden email]
(o) 416.228.1234 x 
230

(c) 919.525.0083

--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]


--

Darren Boss

Senior Programmer/Analyst
Programmeur-analyste principal

[hidden email]

(o) 416.228.1234 x 
230
(c) 919.525.0083

--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

RE: SLO Problems

Paul Caskey

If those 2 items aren’t working, then nobody has reported it.  And, in that case, we’d get it fixed.

 

And, FWIW, source for the Linux IdP container is here (and Windows IdP is here).

 

 

Thanks - TTYL

 

From: users <[hidden email]> On Behalf Of Darren Boss
Sent: Thursday, April 18, 2019 1:41 PM
To: Shib Users <[hidden email]>
Subject: Re: SLO Problems

 

I sort of agree but I still distrust the majority of the images in docker hub and I'd still like to rebuild any of the images I deploy in our infrastructure. That being said you are likely going to trust some base image that gets pulled from Dockerhub or Quay.

 

Are the TEIR images tested working for features like SLO and ECP? That might be a compelling reason for me to switch.

 

I think I've almost got SLO working for the Unicon image working under Kubernetes. I'm seeing this in my nginx ingress controllers logs:
2019/04/18 18:24:06 [error] 328#328: *4351387 upstream sent too big header while reading response header from upstream, client: xxx.xxx.xxx.xxx, server: xxx.xxx.xxx.xxx, request: "GET /idp/profile/PropagateLogout?SessionKey=1 HTTP/2.0", upstream: "http://xxx.xxx.xxx.xxx:8080/idp/profile/PropagateLogout?SessionKey=1", host: "xxx.xxx.xxx.xxx", referrer: "https://xxx.xxx.xxx.xxx/idp/profile/Logout?execution=e4s2"

 

TLS gets terminated at the ingress controller in case someone was goign to point out the http url. Crossing fingers that some minor tweaking of the configuration for the nginx reverse proxy will solve the problem.

 

On Wed, Apr 17, 2019 at 10:13 AM Paul Caskey <[hidden email]> wrote:

Excellent!  I agree the VM images were bulky.  Everything is in docker hub nowadays.

 

Let us know if we can help or if you have any feedback!

 

 

 

From: users <[hidden email]> On Behalf Of Darren Boss
Sent: Wednesday, April 17, 2019 9:11 AM
To: Shib Users <[hidden email]>
Subject: Re: SLO Problems

 

Yes, I was aware. It's on my long to do list to try the TIER Shibboleth IdP image. At the time we were setting up our IdP I think the TIER images were still wrapped up bulky VM images and it wasn't what we were looking for but I understand that this is not the case anymore.

 

I can't recall if I've already taken a brief look at the TIER Shibboleth IdP image and determined that it was more difficult to implement the Kubernetes deployment we are doing. We use a alpine based git initContainer to do a single branch clone from our git repo for the Shib configuration and that gets mounted into various locations in the IdP image (metadata, messages, conf, etc). This makes for nicely versioned configuration and easy to rollback quickly to a previous configuration if something breaks. When I get around to it and if I run into problems I'll probably jump over the the Internet2 slack channels to discuss.

 

On Wed, Apr 17, 2019 at 9:18 AM Paul Caskey <[hidden email]> wrote:

Hi Darren-

 

InCommon also maintains containers for Shibboleth IdP, SP (both Windows and Linux) and Grouper and COmanage.

 

See here for more info: <a href="https://spaces.at.internet2.edu/display/ITAP/InCommon&#43;Trusted&#43;Access&#43;Platform&#43;Release" target="_blank"> https://spaces.at.internet2.edu/display/ITAP/InCommon+Trusted+Access+Platform+Release

 

 

TTYL

 

From: users <[hidden email]> On Behalf Of Darren Boss
Sent: Wednesday, April 17, 2019 8:14 AM
To: Shib Users <[hidden email]>
Subject: Re: SLO Problems

 

I was starting to feel bad about hijacking this thread but turns out we really were working on the same issue! I'm still having issue even when removing the jetty-rewrite.xml completely but now I'm closer to a working configuration. I see a status 502 for PropagateLogout (PropagateLogout?SessionKey=N) url when I use the developer console in chrome. In Firefox the logout now gets to the point where the red x is now displayed beside each SP and in both browsers I no longer see the error messages I reported before. I also confirmed in the dev console that the csp and frameoptions http headers are no longer there.

 

I wasn't sure that there were many using the Unicon image but I noticed that it was still getting quickly updated when a new release of the IdP came out and they recently started using multi-stage builds so it's still being supported and even if it wasn't it's pretty simple to tweak the Dockerfile to target new versions of Jetty, Shib IdP or Java and rebuild.

 

 

On Tue, Apr 16, 2019 at 7:41 PM Bob Allison <[hidden email]> wrote:

I am also using that image. I confirmed that removing jetty-rewrite.xml completely solved my problems. Only removing the last addRule was not enough for me. I guess the question is if there is any reason to have the file at all if both rules have been removed.

 

On Apr 16, 2019, at 13:07, Darren Boss <[hidden email]> wrote:

 

So I think I tracked it down to Jetty configuration. I'm using the Unicon shibboleth-idp-dockerized image although I rebuild it and I do make some minor tweaks as a layer on top of their image.

 

 

I think that's the culprit and that last addRule can be removed. If it works I'll create a PR to their project.

 

On Tue, Apr 16, 2019 at 11:19 AM Cantor, Scott <[hidden email]> wrote:

On 4/16/19, 9:43 AM, "users on behalf of Darren Boss" <[hidden email] on behalf of [hidden email]> wrote:

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

That doesn't inherently mean the headers are in fact correctly usable out of the box, there still might be a mistake in our understanding.

You should NOT need to alter the headers to make logout work, and I have never had to do so in any testing scenarios I've attempted. So either my testing is artificial and doesn't match a real world issue in some way, or people are mistaken somewhere about what Chrome is really saying.

-- Scott


--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]


 

--

Darren Boss

Senior Programmer/Analyst
Programmeur-analyste principal
[hidden email]
(o) 416.228.1234 x 
230

(c) 919.525.0083

--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]

 

--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]


 

--

Darren Boss

Senior Programmer/Analyst
Programmeur-analyste principal
[hidden email]
(o) 416.228.1234 x 
230

(c) 919.525.0083

--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]


 

--

Darren Boss

Senior Programmer/Analyst
Programmeur-analyste principal
[hidden email]
(o) 416.228.1234 x 
230

(c) 919.525.0083

--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]


 

--

Darren Boss

Senior Programmer/Analyst
Programmeur-analyste principal
[hidden email]
(o) 416.228.1234 x 
230

(c) 919.525.0083


--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: SLO Problems

Darren Boss
For anyone deploying under Kubernetes using the nginx ingress controller you will likely have to set this annotation in your ingress:

The default is 4k. Similar issues would likely be the case if you were using any nginx reverse proxy configuration in front of your IdP.

After removing the jetty-rewrite.xml file from the Docker image and setting this annotation in my ingress, I can confirm that it has solved the issue with SLO for me where the SP is configured correctly.

On Thu, Apr 18, 2019 at 2:53 PM Paul Caskey <[hidden email]> wrote:

If those 2 items aren’t working, then nobody has reported it.  And, in that case, we’d get it fixed.

 

And, FWIW, source for the Linux IdP container is here (and Windows IdP is here).

 

 

Thanks - TTYL

 

From: users <[hidden email]> On Behalf Of Darren Boss
Sent: Thursday, April 18, 2019 1:41 PM
To: Shib Users <[hidden email]>
Subject: Re: SLO Problems

 

I sort of agree but I still distrust the majority of the images in docker hub and I'd still like to rebuild any of the images I deploy in our infrastructure. That being said you are likely going to trust some base image that gets pulled from Dockerhub or Quay.

 

Are the TEIR images tested working for features like SLO and ECP? That might be a compelling reason for me to switch.

 

I think I've almost got SLO working for the Unicon image working under Kubernetes. I'm seeing this in my nginx ingress controllers logs:
2019/04/18 18:24:06 [error] 328#328: *4351387 upstream sent too big header while reading response header from upstream, client: xxx.xxx.xxx.xxx, server: xxx.xxx.xxx.xxx, request: "GET /idp/profile/PropagateLogout?SessionKey=1 HTTP/2.0", upstream: "http://xxx.xxx.xxx.xxx:8080/idp/profile/PropagateLogout?SessionKey=1", host: "xxx.xxx.xxx.xxx", referrer: "https://xxx.xxx.xxx.xxx/idp/profile/Logout?execution=e4s2"

 

TLS gets terminated at the ingress controller in case someone was goign to point out the http url. Crossing fingers that some minor tweaking of the configuration for the nginx reverse proxy will solve the problem.

 

On Wed, Apr 17, 2019 at 10:13 AM Paul Caskey <[hidden email]> wrote:

Excellent!  I agree the VM images were bulky.  Everything is in docker hub nowadays.

 

Let us know if we can help or if you have any feedback!

 

 

 

From: users <[hidden email]> On Behalf Of Darren Boss
Sent: Wednesday, April 17, 2019 9:11 AM
To: Shib Users <[hidden email]>
Subject: Re: SLO Problems

 

Yes, I was aware. It's on my long to do list to try the TIER Shibboleth IdP image. At the time we were setting up our IdP I think the TIER images were still wrapped up bulky VM images and it wasn't what we were looking for but I understand that this is not the case anymore.

 

I can't recall if I've already taken a brief look at the TIER Shibboleth IdP image and determined that it was more difficult to implement the Kubernetes deployment we are doing. We use a alpine based git initContainer to do a single branch clone from our git repo for the Shib configuration and that gets mounted into various locations in the IdP image (metadata, messages, conf, etc). This makes for nicely versioned configuration and easy to rollback quickly to a previous configuration if something breaks. When I get around to it and if I run into problems I'll probably jump over the the Internet2 slack channels to discuss.

 

On Wed, Apr 17, 2019 at 9:18 AM Paul Caskey <[hidden email]> wrote:

Hi Darren-

 

InCommon also maintains containers for Shibboleth IdP, SP (both Windows and Linux) and Grouper and COmanage.

 

See here for more info: https://spaces.at.internet2.edu/display/ITAP/InCommon+Trusted+Access+Platform+Release

 

 

TTYL

 

From: users <[hidden email]> On Behalf Of Darren Boss
Sent: Wednesday, April 17, 2019 8:14 AM
To: Shib Users <[hidden email]>
Subject: Re: SLO Problems

 

I was starting to feel bad about hijacking this thread but turns out we really were working on the same issue! I'm still having issue even when removing the jetty-rewrite.xml completely but now I'm closer to a working configuration. I see a status 502 for PropagateLogout (PropagateLogout?SessionKey=N) url when I use the developer console in chrome. In Firefox the logout now gets to the point where the red x is now displayed beside each SP and in both browsers I no longer see the error messages I reported before. I also confirmed in the dev console that the csp and frameoptions http headers are no longer there.

 

I wasn't sure that there were many using the Unicon image but I noticed that it was still getting quickly updated when a new release of the IdP came out and they recently started using multi-stage builds so it's still being supported and even if it wasn't it's pretty simple to tweak the Dockerfile to target new versions of Jetty, Shib IdP or Java and rebuild.

 

 

On Tue, Apr 16, 2019 at 7:41 PM Bob Allison <[hidden email]> wrote:

I am also using that image. I confirmed that removing jetty-rewrite.xml completely solved my problems. Only removing the last addRule was not enough for me. I guess the question is if there is any reason to have the file at all if both rules have been removed.

 

On Apr 16, 2019, at 13:07, Darren Boss <[hidden email]> wrote:

 

So I think I tracked it down to Jetty configuration. I'm using the Unicon shibboleth-idp-dockerized image although I rebuild it and I do make some minor tweaks as a layer on top of their image.

 

 

I think that's the culprit and that last addRule can be removed. If it works I'll create a PR to their project.

 

On Tue, Apr 16, 2019 at 11:19 AM Cantor, Scott <[hidden email]> wrote:

On 4/16/19, 9:43 AM, "users on behalf of Darren Boss" <[hidden email] on behalf of [hidden email]> wrote:

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

That doesn't inherently mean the headers are in fact correctly usable out of the box, there still might be a mistake in our understanding.

You should NOT need to alter the headers to make logout work, and I have never had to do so in any testing scenarios I've attempted. So either my testing is artificial and doesn't match a real world issue in some way, or people are mistaken somewhere about what Chrome is really saying.

-- Scott


--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]


 

--

Darren Boss

Senior Programmer/Analyst
Programmeur-analyste principal
[hidden email]
(o) 416.228.1234 x 
230

(c) 919.525.0083

--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]

 

--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]


 

--

Darren Boss

Senior Programmer/Analyst
Programmeur-analyste principal
[hidden email]
(o) 416.228.1234 x 
230

(c) 919.525.0083

--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]


 

--

Darren Boss

Senior Programmer/Analyst
Programmeur-analyste principal
[hidden email]
(o) 416.228.1234 x 
230

(c) 919.525.0083

--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]


 

--

Darren Boss

Senior Programmer/Analyst
Programmeur-analyste principal
[hidden email]
(o) 416.228.1234 x 
230

(c) 919.525.0083

--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]


--

Darren Boss

Senior Programmer/Analyst
Programmeur-analyste principal

[hidden email]

(o) 416.228.1234 x 
230
(c) 919.525.0083

--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]