Hello,
We noticed an issue on CAS 5.3 with OIDC. I finally realized what maybe going on, but do not have a solution.
App uses CAS for authentication via OIDC, App redirects to CAS login page. When people bookmark the apps, the first opportunity they have is the CAS login page, the URL usually reads like this:
Next time, they use the bookmark and go straight to this URL, as oppose to let App redirect to CAS. This is where the problem comes with OIDC.
Here is the flow when user type up the App endpoint in browser and let App redirect:
GET /cas/oidc/authorize/...... (this is due to the OIDC client in App side, crucial first step)
GET /cas/login?service=.....cas/oauth2.0/callbackAuthorize/....
login page shows up, user bookmarks it, and enter credentials
POST /cas/login?service=.....cas/oauth2.0/callbackAuthorize/....
GET /cas5/p3/serviceValidate?ticket=
GET /cas5/oauth2.0/callbackAuthorize?client_id=
GET /cas5/oidc/authorize?client_id=
After user logout, and close browser, Restart browser, they use the saved bookmark. Now the flow is showing CAS login page immediately without going through the first endpoint on /odic/authorize (see above).
When user login, they are redirected to root /, as oppose to proceed to /oidc/authorize endpoint, this is due to how pac4j works. it almost like a stack pushing/popping, and we did not anything to pop, so we default to root. The root is usually the wrong page, such as the Tomcat welcome page or the domain root.
This is fairly consistently seen on IE.
Does that make sense? I think this could be happening with any bookmarked CAS login page with service parameter and will be seen in OIDC client apps.
Any idea to work around or fix this?
Thanks,
Yan