Authentication

The Authentication tab in Organization Settings provides security configuration options for your DataStream organization. Administrators can configure Single Sign-On (SSO) with the identity provider your organization already uses, and manage Multi-Factor Authentication (MFA) requirements for all users.

To access authentication settings:

1. Click the hamburger menu on the top left
2. Select Organization > Settings
3. Click the Authentication tab

---

Single Sign-On

Enterprise

Multi-factor authentication is not gated — it is available on every plan.

Single Sign-On lets your users reach DataStream with the accounts they already hold at your identity provider, instead of a separate VirtualMetric password. Your organization is connected to one provider at a time, and DataStream offers four: Microsoft Entra ID, Google Workspace, Okta, and generic OpenID Connect for any other provider that publishes a discovery document — ADFS, Ping, Keycloak, Auth0 and Workspace ONE among them.

Setting up, changing and removing the configuration are governed by the SSO_CREATE, SSO_EDIT and SSO_DELETE permissions on your role.

SSO Configuration

Two things distinguish the providers: the value that identifies your organization to DataStream, and whether your users get a one-click button on the DataStream login page.

Provider	Directory identifier	Login-page button
Microsoft Entra ID	Directory (tenant) ID — the directory (tenant) ID of your Microsoft Entra tenant, such as 00000000-0000-0000-0000-000000000000	Sign in with Microsoft Entra ID
Google Workspace	Workspace domain — your organization's primary Google Workspace domain, such as example.com	Sign in with Google Workspace
Okta	Okta issuer URL — the issuer URL of your Okta authorization server, found under Security > API in the Okta admin console	None
OpenID Connect	Issuer URL — your provider's issuer URL. The endpoints are read from its discovery document, so a client ID and client secret are the only other values asked for	None

Okta and OpenID Connect have no login-page button, and this is permanent rather than pending. A button on the login page is offered to every visitor, so it can only work where one VirtualMetric application serves every organization. VirtualMetric's Okta application has to be registered inside a single Okta organization, so a button would sign in that one organization's users and turn every other Okta customer away. An OpenID Connect provider is whichever one you name, so VirtualMetric has no application registered with it at all. Users of either provider sign in from the login page by entering their work email instead, which sends them to your provider just the same.

note

A Google account that belongs to no Workspace domain is a personal account, and it is refused. Sign-in is matched to the Workspace domain you configure.

Standard and Extended Integration

The Integration setting decides whose application your users' sign-ins run through.

Standard — sign-in runs through VirtualMetric's own registered application, so there is nothing to register on your side. Your users sign in from the login page or by entering their work email. This is the default, and the directory identifier is the only value you supply.

Extended — turn on Extended integration to use your own provider application registration instead of VirtualMetric's. What changes:

• Sign-ins started by entering a work email then run through your application: they appear in your own sign-in logs, are governed by the conditional access policies scoped to it, and stop working if you delete the client secret.
• Sign-ins started from a login-page button still use VirtualMetric's application, so those policies do not apply to them.
• Mapping provider groups to VirtualMetric roles is not available yet, and adding credentials does not enable it.

OpenID Connect is always Extended. It has no Standard mode to switch to: because the issuer is yours to choose, VirtualMetric has no application registered with your provider, so a client ID and secret are always required.

note

Standard integration depends on your directory being connected (see Connect Your Directory), and a directory can be connected for Microsoft Entra ID and Google Workspace. Set Okta up with Extended integration, so its sign-ins run through your own Okta application.

Enable Single Sign-On

1. Navigate to Organization > Settings and open the Authentication tab.
2. In the Single Sign-On section, click Set up Single Sign-On.
3. Under Identity provider, choose the provider your organization already uses. Your users will sign in with the accounts they have there.
4. Enter the directory identifier for that provider — the field is named in the table under SSO Configuration above. For Microsoft Entra ID and Google Workspace you can click Get my tenant ID or Get my domain beside the field and sign in once, rather than finding and pasting the value; see Connect Your Directory.
5. Leave Extended integration off to sign in through VirtualMetric's application, or turn it on to use your own and complete the fields below. OpenID Connect always asks for them.

Field	Description
Redirect URI	The VirtualMetric callback URL, read-only with a copy control. Add this exact URL as a Redirect URI on your application registration
Client ID	The application (client) ID of your own app registration
Client Secret	A client secret generated on your own app registration

6. Click Save. On success, your organization is connected to the provider. With Extended integration your users can sign in straight away. With Standard integration they can sign in once your directory is connected, which is a separate step — see Connect Your Directory.

Registering Your Own Application

These steps apply only when Extended integration is on. With Standard integration there is nothing to register — VirtualMetric's own application is used.

Whichever provider you use, the registration needs the Redirect URI shown in the form added to it exactly as written, and you supply the client ID and client secret it issues.

Microsoft Entra ID — Microsoft Entra ID administrator access required.

1. Register Application

   • Navigate to Azure Portal > Microsoft Entra ID > App registrations
   • Create a new registration
   • Note the Application (client) ID and the Directory (tenant) ID

2. Configure Authentication

   • Add platform configuration for web application
   • Add the Redirect URI shown in the DataStream form
   • Enable ID tokens and access tokens

3. Create Client Secret

   • Navigate to Certificates & secrets
   • Create a new client secret
   • Copy the secret value immediately

Google Workspace — create an OAuth client for your organization in the Google Cloud console, add the Redirect URI to it, and copy the client ID and client secret it issues.

Okta — create an OIDC web application in the Okta admin console and add the Redirect URI to it. Its client ID and client secret go in the form, and the issuer URL of your authorization server, found under Security > API, is the directory identifier.

OpenID Connect — register a confidential client with your provider and add the Redirect URI to it. Only the issuer URL, client ID and client secret are needed: the remaining endpoints are read from your provider's discovery document.

Connect Your Directory

Before your users can sign in from a provider button — Sign in with Microsoft Entra ID or Sign in with Google Workspace — an administrator has to connect your organization's directory. Connecting is a one-time sign-in to the directory from the Authentication tab, using Get my tenant ID or Get my domain beside the directory field, after which DataStream records which directory belongs to your organization and fills the field in for you.

It applies to Microsoft Entra ID and Google Workspace only. Okta and OpenID Connect cannot be connected this way, because connecting runs through VirtualMetric's own application, and for those two providers the value being discovered is the very thing such an application would have to be built against.

Three rules govern who may connect one:

• You must be an administrator of the organization, and you must sign in as yourself. The identity the directory returns has to be your own account.
• A guest of the directory cannot connect it. An Entra ID B2B guest, or an external Microsoft account or Google-federated user, can sign in through a directory that is already connected, but an attempt to connect one fails.
• A directory belongs to one organization at a time. If another organization has already connected the directory, the attempt is refused whatever the state of that organization's SSO settings. Your own organization can reconnect its directory freely.

Once the directory is connected, the section reports Login page buttons as Enabled — your team can sign in with one click; until then it reads Not connected yet — use the button beside the directory field. The buttons also have to be enabled for your DataStream deployment: if the login page offers none at all, ask VirtualMetric to turn them on.

Manage SSO Configuration

Once SSO is enabled, the section reports the SSO Provider, the directory identifier under its own label, the Integration mode as Standard or Extended, the Client ID and Client Secret when the integration is Extended, and whether Login page buttons are enabled, and whether Enforce SSO login is enabled.

Click Manage SSO configuration to enter edit mode, where the identity provider, the directory identifier, the Extended integration toggle and the Enforce SSO login toggle all become editable, along with the client fields when the toggle is on. Apply with Save changes or discard with Cancel.

note

A stored client secret is never shown. Leave Client Secret unchanged to keep it. If you switch to a different identity provider, enter a new secret — the stored one belongs to the application you are leaving.

SSO Enforcement

Administrators with the SSO_EDIT permission can require every user in the organization to sign in through Single Sign-On instead of a password.

1. Navigate to Organization > Settings > Authentication.
2. Click Manage SSO configuration.
3. Turn on Enforce SSO login and click Save changes.

When SSO enforcement is enabled:

• Every user signs in through the identity provider. The password step is skipped for them even if their own Single Sign-On setting is off.
• On the user's own User Details page, the Enable SSO toggle reads Enabled and is locked, with the notice "Single Sign-On is required by your organization"; the Password row is hidden for them.
• Users see SSO enforced on their own Account Settings > Authentication row and cannot turn it off.
• The organization owner is exempt. The owner always keeps password sign-in, so a broken or misconfigured identity provider can never lock the organization out of its own settings. The owner also cannot enable Single Sign-On on their own account.

When SSO enforcement is disabled:

• Each user returns to their own Single Sign-On setting. Enforcement never rewrites that setting.
• Removing the SSO configuration turns enforcement off as well.

note

Turning on enforcement requires SSO to already be configured, and the whole Enforce SSO login control is unavailable on a plan that does not include SSO. If the plan is later downgraded, enforcement stops applying until the plan includes SSO again — though it can still be turned off in the meantime.

note

Enforcement is an organization-level policy layered over each user's stored Single Sign-On preference, not a rewrite of it. As with MFA Enforcement, the identity provider's own policy decides any second factor for an SSO sign-in.

User Access Management

With SSO configured but not enforced, only users whose own Enable SSO toggle is on sign in with the accounts they hold at the configured provider instead of a VirtualMetric password; everyone else keeps their password. With SSO enforcement on, every user signs in through the provider this way, the organization owner excepted. Either way, the provider authenticates them and tells DataStream who they are; their DataStream role and permissions decide what they can then do.

Signing in through your provider does not create accounts. The user has to exist and be active in your DataStream organization already, and an account from a directory your organization has not configured is refused. Roles are assigned in Organization > Users — mapping provider groups to VirtualMetric roles is not available yet.

When SSO is disabled, users must have dedicated VirtualMetric DataStream user accounts with username/password authentication to access the system.

Because the identity provider performs the authentication, DataStream's MFA enforcement and account lockout do not apply to SSO logins — see MFA Enforcement.

Remove Single Sign-On

1. Navigate to Organization > Settings and open the Authentication tab.
2. Click Manage SSO configuration.
3. Click Remove Single Sign-On and confirm.
4. Users revert to VirtualMetric username/password authentication.
5. SSO enforcement, if it was on, turns off as well.

---

Multi-Factor Authentication (MFA)

The Multi-Factor Authentication section allows administrators to configure MFA requirements for all users in the organization. MFA adds an extra layer of security by requiring users to verify their identity using a second factor beyond their password.

MFA Methods

DataStream supports two MFA methods:

Method	Description
Email	Users authenticate with a security passcode sent by email. The UI notes this factor offers a low level of security.
TOTP	Users authenticate with a time-based one-time passcode from an authenticator app (such as Google Authenticator, Microsoft Authenticator, or Authy). The UI notes this factor offers a medium level of security.

Configure Organization MFA Settings

Administrators with the MFA_EDIT permission can configure which MFA methods are available to users and whether MFA is enforced organization-wide.

1. Navigate to Organization > Settings > Authentication
2. In the Multi-Factor Authentication (MFA) section, click Manage MFA configuration
3. Under Authentication Methods, select the allowed MFA methods:
   • Email - Enable email-based passcodes
   • TOTP - Enable time-based one-time passcodes from an authenticator app
4. Under Enforce Multi-Factor Authentication, configure enforcement:
   • Enable the Enforce MFA toggle to require all users to set up MFA
   • When enforcement is enabled, users must configure MFA on their next login
5. Click Save changes

warning

Removing an MFA method that users have already configured will require those users to set up a new method on their next login.

note

At least one MFA method must be selected. You cannot save the configuration with no methods enabled.

MFA Enforcement

When MFA enforcement is enabled:

• Users who have not configured MFA will be prompted to set it up on their next login
• Users must complete MFA setup before accessing DataStream
• The setup wizard guides users through method selection, verification, and backup code generation

When MFA enforcement is disabled:

• MFA setup becomes optional for users
• Users can enable or disable MFA from their Account Settings
• Existing MFA configurations remain active

important

Disabling MFA enforcement does not disable MFA for users who have already configured it. Users retain their existing MFA settings and can manage them through Account Settings.

note

MFA enforcement applies to password logins. A user who signs in through single sign-on is authenticated by the identity provider, whose MFA and conditional access policy determines whether a second factor is required, and DataStream does not add a challenge of its own. Account lockout works the same way: the lockout counters track failed passwords and passcodes, and an SSO login submits neither.

A user who can sign in both ways is covered by DataStream MFA only when they use their password. To require MFA for users signing in through SSO, configure it in the identity provider — Entra ID conditional access, Google 2-Step Verification enforcement, or an Okta sign-on policy.

User MFA Setup

The following flows take place in the user's own sign-in and Account Settings surfaces, not in the Organization > Settings tab.

When MFA is enforced or when users choose to enable MFA, the setup process includes:

1. Method Selection - Choose between Email or TOTP (based on organization-allowed methods)
2. Verification - Complete initial verification:
   • For Email: Click Send to receive a code, then enter the code
   • For TOTP: Scan the QR code with your authenticator app, then enter the code
3. Backup Codes - Save the generated backup codes for account recovery

Backup Codes

After MFA setup, users receive a set of backup codes. These single-use codes allow account access if the primary MFA method is unavailable.

• Backup codes are displayed once during setup and can be copied or downloaded as a text file
• Each code can only be used once
• Users can reset their backup codes from Account Settings, which invalidates all previous codes

warning

Using a backup code triggers a mandatory MFA re-setup. Users must configure a new MFA method immediately after using a backup code to sign in.

MFA Challenge at Login

When a user with MFA enabled signs in, they are prompted to verify their identity:

• Email method: Enter the code sent to the registered email
• TOTP method: Enter the current code from the authenticator app
• Fallback options: If the primary method is unavailable, users can request an email code or use a backup code

note

An email code requested as a fallback is invalidated after five incorrect entries, and a new one can be requested every two minutes. Incorrect codes — a login code, a backup code, or a fallback code — count towards the same account lock as incorrect passwords.

User MFA Management

Individual users can manage their MFA settings from Account Settings > Authentication:

• Enable/Disable MFA - Turn MFA on or off for their account (when not enforced)
• Change Method - Switch between Email and TOTP
• Reset Backup Codes - Generate new backup codes (invalidates previous codes)