Connect your identity provider

Clients can enter the queue anonymously, or sign in with your organisation's own identity provider first — so the operator sees a verified identity, and the client's language, priority tier and personal manager feed matching. The Access & identity page is where an organisation admin connects that provider and decides whether clients must, may, or never sign in.

Any standard OpenID Connect (OIDC) provider works — Keycloak, Microsoft Entra ID, Auth0, Okta, Google, or another OIDC service — with no change on the QMS side.

Prerequisites

• An organisation admin sign-in. Location managers and operators do not see this page.
• Admin access to your identity provider, to register QMS as a client application there.

Connect a provider

Open Access & identity in the sidebar and click Connect identity provider. The guided setup opens as a full page with six steps.

1. Setup guide. Choose the service you are connecting: Keycloak, Microsoft Entra ID, Auth0, Okta, Google, or Other OIDC service (the default). The guide only changes the instructions and the example values shown in the fields — every provider is saved as a generic OIDC connection.

2. Callback address. The page shows your workspace's callback address, https://<your-workspace-host>/c/auth/callback. Click Copy and register this exact address with your provider as the allowed redirect URI.

3. Connection details. Enter a display name, the issuer URL and the client ID from your provider, and choose the client authentication method:

   • Client secret, sent in the header (recommended, preselected) — client_secret_basic.
   • Client secret, sent in the request body — client_secret_post.
   • No secret (public client with PKCE) — none.

   For the two secret-based methods, paste the client secret from your provider. The secret is write-only: once saved, the page never shows it again, not even masked — it shows Set on and the date with a Replace action. The secret is stored encrypted. Switching the method to No secret erases the stored secret.

4. Connection check. Click Check connection. QMS reads your provider's discovery document for the issuer URL as entered and shows the issuer and its authorization, token, JWKS and (when published) user-info endpoints. If the check fails, it names one cause:

   Code	Meaning
   unreachable	No connection could be made to the issuer.
   timeout	The provider did not respond in time.
   not_https	The issuer or one of its endpoints is not https.
   private_address	The issuer resolves to a private or internal network address.
   issuer_mismatch	The discovery document names a different issuer — often a trailing slash.
   missing_endpoint	The discovery document lacks the authorization, token or JWKS endpoint.
   invalid_document	The response is not an OIDC discovery document.

5. Test sign-in. Once the check succeeds and the client ID (and, for a secret-based method, the secret) is in place, click Test sign-in. Your provider's login opens in a new window — allow pop-ups for the console if the browser blocks it. Sign in with any account of your provider. Back in the setup you see exactly what QMS received: the issuer, the subject, and the display name, email, language, priority tier and personal manager, each marked Not provided when the provider did not send it. Changing the issuer URL makes you run the check and the test again.

6. Activation. Review the configuration and click Activate. If no other provider is active, this one also becomes the primary.

A provider is saved inactive and only a provider whose current configuration passed a test sign-in can be activated. QMS requests the openid, profile and email scopes and reads the display name from the name claim, the email from email, the language from locale and the personal manager from personal_manager.

Manage providers

The Identity providers section lists every provider with its status:

• Untested — saved, never successfully tested with its current configuration.
• Tested — the current configuration passed a test sign-in; ready to activate.
• Active — clients can sign in with it.
• Active without a test — an integration activated it, or changed its connection while it was active, without a test sign-in. Clients can sign in with it, but nothing has confirmed they will succeed. A warning under the provider says so, with a Run a test sign-in link that opens its setup: once a test sign-in succeeds and you apply it, the provider becomes Active. Deactivating it also clears the warning.

From the list you can Edit, Activate or Deactivate, Set primary, reorder with Move up / Move down, and Remove a provider. Clients sign in with the primary provider; it must be active, so it cannot be deactivated, and it cannot be removed while other providers remain — make another provider primary first. The order is presentation only.

Editing opens the setup at the connection details with the saved values. A display name change saves directly. A change to the issuer URL, client ID, authentication method or secret of an active provider cannot be saved on its own: run the test sign-in again, then apply it with Activate changes. Until then clients keep signing in with the old configuration. For an inactive provider, the change saves and the provider goes back to Untested.

Choose how clients enter

The Entry & authentication section sets one policy for the whole workspace — every branch and every service:

Option	What clients see
Anonymous only (default)	No sign-in is offered; every ticket is anonymous. No provider is needed.
Anonymous + sign-in	Clients choose Sign in or Continue as guest. If the provider is unavailable, they can still continue as a guest.
Sign-in required	Every client must sign in before getting a ticket. If the provider is unavailable or the client cancels, no ticket is issued.

• Anonymous + sign-in and Sign-in required can only be chosen while an active provider exists.
• Sign-in required cannot be chosen while the primary provider is Active without a test: run a test sign-in of the primary first.
• A signed-in client holds one active ticket at a time; guest tickets are not limited this way.
• The tablet kiosk never shows a provider's sign-in on its shared screen. Under Sign-in required it shows only the QR code for clients to scan with their phone; under Anonymous + sign-in on-screen registration issues guest tickets.
• A change applies to the next ticket — QR codes do not need to be regenerated, and tickets already issued keep the policy they were issued under.
• While the policy is not Anonymous only, the last provider cannot be removed: switch the policy to Anonymous only first.

Changing the policy is separate from the providers: activating, deactivating or switching the primary provider never changes it.

Audit

Creating, updating, activating, deactivating, making primary, reordering and removing a provider, setting, replacing or erasing its client secret, and every policy change are recorded in the audit log. The secret itself is never recorded. Connection checks and test sign-ins change nothing and are not recorded.

Over the integration API

An integration can manage your providers — connect, edit, activate, deactivate, make primary, reorder and remove them, change their client authentication and run the connection check — and read or set the entry policy — see Integrations. The test sign-in stays in the console, so a provider an integration activates without one shows as Active without a test.