See also: SSO (Single Sign-On)
This guide walks you through a complete Azure SSO setup. You or your system administrator collects values from the Microsoft Azure portal. You enter them in the Lobster Data Platform. Furthermore, you test and activate the configuration.
SSO uses OAuth2/OpenID Connect to authenticate users via an external identity provider. This example uses Microsoft Azure (Entra ID).
Requirements
An app registration exists in your Azure tenant.
You have admin access to the Microsoft Azure portal.
You have the
Createpermission for "SSO System Preferences" in Lobster Data Platform.
Step 1: Collect values from the Microsoft Azure portal
Open your app registration in the Microsoft Azure portal. Note these three values:
Azure portal location | LDP field it maps to |
|---|---|
Overview → Directory (tenant) ID | Tenant |
Overview → Application (client) ID | Client ID |
Certificates & secrets → Client secrets → Value | Client Secret |
IMPORTANT Copy the client secret value immediately
Azure shows the client secret value only once, right after you create it. If you navigate away, the value is masked permanently. You then need to create a new secret.
Step 2: Create a new "SSO System Preferences" entry
In Lobster Data Platform, open Authentication (see Base settings). Click the "SSO (Single Sign-On)" tab. Click New.
In the SSO Provider field, select Azure SSO. Azure-specific fields appear.
WARNING
Do not change the SSO Provider after entering data. Any values you already entered are lost. This is true even if the other provider supports the same fields.
Fill in the fields:
Field | Example value | Note |
|---|---|---|
Alias |
| Unique identifier. Used as |
Status | inactive (for now) | Set to active after testing (Step 6). |
Client ID | from Step 1 | |
Client Secret | from Step 1 | IMPORTANT Keep this confidential. |
Tenant | from Step 1 | Azure-specific field. |
Authorization URL |
| Leave empty to use the default. |
Token URL |
| Leave empty to use the default. |
User Info URL |
| Leave empty to use the default. |
Scope |
| Standard claims for user identification. |
Callback URL | auto-generated | Read-only. Needed for Step 3. |
NOTE The placeholder texts in empty fields describe the system defaults. Defaults apply at runtime as long as the field stays empty. The defaults are not stored in the database.
Save the entry.
Step 3: Register the Callback URL in Azure
Copy the Callback URL from the LDP detail view with the copy button next to the field.
Go back to your Azure app registration.
Open Authentication.
Add the Callback URL as a Redirect URI of type Web.
Save.
Step 4: Test the connection
Select the new "SSO System Preferences" entry in the overview. Click Test SSO. A separate browser window opens. Sign in with an Azure account.
On success, you see a success notification.
On failure, an error message with details appears in the test window.
NOTE The "Status" setting is ignored during the test. You can test inactive configurations.
If the test fails, see How to debug SSO token claims.
Step 5: Map LDP users to Azure identities
SSO works only if an active Users references the Azure identity.
For each user who logs in via Azure SSO:
Open the user record in Users.
Go to "External user login infos".
Add an entry with these values:
Provider Alias:
azure(must match the Alias from Step 2)User term: the Azure identifier of the user, typically the e-mail address
NOTE User mapping must be done manually
Automatic provisioning is not available. SCIM and JIT provisioning are not supported. You must map each Azure identity to an LDP user account by hand.
For options, see User management with SSO.
Step 6: Activate the configuration
In the detail view, set Status to active. Save the entry.
The Azure SSO button now appears in the login dialog for mapped users.
Related topics
Field mappings: syntax and claims. Map Azure token claims to LDP user attributes.
How to debug SSO token claims. Inspect the Azure token and verify the claims.
User management with SSO. Options for user mapping and self-registration.