Identity providers
An identity provider is a connection to a corporate directory or single sign-on service that lets your users sign in to DataForge with their existing corporate accounts. Identity providers are managed in Settings → Integrations, on the Identity providers tab.
Purpose and scope
A configured provider adds a corporate sign-in method next to the built-in one: on the sign-in page the user enters their address, picks one of the providers of their company and signs in with their corporate credentials. The built-in email and password sign-in keeps working at the same time — a provider never replaces it.
Key properties:
- A provider belongs to the company of the administrator who created it. Users with the Administrator and Super administrator roles see and manage only their own company's providers
- On the sign-in page an enabled provider is offered only to the users of its own company: the address entered is matched to its DataForge account, and the account's company determines the providers. Providers are not tied to email domains
- Three methods are supported: LDAP / AD (a directory checks the password), SAML / SSO and OAuth2 / OIDC (the browser is redirected to the provider and back)
- Signing in through a provider never creates an account. The DataForge account must already exist in the provider's company — accounts are created only by invitation
- Creating, editing, deleting and testing providers, as well as sign-ins through them, are recorded in the System Journal
Access permissions
| Role | Manage identity providers (view, create, edit, delete, test) | Sign in through a provider |
|---|---|---|
| Super administrator | Yes (own company's providers) | Yes |
| Administrator | Yes (own company's providers) | Yes |
| Other roles (Project manager, Developer, Analyst, Viewer) | No | Yes |
The Integrations page is available only to administrators; users with other roles cannot open it, but they use the configured providers on the sign-in page.
Providers list
The Identity providers tab shows the company's providers as a table:
| Column | Description |
|---|---|
| Display name | Name set by the administrator |
| URL | The directory host for LDAP / AD, or the entity identifier of the provider for SAML / SSO |
| Method | LDAP / AD, SAML / SSO or OAuth2 / OIDC |
| Users | Number of users linked to the provider |
| Last check | Date and time of the last connection test, or — if it has never been run |
| Status | Active, Check failed or Disabled |
| Actions | Edit, test connection and delete buttons |
Above the table there is an Add identity provider button. The table supports sorting and search: Method and Status are filtered by picking a value from a list, the other columns by substring search. The list is paginated.
Provider status
| Status | Meaning |
|---|---|
| Active (green) | The provider is enabled and its last connection test did not fail |
| Check failed (red) | The last connection test failed |
| Disabled (grey) | The Enabled flag is cleared — the provider is not offered on the sign-in page |
The status is not stored as a separate setting: it follows the Enabled flag and the result of the last connection test.
Adding a provider
- Click Add identity provider above the list
- Fill in the common settings, then choose the tab of the method you need — LDAP / AD, SAML / SSO or OAuth2 / OIDC — and fill in its parameters
- For SAML and OAuth2, copy the generated callback URL from the dialog into the settings on the identity provider's side
- Optionally add group mapping rules at the bottom of the dialog
- Click Verify to test the values currently in the form
- Click Save
Only the tab you are on is saved: the dialog stores the parameters of the selected method. Verify and Save stay disabled until the required fields of the selected method are filled in.
Common settings
These fields sit above the method tabs and apply to every method:
| Field | Required | Description |
|---|---|---|
| Display name | Yes | Name of the provider as it appears in the list and on the sign-in page, up to 255 characters |
| Enabled | — | The provider takes part in sign-in. A cleared flag gives the provider the Disabled status |
| Default provider | — | The provider comes first in the list of the company's providers on the sign-in page and is preselected for a user who has not yet signed in through any of them. At most one default provider is allowed per company |
LDAP / Active Directory
The directory checks the user's password directly: DataForge binds with a service account, finds the user's entry and then binds as that user.
| Field | Required | Default | Description |
|---|---|---|---|
| Directory server host | Yes | — | Host name or IP address of the directory server |
| Port | Yes | 389 | Directory server port. Switching Enable SSL (LDAPS) moves it to 636 and back, unless a custom port has been typed |
| Enable SSL (LDAPS) | — | Cleared | Connect over LDAPS instead of plain LDAP |
| Bind DN | Yes | — | Distinguished name of the service account used to search the directory |
| Bind password | Yes | — | Password of the service account. Stored encrypted and never shown again |
| Login attribute | Yes | sAMAccountName |
Attribute the user name is matched against |
| Object class | Yes | person |
Object class the user entry is selected by |
| Email attribute | Yes | mail |
Attribute holding the email address |
| Group attribute | Yes | memberOf |
Attribute holding group memberships |
| First name attribute | Yes | givenName |
Attribute holding the first name |
| Last name attribute | Yes | sn |
Attribute holding the last name |
Microsoft Active Directory, OpenLDAP and other LDAP-compliant directories are supported — for the last two, adjust the attribute names to match the directory's schema.
SAML 2.0 / SSO
The browser is redirected to the identity provider, which returns a signed assertion describing the user.
| Field | Required | Default | Description |
|---|---|---|---|
| SP Entity ID | Yes | Prefilled from the server address | Identifier of DataForge as a Service Provider. Editable — some identity providers require a specific value |
| ACS (callback) URL | — | Generated | Address the assertion is posted back to. Read-only; register it on the identity provider's side |
| IdP metadata source | Yes | XML | XML — the metadata document is pasted into the dialog; URL — the document is fetched from an address |
| Identity provider metadata | Yes | — | The metadata document itself, or the address it is fetched from. A pasted document is formatted automatically and scrolls inside the field |
| NameID format | Yes | Format of the user identifier in the assertion: Email, Persistent, Transient, Unspecified | |
| Group attribute | Yes | group_attr |
Assertion attribute holding group memberships |
| First name attribute | Yes | firstName_attr |
Assertion attribute holding the first name |
| Last name attribute | Yes | lastName_attr |
Assertion attribute holding the last name |
The provider's own entity identifier, sign-on address and signing certificates are read out of the metadata when the provider is saved and when the connection is tested. With the URL source the metadata is also refreshed automatically once it goes stale. Signing out of DataForge stays local — it does not sign the user out of the identity provider.
Providers such as Active Directory Federation Services, Microsoft Entra ID, Okta, PingFederate, OneLogin and any other SAML 2.0 identity provider can be configured this way.
OAuth2 / OpenID Connect
The browser is redirected to the identity provider and comes back with an authorization code, which DataForge exchanges for the user's data.
| Field | Required | Default | Description |
|---|---|---|---|
| Provider type | Yes | Microsoft Entra ID | Preset: Microsoft Entra ID, Google Workspace, Okta, Custom (any other OpenID Connect provider). It affects the default values in the dialog; the sign-in flow is the same for all of them |
| Client ID | Yes | — | Identifier of the application registered on the provider's side |
| Client secret | Yes | — | Secret of that application. Stored encrypted and never shown again |
| Redirect URL | — | Generated | Address the provider returns the browser to. Read-only; register it on the identity provider's side |
| Authorization URL | Yes | — | Provider endpoint the user is sent to |
| Token URL | Yes | — | Provider endpoint the authorization code is exchanged at |
| User info URL | Yes | — | Provider endpoint the user's data is read from |
| Scopes | Yes | openid, profile, email, groups |
Requested scopes. Values can be removed and any other scope typed in; openid is mandatory and carries no remove control |
| Email attribute | Yes | email |
Claim holding the email address |
| Group attribute | Yes | groups |
Claim holding group memberships |
| First name attribute | Yes | given_name |
Claim holding the first name |
| Last name attribute | Yes | family_name |
Claim holding the last name |
Provider endpoints are entered explicitly, so any OpenID Connect compliant provider fits. For the Google Workspace preset, everything group-related — the Group attribute field, the groups scope and the group mapping rows — is disabled and cleared, because that provider issues no group data to an ordinary OpenID Connect client.
Callback URLs
Every provider gets its own permanent identifier, and the ACS (callback) URL and Redirect URL are built from it and from the server's public address. These are DataForge's own routes, so the fields are read-only — select the value and copy it into the settings on the identity provider's side.
- The identifier is issued as soon as the creation dialog opens, so the callback URL can be copied and registered at the identity provider before the provider is saved
- The identifier never changes, so a registration made on the provider's side survives editing the provider, and the same integration can be reproduced in another environment
- Service Provider metadata for the SAML integration is published by DataForge at the same identifier and can be handed to the identity provider instead of filling its settings in by hand
- If the server's public address is not configured, a SAML or OAuth2 provider cannot be created — the dialog reports the reason
Testing the connection
A provider can be tested in two ways:
- With the Verify button in the creation or editing dialog — the values currently in the form are tested and nothing is saved. For a stored provider, an untouched Bind password or Client secret field is substituted with the saved value
- With the test connection button in the list row — the saved settings are used, and the result is written into the provider's Last check and Status
The test runs as a sequence of checks, and a failure names the step that failed:
| Method | Checks |
|---|---|
| LDAP / AD | server connection — the directory is reachable and the TLS handshake succeeds; service account bind — the bind DN and password are accepted; user search — a user entry can be found; attribute extraction — the mapped attributes are present on the entry |
| SAML / SSO | IdP metadata — the metadata document is fetched and parses correctly; signing certificate — the certificate is valid and not expired; ACS URL — the assertion consumer address matches |
| OAuth2 / OIDC | endpoint URLs — the authorization, token and user info addresses are reachable; client credentials — the client ID and secret are accepted; redirect URI — the callback address matches |
The result is shown as a notification: on success "Directory connection successful", on failure "Failed to connect to the directory" followed by the failed step and the reason reported by the provider.
When testing an edited provider you may reuse the stored secret, but not if the Token URL has been changed in the same dialog — a secret must not be sent to a new address.
Group and role mapping
Below the method tabs, the dialog holds a list of Directory group → DataForge role rules, up to 100. Each row pairs a group as the provider reports it with the role that group grants. Use Add group mapping to add a row and the delete button to remove one; half-filled rows are dropped on save.
The role list offers Administrator, Project manager, Developer, Analyst and Viewer. Super administrator is deliberately not offered — an external directory must not be able to grant instance-wide administration.
How the rules are applied on each sign-in:
- The user's group memberships are read from the provider and replace the previously recorded ones
- With no rules configured, the groups are only recorded and every account keeps the role it has in DataForge
- With rules configured, the account's role is brought in line with them. When several groups match, the most privileged role wins, in the order Administrator → Developer → Analyst → Viewer
- If rules are configured and the user belongs to none of the listed groups, the sign-in is refused
- Only direct group membership is taken into account; nested groups are not resolved
What happens to accounts
Provider data is applied on every sign-in, not only the first one:
- The account must already exist in DataForge and belong to the provider's company. A provider sign-in never creates one — the only way to add a user is by invitation
- An account that was invited but never completed its registration is activated by its first successful provider sign-in
- The first and last name are refreshed with the values from the provider. When the provider sends neither, the email address stands in for the name — but only while the account has no name of its own, so a name entered in DataForge is never overwritten
- Corporate passwords are never stored in DataForge. An account that has no DataForge password of its own cannot use the built-in email and password sign-in until it sets one
- After the account is matched, the usual checks apply: the client IP address is verified against the company's IP lists just as it is for the built-in sign-in
Editing a provider
- The method cannot be changed on a stored provider — the other two tabs are disabled. To switch methods, create a new provider
- Stored secrets — Bind password and Client secret — are never shown again. Leaving the field empty keeps the stored value; typing a new value replaces it
- Everything else, including the flags and the group mapping rules, can be changed at any time
Deleting a provider
A provider is deleted from the list through a confirmation dialog, which warns that users who signed in through it will lose that sign-in method. Their DataForge accounts remain — they sign in with another provider or with the built-in email and password, if they have set one.
Audit log entries
Provider configuration changes are recorded in the System Journal under the identity provider management category: adding, editing, deleting and testing a connection. Every changed field is recorded with its old and new value; the service account password and the client secret are marked as changed without revealing their values.
Sign-ins through a provider are recorded under the authentication category, naming the provider and its method: successful sign-ins, failed attempts with their reason, and the account changes made by the mapping — name, role and status — with their old and new values.