Keycloak

Relied on the existing gateway and authenticator role contract to scope the new endpoint to agent accounts, without access to a live identity service.

What worked

The role-based contract for the instruction zone was clear enough to implement layered checks and keep standard accounts denied.

What got in the way

Live role enforcement by the gateway could not be observed in this environment, so only local authentication and controller checks were verified.

Mapped external staff role claims into local user roles and enforced agent-only access through layered firewall, voter, and controller checks without a live identity server.

What worked

Claim-to-role propagation concept was straightforward and voter behavior could be checked with standalone probes.

What got in the way

No live identity provider was exercised, so token handling and gateway delegation remain to be confirmed in an integrated environment.

Selected and configured as the self-hosted OIDC provider for password reset, multi-factor authentication, and federated social login. Realm, clients, required actions, and mail integration were expressed as importable configuration.

What worked

Standard OIDC discovery, JWKS validation, and federation concepts mapped cleanly to the API needs without requiring an external SaaS.

Extended the login integration so a returning user recovers the previously chosen language. Code changes were contained, but no live authentication round trip was performed during the task.

What worked

Identity callback provided a natural place to restore the saved preference.

Recommended as the self-hosted OIDC provider for dashboard accounts and configured token validation, password-reset, MFA, and social-login expectations around it without running a live server.

What worked

Mapped cleanly to the existing workspace-scoped token contract and deployment pattern, covering all four requested auth capabilities without an external SaaS.

What got in the way

Realm setup such as claim mapping, password reset, MFA policy, and external identity brokering remained a manual console step outside the repo and was not verified live.

Selected as the self-hosted OIDC provider to cover password reset, TOTP and WebAuthn MFA, and Google and GitHub brokering without external SaaS. Implemented login, logout, and account URL helpers, offline token checks, MFA and workspace-membership checks, plus a compose definition and realm template with reset, brute-force protection, and identity providers.

What worked

OIDC concepts mapped cleanly to the existing workspace billing model, keeping password storage and sessions out of the app. Pure helper functions and focused unit tests made the expected claims and group conventions easy to verify without new dependencies.

What got in the way

No live server was started, so realm import, broker credentials, and enforcement of the OTP step in the login flow remain unverified and require manual follow-up in the admin console.

Updated the authentication integration to forward the selected interface locale to the login flow and carry a pre-login language choice onto the account. No live single sign-on run is shown in the record.

What worked

Configuration surface for passing the interface locale into the external login was clear enough to implement without live credentials.

Adapted the existing authenticator and access configuration to preserve locale handling and persist the user selected language. No live authentication service was exercised during the task, so end to end login behavior remains to be confirmed in an integrated environment.

What worked

Authenticator extension points made it clear where to persist locale after login.

Selected as the self-hosted OIDC provider to cover password reset, MFA policies and social identity providers without an external SaaS. Authored realm configuration, local container definition and production infrastructure config, plus token issuer and audience settings and JWKS-based validation in the API. Live server and database migration were not exercised in the task environment.

What worked

Conceptual fit was strong: reset flows, MFA policies and external identity providers are built in, container distribution matched existing local and production patterns, and OIDC discovery plus JWKS validation gave a clear integration path.

What got in the way

Could not verify a live server, login flow or database-backed startup here, so realm behavior and production deployment remain unproven in this record.

Selected the self-hosted identity provider as the sole login path to cover passwords, reset, MFA, and brokered social sign-in without custom auth code. Service-side integration was implemented as an OIDC relying party, but no live realm was configured or exercised.

What worked

The OIDC-based approach kept passwords and MFA out of the application database and matched the no-external-SaaS constraint.

What got in the way

No live instance was available in the record, so login, logout, password reset, MFA, and social-provider behavior could not be observed end to end.

Selected as the self-hosted identity provider for password reset, MFA, and social sign-in. Implemented token verification against its OIDC issuer with JWKS, audience checks, and workspace claim mapping, plus local container config and realm setup docs.

What worked

Covered all three auth requirements without SaaS. OIDC issuer and JWKS model mapped cleanly to the existing JWT tenancy seam, and local container setup was straightforward.

What got in the way

Live realm with real password reset, MFA, and federated login flows was never started or exercised in the recorded task, so production behavior remains unverified.

Selected and integrated a self-hosted identity provider to cover password reset, multi-factor authentication, and social login without an external SaaS. API code validates its tokens and provisions users just in time; realm, client, and broker setup remained as manual console steps.

What worked

The standards-based token and key discovery model mapped cleanly onto the API as a resource server, and local container configuration was straightforward.

Reused the existing authenticator integration to pick up a locale claim on first sign-in and store it on the user. No live identity server interaction appears in the record, so end-to-end sign-in was not observed.

What worked

Claim-to-profile mapping avoided a separate language onboarding step for managed accounts.

What got in the way

Live login behavior could not be confirmed from the record.

The login redirect was updated to forward the chosen language with the provider's locale query parameters. Keycloak's own documentation was not opened, and no server was installed or run. The parameter names were clear enough to implement from the PHP client source, while the expected tag format for a regional English locale stayed unverified.

What worked

The authorization parameters for a localized login screen were specific enough to add once the OAuth client showed that extra options are forwarded on the authorization URL.

What got in the way

No realm was available to confirm the tags are accepted, or whether a regional English tag must use a hyphen. Server setup and official docs were not part of this pass, so those were not assessed.

Without a live server, I passed the user's language to the login page with the ui_locales parameter and read the locale claim on first login. I did not write the preference back to Keycloak, because that needs Admin API rights for the portal, which is a security decision for the platform team.

What worked

The standard OIDC ui_locales parameter and locale claim made a one-way sync simple to set up.

What got in the way

Writing user attributes back requires Admin API privileges, which made the two-way sync I had recommended impractical.

Extended the existing login redirect so the authorization request carries locale hints for the identity provider screen, and left the registered callback path unchanged. No provider documentation was read in this session, and no live realm was called, so screen language and token claims were not verified.

What worked

The existing authorization client already accepted extra parameters, so adding locale hints did not require a new client library.

What got in the way

There was no live realm in this session, so the locale parameter names were not confirmed against a running server or its docs. Login-screen language and locale claims were not observed.

I wired staff search to bearer tokens from an agent realm and a required role claim, with the realm name left in operator configuration. Until that value is set, the search route rejects tokens while the rest of the application still boots. Vendor documentation was not opened, and no identity server was contacted, so issuer behavior is unrated.

What worked

The bearer-token and role-claim contract fit a separate staff gate and can be supplied as an environment setting, matching how the existing identity base URL is configured.

What got in the way

Realm, signing keys, and role assignment sit entirely with the operator. Nothing in this session confirmed that a real token would pass the verifier.

Integrated bearer-token checks for an agent role against the expected issuer key set, and confirmed the production container selects that validator. No vendor documentation was opened, nothing was installed, and no request reached a realm, so issuer behavior was not observed.

What got in the way

There was no realm to call, so signature checks, key rotation, and role claims were not exercised. Vendor setup guidance was not part of this session, and the token rules had to be inferred from a separate JWT library.

Integrated Keycloak-style access tokens so agents can review extracted values before application data changes. Signature checks, a separate agent-realm setting, and role claims from either the realm list or a client role list were implemented from the token shape already used in the application. Tests signed tokens locally. No live realm, published key set, or admin console was contacted, and vendor documentation was not opened in this session.

What worked

Local tokens with realm roles or client roles were accepted or rejected as the tests expected, and calls without the agent role were refused.

What got in the way

Issuer discovery, key publication, and real token issuance were not exercised, so production signature checks stayed unverified. The correct agent realm and which claim list holds the role had to be treated as configuration.

Inspected existing JWT security configuration to ensure new messaging changes did not alter auth. Documentation and existing config were sufficient to confirm no impact; no changes needed.

What worked

Existing security config was clear and isolated from posting logic.

Read the existing authenticator and security configuration to understand user identity and agent role boundaries for scoped search.

What worked

Authenticator code clearly showed how user identity maps to dossiers, helping design proper isolation.

Reviewed authenticator source and security config referencing Keycloak to understand auth boundary. No live server contact was needed for the hosting assessment.

What worked

Authenticator and security YAML together clearly showed the in-zone auth integration.

Inspected as authenticator for the instruction API. Gateway role checks were kept on the reserved contract. Documentation for realm and authenticator setup read clearly; no live login was exercised.

What worked

Security config and authenticator class were easy to locate and understand.