# Single sign-on

> Let your team sign in to Delsivo through your identity provider with OpenID Connect or SAML 2.0, test it safely, then require it for your email domain.

Source: https://delsivo.com/help/team-and-settings/single-sign-on · Updated 2026-11-07

## Key takeaways

- A fund Admin sets up single sign-on in Settings, Security, with OpenID Connect (issuer URL, client id and client secret) or SAML 2.0 (your identity provider's metadata XML), plus your email domain.
- For SAML, give your identity provider the ACS URL and entity ID shown on the card, then paste its metadata back into Delsivo.
- Single sign-on can be turned on only after your domain is verified and a test sign-in passes with the saved settings, so a typo can't lock your team out.
- Requiring single sign-on stops members of your fund on that email domain from signing in with a password. Delsivo staff and people outside your fund are never affected.
- Single sign-on never creates accounts. People still join your fund by invitation.

Single sign-on lets your team sign in with the same account they use for email and everything else at your fund. When someone leaves, turning off their account at your identity provider also stops them signing in to Delsivo. Only an **Admin** can set it up, in **Settings → Security → Single sign-on**.

The card shows five steps: **Save settings**, **Verify your domain**, **Test sign-in**, **Turn on** and **Require for your domain**.

## OpenID Connect or SAML 2.0

Both work with Okta, Microsoft Entra ID and Google Workspace. Pick the one your IT team prefers:

- **OpenID Connect** is quicker to set up: an issuer URL, a client id and a client secret.
- **SAML 2.0** suits identity providers that only offer SAML (ADFS, some OneLogin and PingFederate setups) and teams that already run their apps on SAML.

Choose it under **Protocol** on the card. You can switch later; switching saves as a new draft that needs a new test.

## Set up with OpenID Connect

### Create the app at your identity provider

Create an OpenID Connect web application (sometimes called an "OIDC app" or "app registration") at your identity provider:

1. Set the **redirect URI** to the one shown on the card under **Redirect URI** (copy it with **Copy**).
2. Allow the scopes **openid**, **email** and **profile**.
3. Assign the app to the people on your team.
4. Note the **issuer URL**, the **client id** and the **client secret**.

| Identity provider | Where to find the issuer URL |
|---|---|
| Okta | Your Okta domain, for example `https://yourfund.okta.com` |
| Microsoft Entra ID | `https://login.microsoftonline.com/<tenant id>/v2.0` |
| Google Workspace | `https://accounts.google.com` |

### Save the settings

1. Open **Settings → Security**.
2. Under **Single sign-on**, leave **Protocol** as **OpenID Connect**.
3. Enter your **Email domain** (for example `yourfund.com`), the **Issuer URL**, the **Client id** and the **Client secret**.
4. Click **Save draft**.

The client secret is stored encrypted and is never shown again. To change it, type a new one; leave the field blank to keep the saved one.

## Set up with SAML 2.0

### What to give your identity provider

Set **Protocol** to **SAML 2.0**. The card shows **Give these to your identity provider**, each with a **Copy** button:

| On the card | What it is |
|---|---|
| **ACS URL** | Where your identity provider sends people back after they sign in (the assertion consumer service) |
| **Entity ID** | Delsivo's identifier for your fund, also called the audience |
| **Metadata URL** | Delsivo's SAML metadata, for identity providers that can import it instead |

Each fund has its own entity ID, so a response meant for another fund's app is refused.

### Create the app at your identity provider

**Okta**

1. In the Okta Admin Console, go to **Applications → Create App Integration** and choose **SAML 2.0**.
2. Set **Single sign-on URL** to the **ACS URL**, and leave **Use this for Recipient URL and Destination URL** ticked.
3. Set **Audience URI (SP Entity ID)** to the **Entity ID**.
4. Set **Name ID format** to **EmailAddress** and **Application username** to **Email**.
5. Finish, assign the app to your team, then open the app's **Sign On** tab and copy the identity provider metadata (open the **Metadata URL** there and copy the XML it shows).

**Microsoft Entra ID**

1. In the Entra admin center, go to **Enterprise applications → New application → Create your own application**, name it Delsivo and choose the non-gallery option.
2. Open **Single sign-on** and choose **SAML**.
3. Under **Basic SAML Configuration**, set **Identifier (Entity ID)** to the **Entity ID** and **Reply URL** to the **ACS URL**. Set **Sign on URL** to `https://app.delsivo.com/sign-in/sso`, so opening the app from My Apps starts the sign-in from Delsivo.
4. Under **Attributes & Claims**, make sure the email address is sent: either as the **Unique User Identifier** (Name ID) in email format, or as the **emailaddress** claim (the default).
5. Under **SAML Certificates**, download **Federation Metadata XML**.
6. Under **Users and groups**, assign the people on your team.

**Google Workspace**

1. In the Google Admin console, go to **Apps → Web and mobile apps → Add app → Add custom SAML app** and name it Delsivo.
2. On **Google Identity Provider details**, click **Download metadata**.
3. On **Service provider details**, set **ACS URL** to the **ACS URL** and **Entity ID** to the **Entity ID**. Set **Name ID format** to **EMAIL** and **Name ID** to **Basic Information > Primary email**. If you want a start URL, use `https://app.delsivo.com/sign-in/sso`.
4. Finish, then turn the app on for the people who need it under **User access**.

Whatever your identity provider, check that:

- The response, the assertion, or both are **signed with SHA-256**. SHA-1 signatures are refused.
- **Signed requests** are not required (Delsivo doesn't sign its requests), and **assertion encryption** is off.
- The person's **email address** is sent as the Name ID or as an email attribute (`email`, `mail` or Entra ID's `emailaddress` claim).

### Save the settings

1. Under **Single sign-on**, set **Protocol** to **SAML 2.0**.
2. Enter your **Email domain** (for example `yourfund.com`).
3. Paste the whole metadata file into **Identity provider metadata (XML)**.
4. Click **Save draft**.

Delsivo reads your identity provider's entity ID, its sign-in address and its signing certificates from the metadata, and shows them under **Saved identity provider** with each certificate's expiry date. Paste the XML itself: Delsivo doesn't download metadata from an address, so if your identity provider gives you a URL, open it in your browser and copy what it shows. Metadata that asks for signed requests, has no https sign-in address or only has expired certificates is refused with a message saying why.

### Sign-in starts from Delsivo

People sign in from **Sign in with single sign-on** on the Delsivo sign-in page. Opening Delsivo straight from your identity provider's app list (an identity provider initiated sign-in) is refused with **That sign-in didn't start here**, because Delsivo only accepts an answer to a sign-in it started. Where your identity provider allows it, point the app's sign-on or start URL at `https://app.delsivo.com/sign-in/sso`, as in the Entra ID and Google Workspace steps above.

### When your identity provider changes its certificate

Identity providers replace their signing certificate every year or few years. When yours does, download the new metadata (it can hold the old and new certificates together), paste it and click **Save draft**, then test and turn single sign-on on again. Saving puts single sign-on back to **Draft** with the requirement off until then, so do it at a quiet moment. The card marks a certificate that has expired.

## The email domain

The **Email domain** is where single sign-on applies: members of your fund whose email is on it. Shared mailbox domains such as gmail.com can't be used.

Saving any change puts single sign-on back to **Draft** and turns the requirement off until you test again. That way a wrong setting can't stop anyone signing in.

## Verify your domain

Once the settings are saved, the card shows a TXT record: a **Name** (`_delsivo.yourfund.com`) and a **Value** (starting `tr-sso=`). Add it at your DNS host, then click **Check domain**. When two public DNS services both see it, the step shows **Verified**. DNS changes can take up to an hour; if only one service sees it yet, check again soon.

This proves your fund controls the domain, so no one else on Delsivo can turn on single sign-on for it. You can remove the record after single sign-on is on. Saving a different domain needs a new check.

## Run a test sign-in

Click **Test sign-in**. You're sent to your identity provider; sign in there with your own account. You come back to **Settings → Security** with the result:

| Result | What it means |
|---|---|
| **Test passed** | The identity provider signed you in, its answer checked out, and your email is on your domain |
| **The identity provider signed in an address outside your email domain.** | You signed in at the identity provider with another account, or the email domain is wrong |
| **The identity provider refused the code.** | OpenID Connect: check the client id, client secret and redirect URI |
| **We couldn't read the issuer's OpenID configuration.** | OpenID Connect: check the issuer URL. It must start with https:// |
| **The identity provider didn't send an email address.** | Add the email scope or claim (OpenID Connect), or send the email as the Name ID or an email attribute (SAML) |
| **The SAML response wasn't signed by a certificate in your metadata.** | The response was unsigned, or your identity provider changed its certificate. Paste fresh metadata |
| **The SAML response was signed with SHA-1.** | Set the signature algorithm to SHA-256 at your identity provider |
| **The SAML response was for another app.** | Set the entity ID (audience) at your identity provider to the **Entity ID** on the card |
| **The SAML response was sent for another address.** | Set the ACS URL (Okta: Single sign-on URL; Entra ID: Reply URL) to the **ACS URL** on the card |
| **The SAML response had expired or wasn't valid yet.** | Your identity provider's clock is off by more than a minute, or the sign-in took too long. Try again |
| **The SAML response didn't answer this sign-in.** | Start the test from Delsivo, not from your identity provider's app list |

A passed test applies to the exact settings you saved. If you change anything afterwards, including pasting new metadata, test again.

## Turn it on

Click **Turn on** (it needs a verified domain and a passed test). Members of your fund whose email is on your domain can now click **Sign in with single sign-on** on the sign-in page. Passwords still work too.

Someone who is also on another fund's team on Delsivo (a committee member or co-investor from another firm, say) always signs in with their password and two-step sign-in, never through your identity provider: a Delsivo sign-in opens every fund the person belongs to.

If another fund on Delsivo already uses single sign-on for the same domain, you see a message asking you to contact support.

## Require it for your domain (optional)

Switch on **Require single sign-on for @yourdomain** and confirm. From then on:

- Members of your fund on that domain can't sign in with a password. They see **… signs you in with single sign-on. Choose Sign in with single sign-on instead.**
- Their open sessions on other devices are signed out, except yours, so everyone comes back through your identity provider.
- People on your team with an email on another domain (an adviser, a venture partner using their own address) keep signing in with their password.
- People who are also on another fund's team keep signing in with their password and two-step sign-in.
- Delsivo staff are never affected.

Switch it off at any time and passwords work again straight away.

## Turn single sign-on off

Click **Turn off** and confirm. Everyone signs in with their password again. Your settings are kept, so you can turn it back on later without testing again if nothing changed. Members who never had a password can set one with **Forgot it?** on the sign-in page.

## What gets recorded

Every step is in your activity log under **Team and sign-in**: settings saved, tests passed and failed, turned on and off, required and not required, and each single sign-on sign-in. The client secret, SAML responses and email addresses from your identity provider never appear there.

## Frequently asked questions

### Does single sign-on create accounts for new people?
No. Invite people from **Settings → Team and roles** as usual. Once they've accepted, they can sign in with single sign-on.

### What about two-step sign-in?
Your identity provider handles it. When someone signs in with single sign-on, Delsivo doesn't ask for its own 6-digit code.

### Our identity provider is down. How do we get in?
An Admin can switch off **Require single sign-on** if they can still sign in. If nobody can, email hello@delsivo.com: Delsivo support can turn the requirement off for your fund so passwords work again. That change is recorded in your activity log.

### Can people open Delsivo from our identity provider's app list?
Not directly with SAML: Delsivo accepts only answers to sign-ins it started, which protects against forged or replayed sign-ins. Set the app's sign-on or start URL to `https://app.delsivo.com/sign-in/sso` where your identity provider allows it.

### Do you support encrypted assertions or single logout?
Not yet. Leave assertion encryption off; the connection to Delsivo is encrypted with https. Signing out of Delsivo doesn't sign you out of your identity provider, and the other way round.