QA (Admin-UI + CASA ): Session not revoked after password change or deactivation.

[mzico]

QA Test Plan: Session Not Revoked After Password Change or Deactivation

Ticket Reference

Ticket ID: [Tickets-160] Title: Sessions not revoked after password change or user deactivation

Objective

To verify that user sessions are properly revoked when:

• The user's password is changed.
• The user is deactivated.

Affected Components

• Gluu Flex: Versions 5.5.0 and 5.8.0 [ TEST IN 5.9.0 ]
• Admin UI
• Casa UI

Pre-Requisites

1. Deployed Gluu Flex 5.9.0 Environment.
2. Admin UI and Casa UI must be accessible.
3. Access to modify users (via Admin UI or LDAP).
4. Two separate browser sessions (e.g., normal + incognito) or devices.

Test User Setup

1. Create a test user (e.g., testuser01).
2. Ensure testuser01 has necessary roles/permissions to access Admin UI and Casa UI.
3. Record the initial password (e.g., Test@1234).

---

Test Case 1: Session Not Revoked After Password Change

Steps

1. Login Session

   • Open Admin UI or Casa in a browser tab.
   • Log in as testuser01 using initial credentials.

2. Password Change

   • Open another browser session (incognito or another browser).
   • Log in as an admin.
   • Change testuser01's password (e.g., change to Test@5678).

3. Refresh Active Session

   • Go back to the first session where the user is still logged in.
   • Refresh the browser page.

Expected Result

• The session should be revoked.
• User should be redirected to login screen.

Actual Result

• The session remains active.

---

Test Case 2: Session Not Revoked After User Deactivation

Steps

1. Login Session

   • Open Admin UI or Casa in a browser tab.
   • Log in as testuser01.

2. Deactivate User

   • From another session (admin user), deactivate testuser01.
   • This can be done via Admin UI or LDAP (set jansStatus to inactive).

3. Refresh Active Session

   • Return to the active user session.
   • Refresh the page.

Expected Result

• Session should be revoked.
• User should see an error or be redirected to the login page.

Actual Result

• Session remains active.

---

Notes

• This behavior is a security risk because it allows an attacker to remain logged in even after the password is changed.
• A proper fix should revoke user sessions and associated tokens on password update or deactivation.
• Apply changes to both Admin UI and Casa UI session validators.
• Optionally, trigger a logout via browser redirect or refresh token expiration.

---

Attachments

• Reference video: Please talk to Zico for video shared by customer.
• Original ticket: Please talk to Zico for ticket info.

[ossdhaval]

The password change and user deactivation are happening out of band. Implementation will likely leverage the back channel logout feature provided by the auth server. Adding @yuriyz and @nynymike for their view.

@mzico @manojs1978 Please create separate issues for Casa(turn this one into a Casa only issue) and Admin UI(create a new one in the Flex repo).

[yuriyz]

On user deletion or deactivation we need to call Global Token Revocation to revoke all sessions and tokens of the user. If user is active and we want to end current session then we need to call front channel or back channel logout.

[ossdhaval]

@yuriyz So will this be a change required in the AS or Apps(Casa, admin-UI)? Or both?

[yuriyz]

As you may know on AS side Global Token Revocation, front channel and backchannel are implemented. @ossdhaval Are all docs about it present? Can you revise docs and confirm ?

[quer0016]

Hello team,

I’d like to suggest a security improvement related to session handling in AdminUI.

Currently, when an admin changes a user's status to inactive, the session remains active if the user refreshes it. This behavior is consistent with other user modifications, such as password or role changes.

To strengthen security, I propose that any of the following admin actions should automatically invalidate the user's active sessions and remove the associated session tokens:

Password change

Status change (e.g., active → inactive)

Role change

This would help prevent unauthorized access after critical user changes and align with best practices in session management.

Thanks for considering this improvement.

[nynymike]

@ossdhaval the best person to take this on is @faisalsiddique4400 and @duttarnab.

[ossdhaval]

@faisalsiddique4400 @duttarnab Can you share your views or any questions you may have? If this is ready to go into implementation, I suggest you to create two sub-issues to track Admin Ui and Casa separately.

[duttarnab]

Hi @quer0016

To strengthen security, I propose that any of the following admin actions should automatically invalidate the user's active sessions and remove the associated session tokens:

Sorry for joining this task late. I’d like your suggestion on a use case: if a user, for example Alex, changes their password using the Admin UI, they should be automatically logged out afterwards since all active sessions would be invalidated.

[quer0016]

Hi @duttarnab I like the suggestion that fixes the password-change issue, but if a user’s role changes, can the same solution be applied?