UX Spec: Session Attributes for Zero Trust ABAC (MVF v1.0)
Links
Resource | Link |
|---|---|
Tech Spec (Source of Truth) | |
PRFAQ v1.2 | |
Figma file | |
Parent Spec | ABAC Permission Policies (shipped) |
1. Overview
1.1 Problem Statement
Mattermost's ABAC engine cannot distinguish between a user on a hardened government workstation and the same user on a compromised personal device. This violates per-session verification mandates (NIST 800-207 Tenet 3, DoD ZT Strategy FY2027 Target Level), blocks adoption for DoD and regulated financial customers, and allows non-compliant devices to access sensitive data with full privileges.
1.2 Feature Summary
Session Attributes extends the existing ABAC engine with session-aware, device-and-network-context signals. Each active session (user + device pairing) maintains its own attribute set — the same user on two devices gets independently evaluated access decisions.
The MVF uses a client-native collection model (Desktop and Mobile) plus carry-forward server-native attributes derived from request metadata (User-Agent, IP). Mattermost clients report session signals (network identity, device identity, device posture) directly to the server via the X-MM-Session-Attributes request header. No external MDM, NAC, or connector infrastructure is required for the MVF.
No certificate / PKI attributes in V1. Per the tech spec schema, V1 ships without cert-derived attributes. The trust model relies on mdm_enrolled + device_id + hardware_id as client-asserted device-identity signals. This is a deliberate deviation from PRFAQ v1.2 §6 Mechanism A and carries three security implications — see §10.1.
Attribute refresh: Per-attribute TTL + grace period, defaults 30 s / 60 s. Admin-tunable on the listing page row menu. Three refresh triggers (manifest fetch at session establishment, material change, per-attribute TTL).
Launch use case (marketing-only): Preventing file downloads on mobile devices for defense platform deployments. This spec is platform-agnostic.
1.3 User Roles
Role | Relevant Actions |
|---|---|
System Admin | View + edit session attribute definitions (Enable/Disable, TTL, Grace), author policies with session attribute conditions, test policies (User Lookup + Manual Simulation), view a user's active sessions and revoke them. Configure |
Channel Admin | Author channel-level policies with session attribute conditions; test policies (Manual Simulation only) — values populated from users they share channel membership with. Cannot edit attribute definitions, configure settings, view active sessions, or revoke. |
End User | Experiences per-session access enforcement through the existing denial UX (not covered by this spec — already implemented). |
Security/Compliance Officer | Reviews audit log entries for access decisions when the access-control team's separate audit workstream lands. |
IT/Help Desk | Revokes sessions via the User Sessions modal (System Admin access). |
1.4 Scope
In Scope (MVF v1.0):
Client-native attribute collection from Desktop (Windows, macOS) and Mobile (iOS, Android) clients
Server-native attribute carry-forward from v0.1 (
user_agent_*,ip_address)Schema — 13 client-native + 5 server-native = 18 attributes (see Attribute Reference below)
Session architecture — per-session attribute storage, per-session ABAC evaluation
Manifest-based refresh with three triggers (session establishment + material change + per-attribute TTL)
Editable Listing page — Status, TTL, Grace tunable per attribute via row context menu (Platforms shown but not tunable in V1)
Session Attribute Settings page —
EnforceDeviceIDConsistencytogglePolicy editor extension (Simple + CEL modes) with soft platform coverage warnings
Policy test/preview side panel (User Lookup for System Admin, Manual Simulation for both)
User Sessions modal — System Admin can list a user's active sessions and revoke individually or all at once
Enterprise Advanced tier only, feature-flag-gated (
SessionAttributes)
Out of Scope:
End-user denial UX (suppression, toasts, infrastructure denial messaging) — already implemented in the product
Forced re-auth modals (session-limit eviction, device-ID drift) — the existing platform sign-in / re-auth UX handles user-facing response when a session is revoked or fails validation
Concurrent session limit — PRFAQ v1.2 Req 20 is not in the tech spec; no V1 UI
PKI / certificate attributes (see §10.1)
Per-decision ABAC audit logging (owned by access-control team's separate workstream)
Custom attribute definitions ("Add Attribute") — deferred until connector framework
Visual trust-level distinction on listing page and policy editor (deviation from PRFAQ Req 12)
Per-attribute details surface (read-only side panel showing CEL ref, source, trust assurance, full per-platform detail) — deferred; row tooltips + on-row metadata cover the core needs in V1
Admin-tunable supported platforms — the per-attribute Platforms field is server-controlled by the manifest schema and engineering reality; admins cannot toggle Desktop/Mobile/Browser availability in V1
External attribute connector / plugin framework — planned for a future release, not committed
GPS-based geolocation; External PDP support; Native MDM agent, device wipe, remote lock, self-healing
AVD container detection (
session.avd_containernamespace reserved for future)FQDN-based auto-enrollment to teams — lives in Team Membership Policies spec
2. Terminology
Term | Definition |
|---|---|
Session | The unique pairing of a user and a specific device/connection. Each session maintains its own session attribute set, evaluated independently by the ABAC engine. |
Session Attribute | A key/value pair scoped to a specific authenticated session, evaluated as |
Server-native attribute | A session attribute derived server-side from request metadata (e.g., IP, User-Agent). No client cooperation required. Carries |
Client-native attribute | A session attribute collected by the Mattermost client (Desktop, Mobile) and reported via the |
Attribute Manifest | The platform-filtered, per-session JSON document listing the attributes the client should collect, including TTL and grace period for each. |
| Request header carrying base64-encoded JSON |
TTL | Time-to-live in seconds. Per-attribute, admin-tunable. Default 30 s. |
Grace Period | Window in seconds after TTL elapses during which a cached value is still usable while a refresh arrives. Per-attribute, admin-tunable. Default 60 s. |
Material change | A client-detected event that invalidates the current attribute set (network interface change, VPN connect/disconnect). Triggers immediate re-report. |
Fail-Secure | When attributes are missing, unavailable, or stale beyond TTL + grace, access is denied for any policy that references the missing attribute. |
Device-ID drift | Client-reported |
Revoke session | Admin terminates a specific active session for a user. The user on that device is signed out at their next interaction through the existing platform sign-in flow. |
3. Admin / Configuration UX
3.1 Session Attributes Listing Page
Location: System Console > System Attributes > Session Attributes
Displays the pre-configured set of session attribute definitions, not live per-session values. Built-in attributes from the tech spec (Reqs 5–7) are seeded at install; the page is never empty. There is no "Add Attribute" in V1 — the schema is fixed. Each attribute is Protected=true, meaning it cannot be deleted; admin can tune its Attrs (Enabled, TTL, Grace) via the row menu. The Platforms field is server-controlled and not admin-tunable in V1.
Structure: Collapsible header card with intro ("Configure session attributes — Enterprise") and a flat table below using the ConsolePanel + SimpleTable pattern.
Column | Content |
|---|---|
Display Name | Human-readable name (semibold) |
Name | Canonical snake_case identifier matching the CEL suffix |
Type | String / IP / Boolean / Version / Enum, with leading icon |
Platform | Three icons — Desktop / Mobile / Browser — colored when the attribute is collectible on that platform, dimmed when not. Read-only in V1. |
TTL | Per-attribute value in seconds (e.g., |
Grace | Per-attribute value in seconds (e.g., |
Status | Enabled / Disabled chip |
Actions | Row kebab menu |
Source distinction: Server-native attributes (ip_address, user_agent_*) carry an inline Server label next to the Name; client-native is the default.
Per-row context menu (three items, all editing happens inline — no separate modals for TTL/Grace):
Time-to-live (TTL) — opens a preset submenu (§3.1.1). The current TTL value is shown to the right of the label in the parent menu item (e.g.,
Time-to-live (TTL) 30s ▸).Grace Period — opens a preset submenu (§3.1.2). The current Grace value is shown to the right of the label (e.g.,
Grace Period 1m ▸).Disable (destructive, red) — opens the Disable confirmation modal (§3.1.3). When the attribute is already disabled, this item reads Enable (non-destructive) and toggles without a confirmation.
Disabling an attribute removes it from manifests; policies that reference it fail-secure.
3.1.3 Disable confirmation modal
Triggered when admin clicks the destructive Disable menu item.
Field | Copy |
|---|---|
Title | Disable attribute |
Body | Disabling this attribute will make it unusable in permission policies based on attributes. Are you sure you want to disable the attribute? |
Primary | Disable (destructive, red) |
Secondary | Cancel |
Confirming sets the row's Status to Disabled (pending Save) and removes the attribute from active manifests on commit. Existing policies that reference the attribute continue to evaluate fail-secure for any session that hits a condition on the disabled attribute. Re-enabling does not require a confirmation modal; it's a one-click action from the row menu.
3.3 Policy Editor Extension
Location: System Console > System Attributes > Attribute-based access > [Policy Editor] (existing editor, extended)
Session attributes are added to the existing ABAC condition builder.
Attribute picker. The picker dropdown groups attributes by namespace with two section headers:
(no header) — user attributes (existing behavior)
SESSION ATTRIBUTES — new section, with platform-coverage icons inline next to each attribute
Simple Mode
Each session attribute condition row shows: attribute name + per-platform availability icons inline,.
Channel Admin access. Channel Admins see the same picker, scoped to channel-level policies. Cannot edit attribute definitions, configure settings, or view sessions.
3.5 User Sessions modal
Triggers:
System Console > Users > [User row] > Actions menu > Manage User Sessions — opens this modal scoped to the selected user
Per-row "Revoke session" action:
Invokes the existing session-revocation API for the targeted session ID
The user on that device is signed out at their next interaction via the existing platform sign-in flow (this spec does not define new user-facing UX for the revoke event)
Row is updated to a "Session revoked" state, then removed on next refresh of the modal
Audit log entry will record the admin actor, target user, target session ID, and revocation reason when the audit workstream lands
Session attributes are not shown in this modal. The purpose of the User Sessions view is identification and termination — distinguishing one device from another and ending the right one. Attribute payloads (VPN active, MDM enrollment, OS version, etc.) are intentionally omitted so the modal stays scannable and the operator's attention stays on the revoke decision.
4. Edge Cases
Scenario | Behavior |
|---|---|
Policy references attribute with partial platform coverage | Sessions from unsupported platforms fail-secure for that condition. Soft warning shown at policy save with a "Continue saving" option. |
User connects from pre-MVF client | Session has zero session attributes. All session attribute conditions fail-secure. User Sessions modal still lists the session (it's a real authenticated session); the existing platform diagnostic surfaces handle "no attribute coverage" messaging if needed. |
| Server revokes the session. User signed out via existing platform re-auth flow. |
| Silent overwrite of cached value. Existing session continues. |
Concurrent edit conflict on policy | "This policy has been modified by another administrator. Please reload and re-apply your changes." |
Browser client with limited signals | Client-native attributes are not collected on browsers in V1. Browser sessions carry only server-native attrs ( |
Admin revokes a session that's currently making a request | The in-flight request completes against the cached session state. The next request from that client returns 401; the existing platform sign-in flow handles re-auth. |
Admin attempts "Revoke All Sessions" by mistake | Confirmation modal required ("This will sign out every user across the workspace. Continue?"). Action is auditable. |
Admin disables an attribute referenced by a live policy | Disable confirmation modal explains the impact. On confirm, attribute is removed from manifests on next Save. Existing policy conditions on the attribute fail-secure thereafter. No automatic policy edit — admin reviews policy library separately. |
Server FQDN reported by client vs. proxy | Client reports its configured server URL. For high-assurance environments, reverse proxy header injection is the recommended path; spec documents this in the attribute reference tooltip. |
Refresh interval set to TTL=30 s on dense deployment | Submenu accepts the value. Spec recommendation (documented out-of-band): for deployments above 5,000 concurrent users, prefer TTL ≥ 60 s. Customer can set higher via the row submenu or via the property API. |
Stale attribute beyond TTL + grace | Session is treated as fail-secure for all subsequent policy evaluations until refresh succeeds. Existing platform denial UX handles user-facing surface. |
FQDN pattern with invalid syntax | Policy editor shows inline error: "Pattern not supported. Use |
Server process restart | In-memory cache is volatile. Cache rebuilds as clients re-report on next authenticated request. During the gap (typically <5 s at default 30 s TTL), policies referencing missing attributes fail-secure. |
macOS SSID collection requested | Not collectible in V1 (CoreWLAN Location Services entitlement deferred to v2.0). Schema |
iOS SSID — Location permission denied | Attribute reports as absent for that session. Policies referencing SSID fail-secure. No new user-facing prompt; existing platform handles permission negotiation. |
5. Roles and Permissions
Capability | System Admin | Channel Admin | End User |
|---|---|---|---|
View session attribute definitions (Listing page) | Yes | Yes (via policy editor picker) | No |
Edit attribute settings (Enable/Disable, TTL, Grace) | Yes | No | No |
Configure | Yes | No | No |
Add/delete attribute definitions, or toggle Platforms | No (V1 schema fixed; Platforms server-controlled) | No | No |
Author policies with session attribute conditions | Yes (system-wide) | Yes (channel-scoped) | No |
Policy Test — User Lookup (real session data) | Yes | No | No |
Policy Test — Manual Simulation, values from shared channels | Yes | Yes | No |
Open the User Sessions modal for any user | Yes | No | No |
Revoke an individual session | Yes | No | No |
Revoke all sessions (workspace-wide) | Yes (confirmation required) | No | No |
View audit log (session attribute entries) | (when audit workstream lands) | No | No |
Channel Admin Manual Simulation values are scoped to users they share channel membership with — aligned with the existing simulate-access privacy model. API authorization enforces this; UI suppression alone is insufficient.
6. Licensing and SKU
Property | Value |
|---|---|
Feature Available In | Enterprise Advanced only |
Feature Flag |
|
Behavior Below Tier | Session Attributes page shows the discovery state. Policy editor does not show session attribute category. Existing policies referencing session attributes evaluate as fail-secure. |
8. Open Questions
# | Question | Owner | Status |
|---|---|---|---|
VP-8 | PKI deferral acceptability. Three security gaps documented in §10.1. Decision needed before launch. | PM + Eng + Security | BLOCKING |
9. Future Considerations
Framing: V2 / connector framework is planned for a future release, no committed date. V1 must be self-sufficient.
# | Item | Deferred To | Rationale |
|---|---|---|---|
FC-1 | External attribute connector framework | Future release | MVF uses client-native + server-native only. Schema design preserves forward compatibility. |
FC-2 | Custom attribute definitions ("Add Attribute") | Future release | Without a connector framework there is no collection mechanism for custom attrs. |
FC-3 | Trust level visual hierarchy | Future release |