BTW ticket target version probably should not be 12.2.8 as this has been released already.
Boris and I were testing strange behavior where IdM fails to redirect back to itself when the user presses the logout button.
Steps to reproduce:
- Have IdM 13.1.x (or maybe 13.0.x suffices? 12.2.8 is definitelly working ok).
- Have working CAS.
- Have everything working in the IAM appliance.
- IdM <-> CAS authentication via CAS protocol is enabled.
- Sign-in into the IdM.
- In the IdM GUI, click the logout button at the top-right corner.
- App will redirect to CAS, then to itself and you will get "Login failed" message from IdM.
There are some strange HTTP DELETE in the log ending up with 403. It looks like IdM tries to delete some session token more than once:
Nov 9 10:06:49 appliance195.bcv web-proxy[984]: 172.31.255.148 - - [09/Nov/2023:09:06:49 +0000] "DELETE /idm/api/v1/logout HTTP/1.1" 403 302 "https://appliance195.bcv/idm/" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/119.0.0.0 Safari/537.36"
Nov 9 10:06:49 appliance195.bcv web-proxy[984]: {"transaction":{"client_ip":"172.31.255.148","time_stamp":"Thu Nov 9 09:06:49 2023","server_id":"060010b052d6a8d3b97e625538842eb22742563a","client_port":62857,"host_ip":"172.17.0.6","host_port":443,"unique_id":"1699520809","request":{"method":"DELETE","http_version":1.1,"uri":"/idm/api/v1/logout"},"response":{"http_code":403,"headers":{"Strict-Transport-Security":"max-age=31536000 ; includeSubDomains","Cache-Control":"no-cache, no-store, max-age=0, must-revalidate","Expires":"0","Pragma":"no-cache","X-XSS-Protection":"1; mode=block","Connection":"keep-alive","Keep-Alive":"timeout=75","X-Content-Type-Options":"nosniff","Content-Type":"application/hal+json;charset=UTF-8","Date":"Thu, 09 Nov 2023 09:06:49 GMT","Server":"nginx/1.20.2","X-Frame-Options":"DENY"}},"producer":{"modsecurity":"ModSecurity v3.0.6 (Linux)","connector":"ModSecurity-nginx v1.0.2","secrules_engine":"Enabled","components":[]},"messages":[]}}
Upon fail, IdM logs also something like:
Nov 9 10:04:36 appliance195.bcv czechidm[984]: 2023-11-09 10:04:36.659 WARN 240767124 --- [http-nio-8080-exec-19] e.b.idm.core.security.auth.filter.JwtIdmAuthenticationFilter.authorize : Invalid token, reason: [Authorities changed or user logged out, log in again.]
Nov 9 10:04:36 appliance195.bcv czechidm[984]: 2023-11-09 10:04:36.661 WARN 240767126 --- [http-nio-8080-exec-19] eu.bcvsolutions.idm.core.exception.RestErrorAttributes.getErrorAttributes : [core:FORBIDDEN:3a7889d8-5b06-4f3e-a866-894fba19849e] Forbidden. ({path=/idm/api/v1/logout, message=Access Denied})
What we found out is that 13.1.0 has messed up redirects on the logout processing. The redirect to CAS contains /cas/logout?service=https://idm url here/idm/cas-login-response where it probably should contain cas-logout-response.
Network log from 13.1.0:
https://appliance195.bcv/idm/api/v1/authentication/cas-logout-request
-> https://appliance195.bcv/cas/logout?service=https://appliance195.bcv/idm/api/v1/authentication/cas-login-response
-> https://appliance195.bcv/idm/api/v1/authentication/cas-login-response
-> https://appliance195.bcv/idm/#/cas-login-response?status-code=log_in_failed
Network log from 12.2.8 (which works fine):
https://172.31.255.147/idm/api/v1/authentication/cas-logout-request
-> https://172.31.255.147/cas/logout?service=https://172.31.255.147/idm/api/v1/authentication/cas-logout-response
-> https://172.31.255.147/idm/api/v1/authentication/cas-logout-response
-> https://172.31.255.147/idm/#/cas-logout-response
