# 5. Session Management

User Type: **Super Administrator**
Source: *Mi Digital Academy - Education CRM Features Document*

---

## 5. Session Management

### 5.1 Active Session Tracking
**What it does:** Maintains a live record of every active session per user — what device and browser, from which IP and approximate location, when it started, and when it was last active — and exposes that record both to the user (in their profile) and to the Super Admin (in the user directory). This is the foundation for detecting unauthorized access, supporting "where am I logged in?" questions, and executing targeted session termination.

**Sub-features:**
- Session record fields: device type, browser/app and version, IP address, approximate location, start time, last-activity time, authentication method used
- Current-session identification: the user's own active session is marked distinctly from their other sessions
- User-facing "Active sessions" list in profile settings with per-session "sign out" action
- Admin-facing session view per user in the user directory, with the same detail plus authentication method
- Idle detection: last-activity tracking that distinguishes active, idle, and expired sessions
- Session state lifecycle: active → idle → expired/terminated, with state visible in both views
- Termination actions: user self-termination, admin single-session termination, admin terminate-all
- Retention of session history per policy for auditing (then purged)
- Notification when a session is terminated by an admin

**Super Administrator User Journey:**
1. Security monitoring raises a warning: "New device + new location login" for a user. Super Admin opens the user's record in the user directory.
2. Opens the user's "Active sessions" view. It lists three sessions: the user's usual phone (active, last activity 5 minutes ago), a laptop at the user's home location (idle, last activity 2 hours ago), and a browser in a city the user has never used (active, started 10 minutes ago).
3. Super Admin reviews the suspicious session's detail: device type, browser, IP, approximate location, and the authentication method used (password + OTP succeeded).
4. Contacts the user through the support channel to confirm whether they recognize the login. The user says they did not.
5. Super Admin terminates the suspicious session from the admin view. The session is ended immediately on its next request, and the user is notified that a session was signed out by an administrator.
6. Because a valid OTP was used on the suspicious session (suggesting the attacker may have had temporary access to the user's phone), Super Admin also triggers a password reset for the account and reviews the user's 2FA channel state.
7. Super Admin records the incident in the security audit trail with the outcome, and the event appears on the security monitoring dashboard as a resolved incident.
8. Later, Super Admin reviews the session-history retention: terminated and expired sessions remain queryable for the retention period, then are purged automatically.

**Rules & Edge Cases:**
- Location is approximate (IP-derived) and always labeled as such in the UI to avoid implying precision.
- Terminating a session ends it on the session's next request; for an actively used page this is effectively immediate.
- The user's own current session is always identifiable and cannot be accidentally terminated as "another" session (it is offered as "this device").
- Session history is retained per policy for auditing and then purged; purging is automatic and logged.
- Users can terminate their own sessions from their profile; this is a normal, non-alerting action.
- Admin termination of a user session always notifies the user and is audit-logged with the acting admin and reason.

### 5.2 "Remember Me" Option
**What it does:** Extends how long a session persists on a device when the user ticks "Remember me" at login. Instead of the session ending when the browser closes, a remembered session survives browser restarts for a policy-capped period, giving convenience on trusted personal devices while keeping a hard ceiling on how long the convenience lasts.

**Sub-features:**
- "Remember me" checkbox on the login screen
- Extended session validity for remembered devices (beyond the normal browser-session lifetime)
- Device recognition: remembered sessions are bound to the specific device/browser
- Policy cap on maximum remember-me duration (e.g., 30 days)
- Revocation triggers: password change, 2FA reset, admin termination, and policy expiry all end remembered sessions
- Visibility: remembered sessions appear in the active-sessions list marked as "remembered"
- Policy control: remember-me can be disabled entirely or for specific roles/devices (e.g., never offered to admin roles, or on shared devices)
- Audit logging of remembered-session creation and revocation

**Super Administrator User Journey:**
1. Super Admin opens System Settings → Security Policy → Session Policy → Remember Me and reviews the configuration: enabled for standard users, capped at 30 days, disabled for all admin roles.
2. Confirms the admin-role exclusion is intentional (privileged accounts should re-authenticate fully each time) and leaves it as is.
3. A standard user logs in on their personal laptop and ticks "Remember me". Their session now survives browser restarts for up to 30 days on that device.
4. The user later changes their password and ticks "sign out all other sessions". All their remembered sessions except the current one are revoked; the remembered-session entries disappear from their active-sessions list.
5. Super Admin, reviewing that user's account after a reported anomaly, opens the active-sessions view and sees which sessions were remembered, on which devices, and their remaining validity.
6. Super Admin terminates a remembered session that looks unrecognized; the user is notified, and the revocation is audit-logged.
7. At the 30-day cap, any still-valid remembered sessions expire automatically; the user must log in again (and can tick "Remember me" again for a fresh window).
8. Super Admin reviews the remember-me audit entries to confirm creations and revocations are recorded with timestamps and triggers.

**Rules & Edge Cases:**
- Remember-me duration is hard-capped by policy; a user cannot extend it beyond the cap by repeatedly ticking the box.
- Password change, 2FA reset, or admin termination always revokes remembered sessions for the account (except the session in which the change was made, if the user chose to keep it).
- Remember-me is device-bound: it does not carry to a different browser or device.
- Where policy disables remember-me for a role or device class, the checkbox is not shown at all (not merely ignored).
- Remembered sessions are subject to the same idle and absolute timeouts as any session; "remembered" extends persistence across browser restarts, not activity-based expiry.
- Creation and revocation of remembered sessions are audit-logged.

### 5.3 Session Expiry and Timeout
**What it does:** Automatically ends sessions to protect unattended access: an idle timeout ends a session after a configurable period with no activity, and an absolute timeout ends it after a maximum lifetime regardless of activity. Timeouts can be set per role (stricter for privileged roles), and expiry is handled gracefully so the user understands what happened and can resume.

**Sub-features:**
- Idle timeout: session ends after a configurable period of inactivity (e.g., 30 minutes)
- Absolute timeout: session ends after a maximum lifetime (e.g., 12 hours) regardless of activity
- Role-specific timeouts (e.g., 15-minute idle for admin roles, 30-minute for standard users)
- Graceful expiry: on the next action after expiry, the user is redirected to login with a "session expired" notice
- Unsaved-work warning: where the current screen has unsaved input, the user is warned before the redirect
- Re-authentication resumes the user at their panel (deep-link resume where safe)
- Configurable timeout values in System Settings with role overrides
- Expiry event logging, including per-user expiry frequency

**Super Administrator User Journey:**
1. Super Admin opens System Settings → Security Policy → Session Policy → Timeouts.
2. Reviews the current values: 30-minute idle and 12-hour absolute for standard users; 15-minute idle and 8-hour absolute for admin roles.
3. After an incident where an admin session was left unattended on a shared office computer, Super Admin tightens the admin-role idle timeout to 10 minutes and saves.
4. The new values apply to sessions started after the change; existing sessions continue under their original timeout until they end.
5. During normal use, Super Admin steps away for 15 minutes. On returning and clicking a menu, the screen redirects to login with "Your session expired due to inactivity. Please sign in again."
6. Because Super Admin was editing a form with unsaved input, the expiry notice includes a warning that unsaved changes were not saved.
7. Super Admin re-authenticates (password + 2FA) and is returned to their panel; the form is empty and must be re-entered.
8. Super Admin reviews the expiry-event log: the user's expiry frequency is normal, and the admin-role sessions show the tighter timeout in effect.

**Rules & Edge Cases:**
- Timeouts are evaluated server-side: a stale session cannot perform any action even if the client window is still open.
- In-progress critical actions (e.g., a payment being processed, a form submission in flight) are protected from mid-action expiry; the timeout applies between actions.
- The absolute timeout ends sessions even for continuously active users, forcing periodic re-authentication.
- Role overrides apply the stricter value where both a platform default and a role override exist.
- Expiry events are logged; a pattern of frequent unexpected expiries for one user is visible in their session history and can indicate clock or connectivity issues.
- Policy changes apply to new sessions; they do not forcibly end already-active sessions (except where an admin explicitly terminates them).

### 5.4 Concurrent Session Control
**What it does:** Limits how many sessions a user may have active at the same time, and from how many devices, with configurable limits per role and a defined behavior for what happens when the limit is exceeded. This bounds the blast radius of a compromised credential and gives the Super Admin a lever for privileged roles.

**Sub-features:**
- Maximum concurrent sessions per user (configurable, e.g., 5)
- Stricter maximum for admin/privileged roles (e.g., 2)
- Overflow behavior choice: block the new login, or end the oldest session ("newest wins")
- Per-role concurrency policies
- Notification to the user when one of their sessions is ended due to overflow ("You were signed out on [device] because you reached your session limit")
- Visibility of all concurrent sessions to the owner and to admin (see 5.1)
- Audit logging of concurrency-limit events

**Super Administrator User Journey:**
1. Super Admin opens System Settings → Security Policy → Session Policy → Concurrent Sessions.
2. Reviews the current limits: 5 concurrent sessions for standard users, 2 for admin roles; overflow behavior "end the oldest session".
3. Confirms the admin-role limit of 2 is appropriate (admins typically use one workstation and one mobile device) and saves.
4. A standard user logs in from a sixth device. The system ends their oldest session automatically and shows the new device the notice "You were signed out on [older device] because you reached your session limit."
5. The older device, on its next action, is redirected to login with the same explanation.
6. The user is confused and contacts support. Super Admin opens the user's active-sessions view, shows them the five current sessions with devices and locations, and confirms the overflow behavior worked as configured.
7. For a privileged role where even "newest wins" is too permissive, Super Admin changes the overflow behavior to "block the new login" for that role: the sixth login attempt is refused with "Session limit reached. Sign out on another device first."
8. Super Admin reviews the concurrency-event log to confirm each overflow action is recorded with user, device ended, and timestamp.

**Rules & Edge Cases:**
- Admin/privileged roles always have a concurrency cap at least as strict as the platform default; they cannot be configured more permissive than standard users.
- Ending a session due to overflow notifies the user's primary channel so the sign-out is not silent.
- The count includes all active sessions across web and mobile app; a session and its app counterpart are counted separately.
- Expired and terminated sessions do not count toward the limit; only live sessions do.
- Concurrency-limit events (session ended, login blocked) are audit-logged.
- Changing the limit applies to new session-creation decisions; it does not retroactively end sessions that are currently within the old (higher) limit until they next exceed the new one.

### 5.5 Logout, Including Forced Logout of User Sessions by Admin
**What it does:** Provides the normal logout mechanisms for users (single-device logout and "log out of all devices") and a forced-logout capability for the Super Admin to terminate any user's session immediately — a specific session or all of them — as a security response. Forced logout is the primary immediate-mitigation tool when an account is suspected compromised.

**Sub-features:**
- Standard logout from any page (profile menu)
- "Log out of all devices" from profile settings (ends every session for the user)
- Admin forced logout: terminate a specific session or all sessions of any user
- Immediate invalidation: terminated sessions fail on their next request
- User notification when an admin terminates their session(s), with a security-reason message
- Optional companion actions from the same screen: trigger password reset, suspend account
- Audit logging of all logout events (self-initiated and forced) with actor and reason for forced

**Super Administrator User Journey:**
1. Super Admin receives a critical alert: repeated successful logins from an unfamiliar location for a user, followed by bulk data access. Super Admin opens the security monitoring dashboard and drills into the account.
2. Confirms the pattern indicates compromise. Super Admin opens the user's record in the user directory and views all active sessions (two: the usual phone and the suspicious browser).
3. Selects "Force logout all sessions" for the user. A confirmation dialog explains the effect: every active session for this user will end immediately, and the user will be notified.
4. Super Admin enters the reason ("Suspected compromise — unauthorized location logins") and confirms. The system immediately invalidates every active session for that user.
5. The suspicious browser, on its next request, is cut off and redirected to login; the user's phone is likewise signed out.
6. The user is notified: "Your sessions were signed out by an administrator for security reasons. Please sign in again and change your password if this wasn't expected."
7. From the same screen, Super Admin triggers a password reset for the account (so the attacker's access is fully revoked) and reviews whether to suspend the account pending user contact.
8. The user re-authenticates with 2FA, changes their password, and confirms with support that the incident is resolved. Super Admin records the outcome in the audit trail; the forced logout, reset, and resolution all appear in the security monitoring dashboard and audit log.

**Rules & Edge Cases:**
- Forced logout takes effect on the terminated session's next request (immediate for actively used pages).
- Forced logout does not change the password; where compromise is suspected, a password reset should be triggered as a companion action (offered on the same screen).
- All forced logouts require the admin to confirm and to record a reason (preset or free-text); they are audit-logged with the acting admin, target, and reason.
- The user is always notified of an admin-initiated termination so it is not silent and can be reported if unexpected.
- "Log out of all devices" (self-initiated) and admin force-logout-all have the same effect on sessions but are logged with different actors (the user vs. the admin).
- Logout events (all types) are retained in the login activity log for auditing.