OpenID Connect Integration

For OpenID Connect Integration, the Pimcore OpenID Connect bundle needs to be added via composer and enabled. Details see here.

The portal engine provides an integration with OpenID Connect to provide SSO functionality. The configuration takes place directly in the portal configuration document. Thus per portal different OpenID Connect providers could be configured.

For every user that login via OpenID Connect, a PortalUser object will be created in the configured folder (see below). The matching is done via the External User ID field and user data is updated during every login.

By default, these users are not allowed to change their password. So they also cannot login directly without the roundtrip to the SSO provider. If you manually set a password, or change the Allow Password Change permission, it also would be possible to login with this user directly.

Besides updating basic user information like E-Mail, First Name and Last Name, also Groups will be synchronized with the OpenID Connect provider. The integration checks in a defined folder for PortalUserGroup objects that match with their key the groups delivered by the OpenID Connect provider. Matching PortalUserGroup objects are assinged to the PortalUser objects. So, it is possible to preconfigure a set of user permissions for SSO users. Otherwise, they would not have any permissions and hence they also would not be allowed to login to any portal.

Configuration Options

Following two configuration options are available:

• Always directly redirect to first OpenID Connect provider instead of the default portal login page: By default, not logged in users trying to access the portal are redirected to the portal engine login page. If this option is activated, these users are redirected directly to the first configured OpenID connect provider skipping the default login page. With calling the URL of the portal page login page directly (https://<YOUR_DOMAIN)/auth/login), it is still possible to access the portal page login page to login with local users.

• Providers: Configure one or multiple OpenID connect providers, details see below. For every configured provider, an additional login button is shown on the login page that redirects to the corresponding login pages.

Provider Settings

Each provider has to have a unique name.

On provider side, you normally need to configure an application to allow Pimcore to access. Following information you might need from Pimocore for that:

• Redirect URL: https://<YOUR_PORTAL_DOMAIN>/auth/oidc/endpoint
• Allowed scopes: openid profile groups email (see also settings below)

For every provider, following settings are possible:

• Provider Name: Name of the provider, can be chosen freely.
• Client ID: Client ID provided by the provider.
• Client Secret: Client Secret provided by the provider.
• Discovery URL: Discovery URL provided by the provider for discovering all the URLs and Certificates. Typically, this is something like https://<PROVIDER>/.well-known/openid-configuration.
• Folder for created users: For all users, PortalUser data objects will be created and stored in this folder. Matching is done via the External User ID field, user data is updated during every login.
• Folder to look for groups: If OpenID Connect provider delivers roles for the user, these are matched with PortalUserGroup objects and assigned to the PortalUser. Matching is done via the key of PortalUserGroup objects located in this folder (or any sub folders).

Optionally, following additional options can be provided for each provider:

• Additionally load user info during sign-in: Sometimes it is necessary to also call the user info endpoint of the provider to get all the necessary information about the user as the id-token does not contain it. Setting this setting to true will initiate this additional call. If not necessary, it should be prevented, as it slows down the sign-on process.
• Scopes: Customize the scopes for the OpenId Connect flow. By default, openid, profile, email and groups is set as scope. openid will always be added automatically, as it is required for any OpenId Connect flow.
• Claim Mappings: Some provides do not apply to claim names of the OpenId Connect standard. With this setting you can configure custom names for the supported claims preferred_username (contains the username), given_name, family_name, email, groups (should contain an array of groups the user is assigned to), picture (URL to fetch the user avatar) and sub (remote-id of the user).

Just leave these values empty for using the default values.