OpenID Providers

OpenID Providers#

sysman sysadmin

With OpenID Connect (OIDC) single sign-on, users sign in to Allegra with their existing accounts at an external identity provider. You manage credentials, password policies, and multi-factor authentication centrally at the provider.

Allegra supports four provider types, each of which can be configured once:

Single sign-on is optional: the local sign-in with username and password always remains available. For each activated and fully configured provider, the login page shows an additional button Continue with {provider} below the normal login button — for example Continue with Keycloak.

Allegra uses the OAuth 2.0 authorization code flow with PKCE. Except for Microsoft Entra ID, all endpoints of the identity provider are discovered automatically from the issuer’s /.well-known/openid-configuration.

Managing providers#

To configure OpenID providers, sign in as a system administrator and go to Administration > Users & Groups > Authentication > OpenID providers.

The list shows the configured providers with their name, creation date, and last edit. The Add button offers the four provider types; a type that is already configured is grayed out. Use the actions on a list entry to edit or delete a provider.

Note

The LDAP configuration can be found in the neighboring folder User directories.

Common settings#

Keycloak, Google, and generic OpenID Connect providers share the same configuration form. Microsoft Entra ID has its own form, described in Microsoft Entra ID.

In the fieldset OpenID Connect configuration you enter the Client ID and the Client secret from the application you registered at the identity provider. Without them, no login button is shown. After saving, the client secret is only displayed masked; to replace it, remove it first with the Remove client secret button. Leaving the field empty when saving keeps the stored secret.

The fieldset Single Sign On configuration contains:

Single Sign On configuration#

Field

Description

SSO activated

Enables the provider on the login page. The remaining fields are disabled until checked.

Callback URL (read-only)

The URL you must register at the identity provider as the callback (redirect) URL, with a copy-to-clipboard button. See Callback URL.

Automatically register unknown users as

Do not register unknown users (default), Full users, or Guest users. See User matching and auto-registration.

Match Allegra users to identity provider users by

Whether the identifier reported by the provider is compared against the Allegra email address (default) or the Allegra username. See User matching and auto-registration.

Issuer URL

Required. The base URL of the identity provider from which the OpenID Connect endpoints are discovered.

Application scopes

Required. The list of OpenID Connect scopes. Default: openid profile email. The scopes openid and email are re-added automatically if removed.

Callback URL#

At the identity provider, you must register the Allegra callback (redirect) URL:

<Allegra server URL>/sso/callback

The exact URL is displayed read-only in the provider form and can be copied to the clipboard. It is built from the server URL configured in Allegra’s server settings (Administration > Server administration > More settings >) — make sure that URL is correct, including https://.

If the identity provider validates post-logout redirect URLs, additionally register the Allegra server base URL there.

User matching and auto-registration#

When a user signs in through an identity provider, Allegra determines the matching Allegra account in two steps:

  1. The provider reports an identifier. This is fixed per provider type: Microsoft Entra ID reports the preferred_username claim; Keycloak, Google, and generic OpenID Connect providers report the email claim.

  2. The setting Match Allegra users to identity provider users by decides which Allegra field this identifier is compared against:

    • IdP email matches Allegra email address (default) — compared against the user’s email address. If several Allegra users share the same email address, the first match is used and a warning is logged.

    • IdP email matches Allegra username — compared against the Allegra login name. The full identifier is compared, e.g. the whole email address, never just the part before the @.

Note

If the identity provider explicitly reports the email address as not verified (email_verified=false), sign-in and auto-registration are refused.

If no matching account exists, the setting Automatically register unknown users as applies. With Do not register unknown users (the default), the sign-in fails. Otherwise Allegra creates a new account with the identifier as both login name and email address, first and last name from the provider’s name claim, a random password, and the user level Full user or Guest user as configured. If the provider does not report a name claim, no account is created and the sign-in fails.

Signing in and out#

Clicking Continue with {provider} redirects the user to the identity provider. After authenticating there, the user is signed in to Allegra and lands on the originally requested page. JavaScript is required for SSO sign-in. A pending sign-in expires after 10 minutes on the identity provider’s page; the user then gets a validation error and must retry.

Signing out of an SSO session also signs the user out at the identity provider and returns to the Allegra login page. Exception: Google — and any provider without a logout endpoint — signs the user out of Allegra only.

During maintenance mode, only system administrators can sign in — this also applies to SSO.

Upgrading from versions before 9.0.2#

OpenID providers were introduced with Allegra 9.0.2 and replace the previous Microsoft Azure SSO integration:

  • An existing Azure configuration is migrated automatically and appears as the Microsoft Entra ID provider.

  • The global SSO enabled server setting was removed; its value moved into the per-provider SSO activated check box.

  • Entra configurations created before 9.0.2 keep their old redirect URI (msAzureSsoCallback.action), so the Azure app registration needs no change. Newly created providers use /sso/callback.

  • The matching option username with processed email was removed. Affected configurations are switched to email matching automatically. Verify your user matching setting after the upgrade.

Contents