Version: 2026.10

Manual setup without the provisioner

For installations without the provisioner, generate the Identity Service keys and platform credentials below. Complete identity provider registration separately.

Before you start

Keep Identity Service, client integration, and the API Gateway enabled. Disable both provisioner modes:

provisioner:
  enabled: false
  external: false

Supply all the keys and client settings below before installing. On an existing deployment, preserve its current key material and client IDs while updating configuration.

Generate Keys

Generate two values:

the signing key (required), which signs every token the Identity Service issues and backs its public signing keys (JWKS);
the token encryption key, which protects stored provider tokens and sign-in state.

Generate both keys locally with openssl and jq:

SIGNING_KEY=$(jq -n --arg id "identity-$(date +%Y%m%d)" \
  --arg key "$(openssl ecparam -name secp384r1 -genkey -noout | openssl pkcs8 -topk8 -nocrypt)" \
  '{keyId: $id, key: $key}' | base64 | tr -d '\n')
TOKEN_ENCRYPTION_KEY=$(openssl rand -base64 32)
test -n "$SIGNING_KEY" && test -n "$TOKEN_ENCRYPTION_KEY" && echo "Both keys generated" \
  || echo "Key generation failed: check the output above" >&2

Put $SIGNING_KEY in the istari-identity secret as ISTARI_DIGITAL_IDENTITY_SERVICE_SIGNING_KEY, and $TOKEN_ENCRYPTION_KEY as ISTARI_DIGITAL_IDENTITY_SERVICE_TOKEN_ENCRYPTION_KEY (Identity Service Secret). Both are secrets. The commands above keep them in shell variables only; if you then put them in a file to create the secret, delete the file once it is applied, and close the shell when you are done.

warning

Always set the token encryption key in production. Without it the service still starts, with a warning, but it does not keep the upstream identity provider's tokens and stores in-flight sign-in state unencrypted. A malformed value of either key prevents startup.

Key formats, bringing your own signing key, and rotating the encryption key

Signing key. The value is the base64 of a JSON object, {"keyId": "<identifier>", "key": "<private key PEM>"}. The command above makes an ECDSA P-384 key. A key you bring yourself must be ECDSA P-384 or RSA of at least 3072 bits, in a PKCS#8, SEC1 or PKCS#1 PEM; anything weaker fails validation at startup. The keyId becomes the kid published in the JWKS.

Token encryption key. Each key is the base64 encoding of exactly 32 bytes. For rotation, place a new key first in the comma-separated list and retain old keys until dependent sessions and provider grants have expired or been re-encrypted. Losing a key can invalidate sessions and stored grants; recovering a Google refresh grant may require renewed consent.

Register the platform clients

Generate the Registry credential and set the three required client variables before starting Identity Service.

warning

If you supplied the credentials by hand and the provisioner is on, which it is by default from 7.0.0, supply the registry's credential as both halves under the current names, or neither: ISTARI_DIGITAL_IDENTITY_SERVICE_CLIENT_CREDENTIALS (the private half) in the registry's secret, and ISTARI_DIGITAL_IDENTITY_SERVICE_REGISTRY_PUBLIC_KEY_B64 in istari-identity. If you supply the private half only under the legacy FILE_SERVICE_IDENTITY_ROUTER_SECRET, or only one half, the registry's calls to the Identity Service fail once the provisioner runs.

Generate the registry's credential

Run the generator as a one-off pod on the Identity Service image. It needs no database access:

kubectl run gen-client-credentials --quiet --rm -i --restart=Never \
  --image=istaridigital.jfrog.io/customer-docker/identity-service:<tag> \
  --overrides='{"spec":{"imagePullSecrets":[{"name":"docker-pull-secret"}]}}' \
  --command -- /gen-client-credentials --stdout | grep -A5 '^{'

Use your deployed image tag. Copy registry_secret, which contains the Registry private key.

Derive the registry's public key from it, for the Identity Service:

echo "<registry_secret>" | base64 -d | jq -r .key | openssl pkey -pubout | base64 | tr -d '\n'

A credential generated by an Identity Service release before 2.0.1 names a client ID with a suffix (for example registry-a1b2), and the Identity Service no longer registers that client. Generate a new one.

Chart install without the provisioner

Add these keys to the services' own secrets. The chart still renders the API URL and the identity-service switch for each service from common.mainFqdn and identity.clientIntegration.enabled, but not the redirect allowlists, which it derives only for the provisioner.

Secret	Keys
`istari-identity`	`ISTARI_DIGITAL_IDENTITY_SERVICE_REGISTRY_PUBLIC_KEY_B64=<public key from step 2>`, `ISTARI_DIGITAL_IDENTITY_SERVICE_FRONTEND_REDIRECT_URIS=https://<customer_istari_fqdn>`, `ISTARI_DIGITAL_IDENTITY_SERVICE_MCP_REDIRECT_URIS=https://mcp.<customer_istari_fqdn>/auth/callback`
`istari-fileservice`	`ISTARI_DIGITAL_IDENTITY_SERVICE_CLIENT_CREDENTIALS=<registry_secret from step 1>`
`istari-mcp`	`ISTARI_DIGITAL_IDENTITY_SERVICE_CLIENT_SECRET=<a generated value, e.g. openssl rand -hex 32>` (if the MCP service is deployed)

The frontend needs nothing: it uses the client ID frontend by default. The Identity Service needs the MCP allowlist even when the MCP service is not deployed. Then run helm upgrade --install and restart the Identity Service, registry, frontend and MCP service.

Installations not using the chart

Set these variables, then restart the Identity Service, followed by the registry, frontend and MCP service:

Service	Variables
Identity Service	`ISTARI_DIGITAL_API_URL=https://api.<customer_istari_fqdn>`, `ISTARI_DIGITAL_IDENTITY_SERVICE_CORS_ALLOWED_ORIGINS=https://<customer_istari_fqdn>`, `ISTARI_DIGITAL_IDENTITY_SERVICE_REGISTRY_PUBLIC_KEY_B64=<public key from step 2>`, `ISTARI_DIGITAL_IDENTITY_SERVICE_FRONTEND_REDIRECT_URIS=https://<customer_istari_fqdn>`, `ISTARI_DIGITAL_IDENTITY_SERVICE_MCP_REDIRECT_URIS=https://mcp.<customer_istari_fqdn>/auth/callback`
Registry	`ISTARI_DIGITAL_API_URL=https://api.<customer_istari_fqdn>`, `ISTARI_DIGITAL_IDENTITY_SERVICE_ENABLED="true"`, `ISTARI_DIGITAL_IDENTITY_SERVICE_CLIENT_CREDENTIALS=<registry_secret from step 1>`
Frontend	`VITE_ISTARI_DIGITAL_API_URL=https://api.<customer_istari_fqdn>`, `VITE_ISTARI_DIGITAL_IDENTITY_SERVICE_ENABLED="true"`
MCP (if deployed)	`ISTARI_DIGITAL_API_URL=https://api.<customer_istari_fqdn>`, `ISTARI_DIGITAL_IDENTITY_SERVICE_ENABLED="true"`, `ISTARI_DIGITAL_IDENTITY_SERVICE_CLIENT_SECRET=<a generated value, e.g. openssl rand -hex 32>`

The CORS value is the full comma-separated list of allowed browser origins. Without the chart, you supply it yourself; the frontend/MCP redirect allowlists are separate settings.

Rotating the registry's key

Generate a new credential, replace the two values, and restart the Identity Service and the registry together. The Identity Service replaces the registry client's key when it restarts, so the registry's requests to it fail until the registry restarts with the new credential.

Install and verify

Apply the chart with these Secrets, then verify the installation.

Before you start​

Generate Keys​

Register the platform clients​

Generate the registry's credential​

Chart install without the provisioner​

Installations not using the chart​

Rotating the registry's key​

Install and verify​