Management Console integration with OIDC-compliant Identity Provider

Feature availability

Supported in: Resilio Active Everywhere 5.0.7

Configure connection to your Identity Provider

Warning

Before you proceed with setting up integration with OpenID Identity Provider, make sure to configure Management Console Address, Management Console Address for data managers and enable Use Management Console address for IdP redirect URI option in Advanced Settings.

To configure connection to your Identity Provider:

1. In the Resilio Management Console, select Settings > General.
2. In the OPENID CONNECT AUTHENTICATION section, click Configure.

3. Provide configuration parameters for integration with your Identity Provider:

   • IdP name - The display name of the Identity Provider you're integrating with. This value will be used on the Management Console's login screen and included in the requests sent to the IdP.

     

     Note

     • Keep the name short. For example, Resilio MC IDMS.
     • Do not use: Okta, Entra ID, Microsoft Entra ID.

   • Metadata URL - A URL to your Identity Provider’s metadata document (used for auto-configuration).

     Tip

     In Okta, you can find the Metadata URL in your Authorization Server settings.

     

   • Enable issuer validation - Additional security check to verify that the domain in the metadata URL matches the domain in the issuer value returned by the metadata document. Disable this option if you're expecting a mismatch.

   • Redirect URL for regular users - Redirect URL on the IdP side for users logging into the Management Console.

     Tip

     In Okta, you can configure the redirect URL in the Admin Console under your OIDC app > General (or General Settings) > Login > Sign-in redirect URIs.

     

   • Redirect URL for data managers - Redirect URL on the IdP side for users logging into the Data Managers Console.

   • Client ID - The public identifier of your OIDC application (client) that the IdP uses to recognize which application is requesting authentication and tokens.

     Tip

     In Okta, you can find the Client ID in the Admin Console under your OIDC app > General, in the Client Credentials section.

     

   • Client secret - A confidential password for your OIDC application that your system uses to authenticate to the IdP when exchanging an authorization code for tokens.

     Tip

     In Okta, you can find (or generate) the Client secret in the Admin Console under your OIDC app > General, in the Client Credentials section.

     

   • Authorization scopes - Scopes control what data the application receives. Include one that returns user groups (for example, groups or user_groups, depending on your IdP config) so group mapping works.

     Tip

     A typical set of authorization scopes for OIDC is: openid email profile offline_access.

     Note

     In Okta, group scope must be configured in Okta itself, and it must be included in the scope list: for example, openid email profile offline_access user_groups.

     For instructions on adding custom groups scope in Okta, see Management Console intagration with Okta: Authorizatino server - Scopes.

   • User groups mapping - Group mapping defines how groups coming from your IdP are translated into access and permissions in the Management Console.

     • Strictly by name - The system expects the IdP to provide group display names. Mapping is based on the exact string match (the incoming group name must match the configured/expected name).

     • Custom - Mapping is based on custom rules. For example, systemAdmin matches Super Administrator.

       The match is performed against the group identifier included in the OIDC ID token (that is, the value delivered in the groups/roles claim), which may be a UID/UUID/object ID, not necessarily display names.

       Example: Custom groups mapping rules

       

   • User roles claim - The User roles claim is a JWT claim that contains the user’s roles so your application can authorize what the user is allowed to do.

     Tip

     In Okta, this claim is customizable, it’s typically added as a custom claim on your Authorization Server and linked to the groups scope so it’s returned when that scope is requested. For instructions on adding custom groups scope in Okta, see Management Console intagration with Okta: Authorizatino server - Claims.

   • User display name claim - The JWT claim used to show the user’s name in the UI. By default, this claim is preferred_username.

4. Click Save.

   

Issuers mismatch warning

On server restart, the system re-fetches metadata from your custom Identity Provider. If the issuer returned during restart does not match the previously stored issuer, the Management Console will display a warning:

The OIDC issuer obtained from the metadata endpoint differs from the previously stored value. This may indicate a security risk or configuration change at your Identity Provider. Please review your Identity Provider configuration.

If an issuer change is expected, simply dismiss the warning or re-save the integration configuration.

Peculiarities and limitations

• Microsoft Entra ID configuration is not supported through this connector.
• Login may fail if provider name in metadata changes. Restart the Management Console so that it updates the issuer information that is used for token verification.