Single Sign-On

Your team can sign in to the Datafly Signal management console with your organisation’s identity provider instead of a separate password. Datafly Signal supports two protocols:

• SAML 2.0: Microsoft Entra ID, Okta, Google Workspace, ADFS, OneLogin, PingFederate and any other SAML 2.0 identity provider.
• OpenID Connect: Google Workspace, Microsoft Entra ID, Okta, Auth0, Keycloak and any other OIDC provider.

Each organisation has one SSO connection. Whichever protocol you choose, the same rules apply:

• Email domains. Only users whose email domain is on the connection’s allowed list can sign in with SSO. A cluster administrator approves each domain for your organisation before it can be used, so one organisation can never claim another’s domain. On a customer-hosted installation, the admin created at install time is the cluster administrator: approve your domains under Settings → SSO → Approved SSO domains.
• Automatic accounts. A user’s first SSO sign-in creates their account with the default role you choose. Organisation Admin is never granted automatically.
• Require SSO (optional). Refuses password sign-in for your allowed domains. Organisation admins can always sign in with a password, so a misconfigured identity provider cannot lock you out.

Microsoft Entra ID (SAML 2.0)

1. Create the enterprise application

1. In Datafly Signal, open Settings → SSO, choose SAML 2.0 and Microsoft Entra ID. Keep this page open: it shows the values you need next.
2. In the Microsoft Entra admin center, go to Enterprise applications → New application → Create your own application. Name it (for example “Datafly Signal”), choose Integrate any other application you don’t find in the gallery (Non-gallery) and create it.
3. Open Single sign-on and choose SAML.
4. Under Basic SAML Configuration, select Edit and enter the two values from the Datafly Signal settings page:

Leave Sign on URL, Relay State and Logout URL empty, and save.

5. Leave Attributes & Claims at the defaults. Datafly Signal reads the email address from the emailaddress claim, falling back to the name claim (the user principal name). If some of your users have no mailbox, make sure the user principal name is their email address.
6. Under Users and groups, assign the users or groups who should have access. Unassigned users are refused by Entra ID.

2. Connect Datafly Signal

1. In the enterprise application’s SAML Certificates section, copy the App Federation Metadata Url.
2. Paste it into Identity provider metadata on the Datafly Signal settings page.
3. Add your email domains, choose the default role for new users, and save.

Datafly Signal reads the metadata at every sign-in, so when Entra ID rotates its signing certificate you do not need to change anything.

3. Test, then enable

Select Test sign-in. A window opens at Entra ID. After you sign in, the settings page shows the email address Entra ID sent and whether its domain is allowed. The test works while SSO is still disabled, and it never creates an account.

When the test succeeds, tick Enable SSO sign-in and save. Users then choose Continue with SSO on the login page and enter their work email.

Other SAML 2.0 identity providers

Create a SAML 2.0 application in your identity provider with:

• Entity ID / Audience: the Identifier (Entity ID) from the settings page.
• ACS / Reply URL: the Reply URL, using the HTTP-POST binding.
• NameID or an email attribute: the user’s email address. Datafly Signal accepts email, mail, emailAddress, the emailaddress claim URI or the LDAP mail OID, and falls back to the NameID when it is an email address.
• Signing: sign the response or the assertion. Unsigned assertions are refused.

Some identity providers can import the service-provider metadata directly from the Service-provider metadata URL shown on the settings page.

Then give Datafly Signal your identity provider’s metadata URL (or paste its metadata XML), add your email domains and save.

How SAML sign-in is secured

• Sign-in always starts from the Datafly Signal login page (service-provider initiated). Each sign-in attempt is single-use and expires after ten minutes, and the identity provider’s response must answer that exact request. Responses sent without a matching request (identity-provider initiated sign-in) are refused.
• The response must be signed by a certificate in your identity provider’s metadata, be addressed to this deployment, and be inside its validity window.
• Signed-in users are subject to the same domain, role and Require SSO rules as OpenID Connect.

OpenID Connect

Choose OpenID Connect and your provider on the settings page, then:

1. Register an application in your identity provider with the Redirect URI shown on the settings page.
2. Enter the issuer (Google needs none; Entra ID needs your tenant ID; Okta needs your Okta domain; Custom needs the issuer URL), the client ID and the client secret.
3. Add your email domains, choose the default role, save, run Test sign-in, then enable.

The client secret is stored encrypted and never shown again. Leave the field blank when saving to keep the stored secret.

Troubleshooting