Single sign-on

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.

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:

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:

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.