By: Avi Khetarpal user 31 Oct 2017 at 9:52 p.m. CDT

13 Responses
Avi Khetarpal gravatar
Hi there, I've been working through migrating our Gluu 3.0.2 box (which we had working in a stable and reliable manner) to 3.1.x, and after rejigging our APIs to call the new endpoints for SCIM and OpenID things mostly seem to be back to normal, but one issue we have outstanding is the logout flow. We're calling the end_session endpoint with an id_token_hint and session_state and post_logout_redirect_uri in the GET request. I'm correctly getting the HTML response from the Gluu server as before saying: ``` <!DOCTYPE html><html><head><script>window.onload=function() {window.location='https://[Logout URI here]/'}</script><title>Gluu Generated logout page</title></head><body>Logout requests sent.<br/></body></html> ``` That redirects the user back to the main site, where we destroy the application's session and expect to show the user a login screen. However, when the client reaches the step where we'd show the login screen, it looks like the Gluu session has persisted and the client is being authenticated and redirected back to a logged in state. Previously, in 3.0.2, we'd see the Gluu login screen (as expected) using the exact same end_session endpoint usage. Do you guys have any ideas on what might have caused this change in behaviour? I do have the Open ID client set up with the logout URLs and would expect that if Gluu is redirecting me saying "Logout requests sent", there's no error in configuration. Thanks, Avi P.S. The https://support.gluu.org/logout link is shared by both the site's logout mechanism and the ticket category for Logout, meaning we can't click "View All" for the Logout tickets - we just get logged out instead. :)

By Aliaksandr Samuseu staff 31 Oct 2017 at 11:03 p.m. CDT

Aliaksandr Samuseu gravatar
Hi, Avi. Could you please capture everything happening in browser during login and subsequent logout (which fails to kill session at Gluu) with something like **SAMLTracer** plugin for Firefox, or a similar plugin for any other browser, do export of the capture, and share it here? The plugin you'll choose must be able to capture not only headers of HTTP request/response, but body of messages as well.

By Michael Schwartz staff 09 Nov 2017 at 1:20 a.m. CST

Michael Schwartz gravatar
Was this ever resolved?

By Aliaksandr Samuseu staff 09 Nov 2017 at 7:35 a.m. CST

Aliaksandr Samuseu gravatar
I couldn't reproduce it in my test 3.1.1 instance. After calling logout endpoint from RP my oxAuth session is killed and next time I'm sent to authz endpoint I'm forced to log in again. If Avi could share results of capture I suggested and whole contents of `/opt/gluu/jetty/oxauth/logs/` gathered shortly after the issue is encountered, there may happen to be some clues.

By Aliaksandr Samuseu staff 09 Nov 2017 at 7:56 a.m. CST

Aliaksandr Samuseu gravatar
That may be unrelated, but I remember having some issues with `gplus` authentication script in latest packages. After the initial authentication, even when I tried to log out, when next time I was sent to login page for a new OIDC flow, if my session at google was still alive, the script won't give me a chance to choose anything, and just immediately were proceeding to log me in. Yet it wasn't completely transparent, it was obvious what was happening. Perhaps you may use some other kind of auth script in your setup, Avi, which now malfunctions in 3.1.1?

By Avi Khetarpal user 09 Nov 2017 at 2:30 p.m. CST

Avi Khetarpal gravatar
Hi Aliaksandr, Thanks for taking the time to try to replicate the issue. Unfortunately, I've had to put the problem on hold for a few days since we were looking to demo some of the stuff that involved our Gluu integrations over the week, so I ended up restoring our last stable 3.0.2 snapshot so the demos could work reliably. I'm working with our sysadmin to get a second server with the 3.1.1 snapshot so that I can get back to using it for development without breaking any potential demos we may need to do. I'll certainly be back with a bit more detail once I have access to the 3.1.1 server again. Thanks for your time and patience, Avi

By Aliaksandr Samuseu staff 09 Nov 2017 at 2:35 p.m. CST

Aliaksandr Samuseu gravatar
Thanks, Avi. May I also ask you to elaborate a bit regarding method of migration you used prior to encountering this issue first? >I've been working through migrating our Gluu 3.0.2 box (which we had working in a stable and reliable manner) to 3.1.x Did you use some migration script, or just manually recreated your configuration in the new instance?

By Avi Khetarpal user 09 Nov 2017 at 2:55 p.m. CST

Avi Khetarpal gravatar
Hi Aliaksandr, I used a migration script from [https://github.com/GluuFederation/community-edition-setup/blob/upgrade_script_3.1/static/scripts/3031_Readme.md](https://github.com/GluuFederation/community-edition-setup/blob/upgrade_script_3.1/static/scripts/3031_Readme.md) to upgrade to 3.1.0, then replaced the .WAR files with 3.1.1 when they were available. I experienced the same issue in 3.1.0, however. Thanks, Avi

By Aliaksandr Samuseu staff 15 Nov 2017 at 12:28 p.m. CST

Aliaksandr Samuseu gravatar
Hi, Avi. What is the current status of that issue? Are you still keep experiencing it? If you do, do you also use any custom auth script in your setup? If it's the case, may I ask you to share it with us? I also still would like to see the capture I mentioned before. Please use **SAMLTracer** Firefox plugin (or any other similar plugin for any browser, capable of capturing all HTTP traffic, including body of messages) to get a dump of everything what happens during this suspicious flow (initial login, logout, new login attempt which suddenly doesn't require submitting credentials). Please also provide a part of `/opt/gluu/jetty/oxauth/logs/oxauth.log` related to this flow (more or so).

By Avi Khetarpal user 16 Nov 2017 at 4:23 p.m. CST

Avi Khetarpal gravatar
Hi Aliaksandr, Thanks for your patience. I've managed to get our 3.1.1 server back up and running and got the details you requested. The SAMLTracer JSON export is linked. I've obfuscated the actual domain names but made it clear which is the application and which is the Gluu server. The one detail that might be unclear there is the https://application.mydomain.com/logout request. That request calls a simple server side script which performs the following: If there is currently a logged in user in the application's session, 1. Send the end_session GET request to https://gluuserver.mydomain.com/oxauth/restv1/end_session?id_token_hint=(session ID token)&session_state=(session state)&post_logout_redirect_uri=https://application.mydomain.com/home/ 2. Output the response from that request to the browser, which is returning: <!DOCTYPE html><html><head><script>window.onload=function() {window.location='https://application.mydomain.com/home/'}</script><title>Gluu Generated logout page</title></head><body>Logout requests sent.<br/></body></html> 3. Clear application's session. After that, we're correctly redirected to /home in the application and attempt to start the login process again but instead of getting a login screen we're immediately passed back an active session. The only thing I can see in the oxauth.log within the timestamps of these requests are several lines of: INFO [qtp2008017533-18] [org.xdi.oxauth.auth.Authenticator] (Authenticator.java:205) - Authentication success for Client: '@!DFE8.29E5.39AE.805F!0001!B7E5.ACFE!0008!308F.160E.C481.7100' Thanks very much for your time and apologies for the delay. Let me know if you need any further details from me - I should be a lot quicker to respond this time since the server is back in my hands. Thanks, Avi

By Aliaksandr Samuseu staff 16 Nov 2017 at 5:12 p.m. CST

Aliaksandr Samuseu gravatar
Thanks, Avi. What about a custom authentication script in your setup? Do you use some?

By Avi Khetarpal user 16 Nov 2017 at 5:13 p.m. CST

Avi Khetarpal gravatar
We've only used the 2FA TOTP custom authentication script but it's currently inactive on this instance.

By Aliaksandr Samuseu staff 16 Nov 2017 at 5:31 p.m. CST

Aliaksandr Samuseu gravatar
>We've only used the 2FA TOTP custom authentication script but it's currently inactive on this instance. Could you elaborate? What are your current settings at "Manage Authentication -> Default Authentication method" tab? At "Manage Custom scripts" page is "Enabled" checkbox unset for the script?

By Avi Khetarpal user 16 Nov 2017 at 5:39 p.m. CST

Avi Khetarpal gravatar
The Default Authentication Method is using auth_ldap_server for both Default acr and oxTrust acr. The custom script (which was a slightly modified version of the standard HOTP/TOTP authentication module script) is indeed unchecked for the Enable checkbox. One further detail I may have forgotten to mention earlier is that logging out through oxTrust DOES work and kills the session correctly. It's currently the only way we can logout, by going to oxTrust, clicking Logout there, and then refreshing the application page, which then shows the Login screen again, as expected.