Keycloak realm changes for SmartEM Agent authentication
Draft text for a Jira ticket to DLS Keycloak administrators.
Summary
We need two changes to the dls Keycloak realm to support authentication for the SmartEM Agent, a service that runs unattended on EPU workstations and communicates with the SmartEM Decisions backend over HTTP.
The SmartEM Decisions backend already enforces Keycloak Bearer-token validation on all non-exempt endpoints. The SmartEM frontend authenticates via OIDC. The agent needs an equivalent service-to-service authentication path. We have chosen the OAuth 2.0 client_credentials grant (RFC 6749 §4.4), with a clean upgrade path to private_key_jwt as a planned future hardening.
The architectural decision is recorded in ADR 0018 in the smartem-devtools repository.
Changes requested
1. Rename the existing browser-facing client
The existing client used by the SmartEM frontend should be renamed for symmetry with the new agent client:
| Field |
Current |
New |
clientId |
SmartEM |
SmartEM_User |
No other configuration changes. The client remains a public client used by the OIDC authorisation-code flow with PKCE. We will coordinate the matching frontend configuration update so there is no downtime.
2. Add a new confidential client for the agent
Add a new service-account client for the SmartEM Agent. Suggested configuration (matches the local mock realm):
| Field |
Value |
clientId |
SmartEM_Agent |
name |
SmartEM Agent |
description |
Service account client for SmartEM Agents running on EPU workstations. Uses the OAuth 2.0 client_credentials grant. |
enabled |
true |
publicClient |
false |
clientAuthenticatorType |
client-secret |
serviceAccountsEnabled |
true |
standardFlowEnabled |
false |
directAccessGrantsEnabled |
false |
implicitFlowEnabled |
false |
defaultClientScopes |
openid, profile, roles |
secret |
Please generate and share via a secure channel. |
Verification
Once the changes are in place we will verify by:
-
Obtaining a token via:
curl -X POST \
-d "grant_type=client_credentials" \
-u "SmartEM_Agent:<secret>" \
https://<keycloak-url>/realms/dls/protocol/openid-connect/token
-
Confirming the token's azp claim is SmartEM_Agent.
-
Confirming the existing frontend continues to work against the renamed SmartEM_User client (frontend configuration updated by us in coordination).
Coordination notes
- The frontend configuration update (to reference the renamed
SmartEM_User client) is ready to deploy and will be coordinated with the rename.
- No other DLS systems are known to depend on the existing
SmartEM client name. If you are aware of any, please let us know before applying the rename.
Context links
Keycloak realm changes for SmartEM Agent authentication
Draft text for a Jira ticket to DLS Keycloak administrators.
Summary
We need two changes to the
dlsKeycloak realm to support authentication for the SmartEM Agent, a service that runs unattended on EPU workstations and communicates with the SmartEM Decisions backend over HTTP.The SmartEM Decisions backend already enforces Keycloak Bearer-token validation on all non-exempt endpoints. The SmartEM frontend authenticates via OIDC. The agent needs an equivalent service-to-service authentication path. We have chosen the OAuth 2.0 client_credentials grant (RFC 6749 §4.4), with a clean upgrade path to private_key_jwt as a planned future hardening.
The architectural decision is recorded in ADR 0018 in the smartem-devtools repository.
Changes requested
1. Rename the existing browser-facing client
The existing client used by the SmartEM frontend should be renamed for symmetry with the new agent client:
clientIdSmartEMSmartEM_UserNo other configuration changes. The client remains a public client used by the OIDC authorisation-code flow with PKCE. We will coordinate the matching frontend configuration update so there is no downtime.
2. Add a new confidential client for the agent
Add a new service-account client for the SmartEM Agent. Suggested configuration (matches the local mock realm):
clientIdSmartEM_AgentnameSmartEM AgentdescriptionenabledtruepublicClientfalseclientAuthenticatorTypeclient-secretserviceAccountsEnabledtruestandardFlowEnabledfalsedirectAccessGrantsEnabledfalseimplicitFlowEnabledfalsedefaultClientScopesopenid,profile,rolessecretVerification
Once the changes are in place we will verify by:
Obtaining a token via:
Confirming the token's
azpclaim isSmartEM_Agent.Confirming the existing frontend continues to work against the renamed
SmartEM_Userclient (frontend configuration updated by us in coordination).Coordination notes
SmartEM_Userclient) is ready to deploy and will be coordinated with the rename.SmartEMclient name. If you are aware of any, please let us know before applying the rename.Context links
docs/decision-records/decisions/0018-smartem-agent-keycloak-auth.mddocs/agent/authentication.md