Running the assistant for everyone

This mini-book is for Level 5 Operator. The assistant is now a shared service. Work can stop when identity, capacity, routing, or recovery fails, and the service must remain operable after its original builder leaves.

2. Two people left, but their access did not

Sixty people use the shared assistant. This month two colleagues left, usage for one group tripled, and nobody can explain whether old browser sessions still work. The identity provider says both leavers are disabled, while the assistant still contains local accounts created during the pilot. A shared API key appears in a reporting script. Logs contain enough prompt text to create a privacy problem but not enough structured metadata to attribute cost.

This is a Level 5 blast radius. One mistaken group rule can expose an administration function or costly model to the whole organisation. One missing revocation connection can preserve access after employment ends. One unbounded automation can exhaust shared capacity and stop every team's work. One over-broad logging setting can copy sensitive content into a second system. The operator must therefore prove effective controls at every boundary, not merely show that configuration exists.

The service is running, yet you cannot answer four basic questions:

• Which single action ends a person's access?
• Which machine or local paths sit outside that human control?
• Which role, model policy, and quota does each group actually receive?
• Which retained events prove access and usage without retaining unnecessary content?

The answer is one reproducible access audit: configuration fields, bounded tests, observed results, one corrected finding, and a retest another operator can follow.

3. After this you can

• Configure provider-neutral SSO using an exact callback URI, trusted claims, and deny-by-default assignment.
• Demonstrate one-action human revocation against both an active session and a new login.
• Inventory local, emergency, support, and machine access separately from human SSO.
• Assign roles, model access, and quotas by group rather than individual exceptions.
• Observe quota, overload, attribution, and logging behaviour with synthetic requests.
• Complete one access-audit artifact with a finding, fix, owner, date, and retest.

4. Prerequisites

• T02-L04 · A self-hosted assistant.
• T12-L05 · Operate governance.
• Administrator access to an approved non-production identity provider, assistant, and model gateway.
• Two synthetic human users and one synthetic service identity.
• Permission to test identity disablement, session invalidation, group changes, quotas, and log deletion.
• A recovery account or approved break-glass procedure that cannot become routine login.
• A second operator who can perform the final runbook check.

Use only synthetic prompts and identifiers. Do not disable a real colleague, alter production groups, run an unbounded load test, paste secrets into the audit, or use customer data during this exercise.

5. The idea in one page

One action for people

Human access starts at one identity provider. Choose one authoritative offboarding action, such as changing the person's IdP status from enabled to disabled. That one operator action must trigger or be honoured by every human SSO dependency: application assignment, group delivery, user provisioning, and active-session revocation. Do not make the operator remove three groups, disable an assistant account, and clear a session manually. That is three opportunities to miss a path, not one-action revocation.

The acceptance test is behavioural. After the single IdP action, the synthetic leaver must be unable to complete a fresh login or use an already authenticated browser to obtain a new protected response. An old page still visible in a browser cache is not access; a successful new response from a protected route is. If an active application session remains valid, the test fails. Configure a supported session-revocation or revalidation mechanism and retest. Merely reducing token lifetime limits exposure but does not prove immediate revocation.

Group membership maps approved people to assistant and gateway policy:

assistant-users     -> ordinary assistant role -> standard model policy and quota
assistant-editors   -> content editor role     -> approved publishing capability
assistant-operators -> restricted admin role   -> operational functions only

Permissions may be additive. Membership in a broad group can restore a capability removed elsewhere. Always test effective access as a synthetic user.

Separate paths stay separate

An IdP action cannot revoke a local assistant password, a gateway API key, an emergency account, or a vendor support identity unless a documented automation explicitly connects them. Inventory these paths after the human test in a separate part of the same audit. Give every path an owner, purpose, scope, expiry or review date, storage location, and independent revocation control.

Do not disguise machines as people. A reporting job needs a scoped machine credential, not a colleague's browser session. Do not claim that central human revocation covers a credential merely because its owner also has an IdP account.

SSO migration has a closure gate: after SSO is proven, disable routine local password authentication, not only the local accounts you happen to find. Disable self-registration and local password recovery, invalidate existing local sessions, and verify that both the local login route and a new protected request fail. An enabled local password mechanism leaves one-action revocation unproved because a forgotten account can bypass the IdP.

The only permitted human exception is a documented break-glass path for identity-service recovery. It must not be a named person's everyday account. Give it the minimum recovery role, separate protected credentials, named custodians, approval for use, an alert on every attempt, and a test schedule. Keep it disabled between drills if it can be enabled independently; otherwise make it unavailable for routine use through sealed credentials and restricted administration routes. After use, end its sessions, rotate or reseal its credential, restore its controlled state, and review the event. Convenience, support, and automation are not break-glass reasons.

Callback means the complete URI

An OAuth or OpenID Connect callback registration is not the assistant's origin. It is the exact redirect URI sent by the assistant, including scheme, host, optional port, provider or adapter callback path, case, and trailing-slash behaviour. For a generic OIDC adapter, a deployment might advertise:

https://assistant.lab.example.invalid/oauth/oidc/callback

Register the exact redirect_uri observed in the running application's authorization request or specified by the deployed release's current documentation. Do not shorten it to https://assistant.lab.example.invalid. Do not infer a callback path from a different provider adapter. Exact matching prevents accidental redirection and makes a failed callback diagnosable.

Enforce where the decision is possible

The IdP authenticates people. The assistant applies application roles. The gateway can apply model, usage, concurrency, and routing policy when requests pass through it. The log platform retains selected events. Record the component that actually makes each decision. A quota shown in an administration page but not observed at the request boundary is not evidence of enforcement.

For a thirty-person burst, define per-group concurrency, queue length, maximum wait, caller-visible overload result, operator alert, and recovery action. Detailed load engineering belongs to T11-L05; this book checks that identity and group boundaries survive demand.

Log enough to operate the service, not everything forever. A useful request event contains a trace ID, privacy-preserving principal or group identifier, route or model alias, policy revision, authorization result, status category, latency, usage units, and retention class. Raw prompts, responses, retrieved documents, credentials, cookies, and authorization headers are not default operational metadata.

6. The worked example: parallel Lab and Company tracks

The two tracks below are operationally parallel. The Lab track represents an institute-run environment; the Company track represents an enterprise-run environment. Choose one track for the 90-minute exercise, or use both to compare implementations. Neither track depends on a named identity vendor or an invented administration screen.

Use these synthetic identities:

Create one document named for the exercise, such as T02-L05 access audit - 2026-09-04. All configuration snapshots, observations, inventories, and the corrected finding below are sections of this one artifact. Do not create a separate SSO report, quota report, or log report.

Configure SSO reproducibly

Resolve each field from the running assistant, the approved IdP application, and current product documentation. Secret values belong in an approved secret store; the artifact records only their references.

To validate the exact callback, start a synthetic login, inspect the authorization request without storing its token or state value, and record only the redirect_uri. Compare that complete value with the IdP application's registered callback. A matching origin with a missing or different path is a failure. Complete the login and correlate the assistant authentication event with the IdP event by timestamp and synthetic subject.

Selected Company implementation: Microsoft Entra ID

For a Company-track implementation, select Microsoft Entra ID and create a single-tenant web application registration and enterprise application. Use https://login.microsoftonline.com/{tenant-id}/v2.0 and its discovery document. In App registrations > Authentication, register the assistant's exact HTTPS callback. Require enterprise-application assignment and assign only approved Company groups. Map an immutable Entra object identifier accepted by the adapter, not display name or email.

Choose Block sign-in as the authoritative operator action. Connect that change to supported application deprovisioning and active-session invalidation or protected-request revalidation. Automation may propagate the action, but the operator performs no follow-up purge. Entra revocation alone is insufficient if the assistant still honours its own cookie. Record application and enterprise-application IDs, issuer, callback, group IDs, lifecycle connection, and session-control method without secrets or tokens. Then run the provider-neutral tests below; Microsoft screens do not replace behavioural evidence.

Record observable results rather than writing “configured”:

If a check fails, record the actual status category and trace or event ID. Do not paste an authorization code, token, cookie, or secret into the artifact.

Map groups to effective policy

Configure both tracks with equivalent outcomes, even if their IdPs represent groups differently.

For the selected track, add Alex to only the user group. Complete a fresh login and record the displayed role only as supporting evidence. Then test effective behaviour: request an allowed synthetic model, request one model outside standard-models, open a protected administration route, and attempt the approved harmless equivalent of a shared-content change. The pass result is one allowed standard request and denials for the other three actions. Record status categories and trace IDs.

Next add a second, deliberately conflicting synthetic group only if the test environment safely permits it. Re-evaluate Alex's effective role and model list. If additive policy grants an unintended capability, remove the conflict, document the precedence rule, and retest. Never experiment with production groups.

Demonstrate one-action human revocation

This test comes before the inventory of machine and local paths so that its result cannot be blurred by unrelated credentials. Its stated precondition is that routine local human password authentication has already been disabled after the SSO migration; the later inventory verifies that precondition independently. Break-glass access is not issued to Sam and cannot be used as an alternate personal login.

1. Sign in as Sam through SSO in a separate browser profile and obtain one successful response from a protected assistant route. Record its trace ID and time.
2. Keep that browser session open. Also prepare a clean private browser with no assistant cookie.
3. Perform exactly one control action: change Sam's authoritative IdP account status from enabled to disabled. Do not also remove Sam's groups, disable an assistant record, revoke an API key, or clear a server-side session manually.
4. Wait only for the documented propagation objective. Record the actual elapsed time.
5. In the existing browser, request a new protected resource that cannot be satisfied from a cached page.
6. In the clean browser, start a new SSO login.
7. Inspect IdP, assistant, and session-control events using the synthetic subject and timestamps.

The sample below shows the required form, not a claim about your environment:

The human test passes only if both access attempts are denied after the single IdP action. If the fresh login is denied but the active session succeeds, mark the test failed. Identify the missing supported lifecycle or session-control connection, configure it through the approved change process, reset the synthetic test, and repeat the same one action. Do not turn a manual session purge into an undocumented second offboarding step.

Inventory machine, local, emergency, and support paths separately

Only after recording the human result, add this separate inventory section to the same access-audit artifact. Search the assistant account store, gateway credential store, secret manager metadata, approved automation repository, scheduled jobs, deployment configuration, and support-access register. Search metadata and references; do not copy secret values.

These rows are examples to replace with observed synthetic inventory. The IdP disablement result does not prove any row here is revoked. Test each row using its own control, record the result, and restore only approved test access.

For local authentication, the required outcome is stronger than closing Sam's account: every routine local human password account is disabled, creation and recovery of such accounts are unavailable, and existing local sessions no longer obtain protected responses. Add a local-auth closure subsection to the artifact with configuration evidence, account-store search scope, enabled routine-account count (required: zero), local-route result, protected-request result, and event IDs. List the break-glass identity separately with its recovery scope, custodians, authorization rule, credential location reference, source restrictions, alert result, test date, and return-to-controlled-state evidence. If any routine local password path works, the SSO migration and one-action revocation check fail.

Configure quotas and overload behaviour

Use small, safe non-production values that can be reached with bounded synthetic requests. Enforce them at the gateway or other component through which all tested model requests pass.

Send exactly the requests needed to cross each test boundary, using a prompt such as Return the word TEST. Stop when the expected denial or delay is observed. Record request count, timestamps, trace IDs, usage units, latency, policy revision, and result. If the fourth request is accepted, the quota test fails even if configuration displays a limit. Check that the attribution key reaches the enforcement component and that every relevant route uses it.

Use a synthetic rate to demonstrate cost attribution without implying an invoice:

Trace ID: demo-0042
Group: standard-test
Feature: shared chat
Environment: non-production
Route: assistant-default
Input/output usage: value reported by enforcement component
Rate source: synthetic exercise rate
Outcome: accepted test request

Do not claim that the assistant itself enforces gateway budgets. Name and test the exact enforcement component. If that component requires a persistence dependency for counters, record the dependency and prove that a restart does not silently reset the tested policy, or record the reset risk as the audit finding.

Configure logging and retention

Record this field table before testing. Values are provider-neutral policy decisions, not defaults attributed to a product.

Generate one event of each applicable class with the synthetic identities. Search by event ID, trace ID, and time range. Confirm the expected event is present, the result matches the user-visible outcome, and prohibited fields are absent. A blank prompt field is weaker evidence than a schema or pipeline that never sends prompt content, so record where exclusion occurs.

Run a safe deletion test on an isolated synthetic event or accelerated test retention class. Record the deletion request or scheduled-job ID, completion time, and a follow-up search returning no event. If policy or tooling prevents an immediate deletion test, record the exact scheduled control, its owner, and the date evidence will be reviewed; do not mark deletion as observed.

Correct one finding inside the audit

Select one finding from the test environment. A common example is Sam's obsolete local pilot account:

Finding: Local account remains after central human offboarding.
Risk: A second human login path bypasses the one-action SSO control.
Blast radius: Level 5 shared service; unauthorised access could reach shared models and data.
Fix: Disable every routine local human password account, routine local login/registration/recovery, and existing local sessions. Preserve only the separately controlled break-glass path.
Owner: Synthetic Service Operator
Checked: 2026-09-04
Retest: Enabled routine local-account count is zero; fresh local login and password recovery are denied; old local session gets no new protected response; break-glass drill alerts and returns to its controlled state.
Evidence: Redacted event IDs and timestamps in this access-audit artifact.

Do not choose a finding merely because it is easy to close. Prefer the issue with the clearest access, privacy, capacity, or recovery consequence that can be corrected safely during the exercise. The fix is complete only after an observed retest.

7. What goes wrong

The callback registration contains only the origin

Symptom: the IdP rejects the redirect, or an operator registers several broad redirect patterns to make login work.

Fix: capture the complete redirect_uri emitted for that adapter and register its exact HTTPS scheme, host, port if present, and callback path. Remove unused callbacks after testing.

“One action” is actually a checklist of manual actions

Symptom: offboarding requires disabling the IdP user, removing groups, deleting an assistant account, and clearing sessions by hand.

Fix: make one authoritative IdP status change drive or be honoured by human access controls. Test active and fresh access after only that action. Track unsupported paths explicitly rather than hiding them in the checklist.

Routine local passwords survive the SSO migration

Symptom: known pilot users were disabled, but the local login route, registration, recovery, or another forgotten local user still works.

Fix: disable the routine local password mechanism and all routine local human accounts, invalidate their sessions, and test route, recovery, and protected-request denial. Retain only a separately inventoried, alerted, narrowly scoped break-glass path.

A machine credential is mistaken for human SSO

Symptom: Sam is disabled, but a script credential created or shared by Sam still works.

Fix: inventory machine credentials separately with owner, scope, storage reference, expiry, and gateway-side revocation test.

Groups silently add permissions

Symptom: a user retains model or administrative access through a second group.

Fix: test effective actions with a synthetic account, document precedence, remove conflicting membership, and retest.

A displayed quota is not enforced

Symptom: requests continue beyond the configured limit or another group is limited too.

Fix: verify the attribution key, route coverage, counter persistence, and enforcement component with bounded crossing and isolation tests.

Everything is logged forever

Symptom: prompts and documents accumulate without a defined reader, purpose, or deletion date.

Fix: send bounded operational metadata, exclude content and secrets at collection, name a retention owner, and observe deletion on synthetic events.

Capacity failure bypasses policy

Symptom: overload sends traffic through an unrestricted fallback or returns ambiguous failures that trigger uncontrolled retries.

Fix: test concurrency, queue, timeout, fallback, and caller-visible terminal behaviour while preserving the same group policy.

The original operator is the recovery plan

Symptom: no substitute can locate the revocation control, interpret events, or restore bounded service.

Fix: have a second operator use only the artifact to identify and execute the approved synthetic controls.

8. Do it yourself: one access audit in 90 minutes

Produce one artifact throughout. The times are boundaries, not suggestions to create separate reports.

Minutes 0-12: choose Lab or Company, create the one access-audit artifact, record owners and environment, and complete the SSO field table. Capture the exact callback URI without tokens or secrets.

Minutes 12-25: validate callback, issuer, unassigned-user denial, and secret handling. Add Alex to the selected user group and test allowed and denied effective actions.

Minutes 25-40: prepare Sam's active and clean-browser sessions. Perform the single IdP disablement action, test a new protected response and fresh login, and record elapsed propagation plus event IDs. If either path succeeds, record failure before correcting and repeating.

Minutes 40-53: separately inventory machine, local, break-glass, and support paths. Prove that routine local password accounts and authentication are disabled, then test each remaining independent synthetic revocation control without exposing credentials.

Minutes 53-67: apply the small group quota, cross the request and concurrency boundaries, check group isolation, and record caller-visible results, attribution, and alert receipt.

Minutes 67-77: generate bounded authentication, access-change, gateway, quota, and emergency events. Verify required fields, content exclusions, readers, retention, and synthetic deletion evidence.

Minutes 77-85: choose one finding, assign its owner, apply the safe fix, and rerun the exact failed check. Include Level 5 blast-radius reasoning.

Minutes 85-90: remove temporary synthetic access, return emergency access to its controlled state, date the artifact, and ask the second operator to locate the next review date and explain every revocation control.

Stop rather than rush if a step could affect production or real identities. An honestly recorded failed test is better operational evidence than an unsafe or fabricated pass.

9. Exit check

Deliver exactly one artifact: one written access audit containing the selected track's SSO and exact callback fields; group-to-effective-policy mapping; one-action human revocation observations; proof that routine local password accounts and authentication are disabled; the separate machine, break-glass, and support inventory; quota and overload results; logging and deletion results; and one finding with risk, Level 5 blast radius, fix, owner, checked date, and observed retest.

It passes when:

• One IdP disablement action denies Sam both a new protected response in the existing session and a fresh login.
• No manual second action is represented as part of human revocation.
• The enabled routine local human-account count is zero; local login, registration or recovery, and an old local session cannot produce a new protected response.
• Any break-glass path is narrowly scoped, separately protected and approved, alerts on use, and is shown returned to its disabled or otherwise unavailable controlled state after the drill.
• Every non-SSO path has its own owner and tested revocation control.
• Alex's allowed and denied effective actions match the selected Lab or Company field table.
• A bounded request crosses the configured quota and concurrency boundaries while another group remains unaffected.
• Authentication, access-change, usage, quota, and emergency events contain required metadata but no secret or unapproved content.
• The retention or deletion result is observed or honestly marked pending with an owner and review date.
• The corrected finding passes its retest.
• A second operator can use the artifact without asking the original builder.

10. Rule to remember

Use one action to revoke a person; name and test every path that action cannot reach.

11. Further reading & tools

• Taught: Open WebUI SSO (opens in a new tab) - current authentication and provider callback guidance.
• Taught: Open WebUI SCIM (opens in a new tab) - current user and group lifecycle guidance.
• Taught: Open WebUI permissions (opens in a new tab) - current effective-role guidance.
• Taught: Open WebUI hardening (opens in a new tab) - session and audit-log considerations.
• Taught: Microsoft identity platform OpenID Connect (opens in a new tab) - selected Company implementation reference for tenant-specific discovery, exact redirect URIs, and application session handling.
• Taught: Microsoft Entra emergency access accounts (opens in a new tab) - selected-provider controls for restricted, monitored break-glass access.
• Catalogued: OpenID Connect Core (opens in a new tab) - protocol roles, claims, and redirect processing.
• Catalogued: OAuth 2.0 Security Best Current Practice (opens in a new tab) - current redirect URI and client security recommendations.
• Catalogued: LiteLLM virtual keys (opens in a new tab) - gateway-side users, teams, and limits.
• Catalogued: LiteLLM routing (opens in a new tab) - routing and overload controls.
• Taught: T11-L05 · Serve models for real use - detailed capacity and concurrency engineering.
• Catalogued: Tools index - current identity, gateway, and assistant alternatives.