Configure Entra ID SSO for RadiantOne Control Panel (v8 and v8.1+)

This article explains how to configure Microsoft Entra ID (formerly Azure AD) as an OpenID Connect (OIDC) Identity Provider for Single Sign-On (SSO) to the RadiantOne Control Panel for versions v8 and v8.1.1+.

Important: Always replace any example values (IDs, URLs, emails, secrets) with your own. Never store real secrets or personal data in documentation or screenshots.

Version overview

Use this section to determine which configuration path to follow.

Make sure you select the correct section below based on your deployed RadiantOne version.

Prerequisites

Before you start, confirm the following:

• You have a Microsoft Entra ID tenant and an account with permission to create app registrations.
• Your RadiantOne Control Panel (v8 or v8.1.1+) is reachable over HTTPS.
• Delegated admin accounts already exist in RadiantOne under the cn=config naming context.
• Your test admin users are or will be assigned to Delegated Admin roles in RadiantOne.

Part A – Entra ID configuration (all versions)

Follow these steps in the Microsoft Entra admin center.

1. Create the app registration

1. Sign in to the Microsoft Entra admin center at https://entra.microsoft.com.
2. Go to Identity › Applications › App registrations.
3. Click New registration.
4. Set Name to something like RadiantOne Control Panel SSO.
5. For Supported account types, choose Accounts in this organizational directory only (Single tenant).
6. For Redirect URI (type Web), use the URL that matches your RadiantOne version:
   • v8.0–v8.1.0: https://<your-control-panel-domain>/main/j_spring_openid_security_check
   • v8.1.1+: https://<your-control-panel-domain>/callback
7. Click Register.

2. Configure authentication

1. Open the app registration you just created.
2. Go to Authentication.
3. Confirm the Redirect URI you entered is listed.
4. Enable Front-channel logout session required (recommended for clean logout).
5. Under Implicit grant and hybrid flows:
   • For v8.0–v8.1.0: enable Access tokens and ID tokens.
   • For v8.1.1+: enable ID tokens; access tokens are not required for this flow.
6. Click Save.

3. (v8.0–v8.1.0) Create a client secret

For v8.0–v8.1.0 you must configure a client secret; v8.1.1+ does not use it for Control Panel SSO.

1. Go to Certificates & secrets.
2. Click New client secret.
3. Add a description (for example: RadiantOne Control Panel Client Secret).
4. Choose an expiry according to your security policy and click Add.
5. Copy the Value immediately and store it securely (you will not be able to see it again).

Note: Do not paste real secrets into tickets, documentation, or source control.

4. Collect required IDs and endpoints

From the app registration Overview and related pages, collect:

• Application (client) ID – used as the OIDC Client ID in RadiantOne.
• Directory (tenant) ID – used in the discovery and token endpoints.
• (v8.0–v8.1.0) The client secret value from the previous step.

RadiantOne will either discover or use the following endpoints based on your tenant ID:

• Authorization endpoint: https://login.microsoftonline.com/{tenant-id}/oauth2/v2.0/authorize
• Token endpoint: https://login.microsoftonline.com/{tenant-id}/oauth2/v2.0/token
• JWKS URL: https://login.microsoftonline.com/{tenant-id}/discovery/v2.0/keys

(Optional) Add API permissions such as openid, profile, email, and offline_access for richer claims and refresh tokens.

Part B – RadiantOne v8.0–v8.1.0 configuration

Use these steps if your Control Panel is on RadiantOne v8.0–v8.1.0.

1. Open OIDC provider configuration

1. Sign in to the RadiantOne Control Panel as an administrator.
2. Navigate to Settings › Security › OIDC Provider Configuration.

2. Configure discovery and endpoints

1. Set OIDC Provider to CUSTOM.
2. In OIDC Discovery URL, enter: https://login.microsoftonline.com/{tenant-id}/v2.0/.well-known/openid-configuration (replace {tenant-id}).
3. Click Discover to auto-populate authorization, token, and JWKS endpoints (fill them manually if discovery fails).

3. Configure client credentials and scope

1. Client ID: paste the Entra Application (client) ID.
2. Client Secret: paste the client secret value you created in Entra ID.
3. Client Authentication Method: set to CLIENT_SECRET_POST.
4. Scope: use openid profile email (add offline_access if you configured it in Entra ID).

4. Configure OIDC-to-user mapping

This mapping connects the Entra ID user to a delegated admin account in RadiantOne.

Common options include:

• Email-based (recommended): search cn=config for users where mail or userPrincipalName matches the email claim from Entra ID.
• Name-based or UPN-based mappings if your environment prefers those attributes.

Ensure the mapping resolves to an existing delegated admin DN under cn=config.

5. Save and test

1. Click Save in the OIDC configuration panel.
2. Log out of the Control Panel and initiate login via Entra ID.
3. Confirm your test user is prompted by Entra ID and then redirected back to RadiantOne with an authenticated session.

Part C – RadiantOne v8.1.1+ configuration (PKCE, no secret)

Use these steps if your Control Panel is on RadiantOne v8.1.1 or later.

1. Open Control Panel configuration

1. Sign in to the RadiantOne Control Panel as an administrator.
2. Go to Admin › Control Panel Configuration in the new Control Panel.

2. Configure OIDC endpoints

1. In the OIDC configuration area, set the provider to CUSTOM (or compatible option, depending on UI).
2. Use the discovery URL: https://login.microsoftonline.com/{tenant-id}/v2.0/.well-known/openid-configuration.
3. Run discovery to populate authorization, token, and JWKS URLs.

3. Configure PKCE client settings

1. Client ID: paste the Entra Application (client) ID.
2. Client Secret: leave this field empty for v8.1.1+; the Control Panel uses PKCE instead of a shared secret.
3. Verify Client Authentication Method is set to a PKCE-based option (label may be PKCE or similar, depending on UI).
4. Scope: configure openid profile email (and add any additional scopes you require, such as offline_access).

Note: You can still create a client secret in Entra ID for other applications, but the v8.1.1+ Control Panel does not use it when PKCE is enabled.

4. Configure OIDC-to-user mapping

Define how Entra ID claims map to RadiantOne delegated admin users.

Typical options:

• Email-based (recommended): use the email claim to find matching mail or userPrincipalName values under cn=config.
• UPN-based: use the upn claim to match mail or uid.
• Name-based or custom expressions combining multiple claims.

To reduce errors, use the built‑in expression builder (Simple DN or Search expression) instead of hand‑writing LDAP filters. The builder enforces the correct syntax and format for your mappings, which helps prevent subtle mismatches that can cause login failures and difficult troubleshooting later.

Make sure the mapping returns a single user DN that has a Delegated Admin role assigned.

5. Verify delegated admin roles

1. Go to Admin › Roles & Permissions to review available roles.
2. Go to Admin › User Management and assign the desired roles (for example, Directory Administrator, Security Administrator, Read Only) to your SSO test users.
3. Only users with at least one Delegated Admin role can access the Control Panel via SSO.

6. Save and test SSO

1. Review all fields in the OIDC section and click Save.
2. Sign out of the Control Panel and start a new session using the Entra ID SSO option.
3. Confirm you are redirected to Microsoft Entra ID, authenticate, and are returned to RadiantOne with admin access according to your assigned role.

Troubleshooting tips

If SSO does not work as expected, check the following:

• The Redirect URI configured in Entra ID exactly matches your Control Panel URL and path for your version.
• The discovery URL and tenant ID are correct and reachable from the RadiantOne deployment.
• The client ID (and client secret for v8.0–v8.1.0) are correctly entered and not expired or rotated.
• Your test user is correctly mapped by the OIDC-to-user mapping and has a Delegated Admin role in RadiantOne.
• Browser cookies and third-party cookies are allowed so the login flow can complete.