Cloud SSO with Valsight ID

SSO configuration is a paid add-on for the Teams edition, and is included in the Corporate and Enterprise editions. If you are unsure which edition your organization has, ask your Valsight contact.

Goal

Your users sign in to your Valsight cloud instance with their existing company account, through your own identity provider.

In the cloud, that connection is made through Valsight ID (id.valsight.com) — the central identity service that Valsight products trust. Your identity provider talks to Valsight ID, and Valsight ID vouches for the user to your instance. You register one application in your IdP and hand Valsight the connection details; Valsight sets up the connection.

Looking for the on-premise SSO configuration? This page is the cloud path. If you run Valsight on your own servers, the configuration lives on your instance instead — see OpenID Connect under On-Premise Installation.

Prerequisites

• A Valsight account with administrator permissions
• Network access to your Valsight instance

Steps

1. 1. Register an application in your identity provider

   Create a new application, app registration or client for Valsight, using the authorization code flow. Confidential clients are supported and preferred: Valsight ID keeps the client secret.

2. 2. Add the redirect URL

   Your IdP will only send users back to an address you have allow-listed. There is exactly one for the cloud:

   https://id.valsight.com/idps/callback

   That is the same URL for every cloud customer and every Valsight cloud region — it belongs to Valsight ID, not to your instance. You do not need to register anything that contains your own instance hostname.

3. 3. Make sure the required claims are present

   Two claims are mandatory for every OpenID Connect connection. Without them Valsight cannot identify the user, and sign-in fails:

   Claim	Why it is needed
   email	Identifies the user. Valsight uses the email address as the username.
   email_verified	Valsight only accepts an address your IdP states it has verified.

   Optionally, you can also send group memberships. Valsight can use them to control who is allowed in and what they may see:

   Claim	Purpose
   groups	Group memberships, for restricting access or mapping to Valsight roles. Tell your Valsight contact which group names to expect.

   For Microsoft Entra ID, the group claim is not sent by default. Add it under App registration → Token configuration → Add groups claim, and choose the group types you want Valsight to see.

   Do not follow Entra / AAD Configuration for a cloud instance. That page documents the direct-to-instance setup, with callback URLs containing your own instance hostname. On the cloud path the only redirect URL is the Valsight ID one in step 2.

4. 4. Send Valsight the connection details

   What Valsight needs depends on your provider.

   Microsoft Entra ID

   Value	Where it is in Entra
   Application (client) ID	App registration → Overview
   Client secret	App registration → Certificates & secrets
   Directory (tenant) ID	App registration → Overview

   Any other OpenID Connect provider

   Value	Notes
   Client ID	From the application you created in step 1.
   Client secret	n/a for a public client; say so if your provider issues none.
   Issuer URL	The iss value your provider puts in its tokens.
   Authorization URL	Where users are sent to sign in.
   Token URL	Where the authorization code is exchanged.
   JWK URL	Where Valsight ID fetches your signing keys.

   Many providers publish the last four at a discovery document under /.well-known/openid-configuration. If yours does, sending that one URL is enough.

   Send the secret through a channel you consider appropriate for a credential — ask your Valsight contact for a secure upload rather than putting it in an email body.

5. 5. Tell Valsight which email domains to expect

   Users sign in with their email address, and Valsight ID works out which organization they belong to from the domain part of it. So every email domain your users sign in with has to be registered on your organization — for example example.com and example.de if both are in use.

   List the domains together with the details from step 4.

6. 6. Optionally, name a logout URL

   By default, signing out of Valsight ends only the Valsight session. If you want users returned to your own logout page, provide that URL as well.

Verify

Valsight sets up the connection and then tests it with you. Two things are worth knowing about how that goes, because they are deliberate:

• The connection is inactive at first. It exists, but it is not yet offered on the sign-in screen. That way a wrong issuer or a broken mapping cannot lock anyone out while it is being sorted out.
• Password sign-in stays available alongside it. Your users can keep signing in as before while the new route is proven. Switching password sign-in off is a separate, later step, and it is only done once someone has actually signed in successfully through your provider.

You are done when all of these hold:

• The sign-in screen for your instance offers your organization’s identity provider.
• Signing in through it lands you in Valsight as yourself, with your email address shown in the user menu.
• A colleague who is not in a permitted group is refused, if you asked for group-based restrictions.
• Signing out behaves as you expect — Valsight session only, or a redirect to your logout URL.

If sign-in fails, the message on the screen names the reason. Send it to your Valsight contact: the most common causes are a missing email_verified claim, an email domain that was not on the list in step 5, and a redirect URL that does not match step 2 exactly.

SAML 2.0

OpenID Connect is the recommended protocol, and the rest of this page assumes it. SAML 2.0 is supported as well.

The difference for you is that the two URLs your IdP needs contain a connection id, which Valsight can only give you once the connection has been created on the Valsight ID side. So the order is reversed: ask your Valsight contact for the connection first, then configure your IdP with what they send back.

Everything else on this page applies unchanged: the same required attributes, the same email-domain registration, and the same inactive-first rollout.

Related