Skip to content
Onplana Docs

Configure single sign-on (SSO)

Enterprise planOwner or Admin

Single sign-on lets your team sign in to Onplana with the identity provider your company already uses. Onplana supports both SAML 2.0 and OIDC, with ready-made setups for Google Workspace, Microsoft Entra, and Okta, plus generic Other OIDC and SAML 2.0 options for any other provider.

  • Plans: SSO is included in the Enterprise and Enterprise+ plans.
  • Who configures it in Onplana: an Owner or Admin of the organization.
  • Who configures it in your identity provider: for Microsoft Entra ID, a Cloud Application Administrator, Application Administrator or Global Administrator.
  • SAML sign-in flows: both service provider-initiated (from Onplana) and identity provider-initiated (from a tile such as Microsoft My Apps). Either way, Onplana opens the organization the person signed in to, even when they belong to other organizations too.
  • Single logout: not supported. Signing out of Onplana does not sign you out of your identity provider.

Where to configure it

Section titled “Where to configure it”

  1. Open Apps and integrations in the sidebar (under Settings) and select the SSO tab.

  2. Choose your identity provider from the gallery. Google Workspace, Microsoft Entra, and Okta tiles pre-fill what they can; the generic tiles ask for your provider’s URLs directly.

  3. Enter the credentials from your identity provider’s app settings (OAuth client details for OIDC, or the entry URL and certificate details from your IdP metadata for SAML).

  4. Add your verified domains, the email domains your company owns. Only users with emails on this list can be auto-provisioned.

  5. Switch the Single Sign-On toggle on and save.

Password login remains available after SSO is enabled, so nobody is locked out while you roll it out.

SAML values for your identity provider

Section titled “SAML values for your identity provider”

Onplana gives each organization its own service provider address, built from your organization’s slug. The SSO tab shows the metadata URL (https://api.onplana.com/api/sso/<your-org-slug>/metadata); most identity providers can import it directly. If yours asks for the values one by one:

Setting in your identity provider Value
Identifier (Entity ID) https://api.onplana.com/api/sso/<your-org-slug>
Reply URL (Assertion Consumer Service URL) https://api.onplana.com/api/sso/<your-org-slug>/saml/callback
Sign on URL https://api.onplana.com/api/sso/<your-org-slug>/initiate
Relay State leave empty
Logout URL leave empty
Unique user identifier (Name ID) the person’s email; Microsoft Entra’s default (user principal name) works when it matches the email
Signing sign both the SAML response and the assertion

Onplana reads the email address and display name from the standard claims, including Microsoft Entra’s default claim names, so no claim mapping is needed. If your provider sends them under other names, set them in Advanced: Attribute Mapping on the SSO tab.

From your identity provider, copy three values into Onplana’s SSO tab:

Value in your identity provider Field in Onplana
Login URL (single sign-on URL) IdP Single Sign-On URL
Identifier (issuer); in Microsoft Entra, “Microsoft Entra Identifier” IdP Entity ID (Issuer)
Token signing certificate, Base64 IdP X.509 Certificate

The step-by-step setup for Microsoft Entra ID is in Set up SSO with Microsoft Entra ID below.

Set up SSO with Microsoft Entra ID

Section titled “Set up SSO with Microsoft Entra ID”

  1. In the Microsoft Entra admin center, go to Enterprise apps, select New application, then Create your own application. Name it (for example “Onplana”), choose Integrate any other application you don’t find in the gallery, and create it.

  2. Open the new app’s Single sign-on page and choose SAML.

  3. In Basic SAML Configuration, enter the Identifier, Reply URL and Sign on URL from the table above, using your organization’s slug, and save.

  4. In SAML Certificates, select Edit on the token signing certificate, set Signing Option to Sign SAML response and assertion, and save. Then download Certificate (Base64).

  5. In Set up, copy the Login URL and the Microsoft Entra Identifier.

  6. In Onplana, open Apps and integrations, then SSO, and choose SAML 2.0. Paste the Login URL into IdP Single Sign-On URL, the Microsoft Entra Identifier into IdP Entity ID (Issuer), and the contents of the certificate file into IdP X.509 Certificate. Add your verified email domains, choose the default role, and select Save SSO Configuration.

  7. In Microsoft Entra, open Users and groups on the app and assign the people or groups who should use Onplana.

Test sign-in with a pilot user

Section titled “Test sign-in with a pilot user”

Test with a pilot user assigned to the app before you share the sign-in link with everyone.

  1. From Onplana (service provider-initiated). On the SSO tab select Test SSO Login, or open https://app.onplana.com/login?sso=<your-org-slug> in a private window. You are sent to your identity provider and back into Onplana.

  2. From your identity provider (identity provider-initiated). Sign in to Microsoft My Apps (https://myapps.microsoft.com) as the pilot user and select the Onplana tile, or use Test on the app’s Single sign-on page in Microsoft Entra. You land in Onplana signed in.

  3. Check the pilot user’s role on the People page. Each SSO sign-in is recorded in the audit log as SSO_LOGIN, with the protocol.

Just-in-time provisioning

Section titled “Just-in-time provisioning”

With JIT provisioning on (the default), a person who signs in through your identity provider for the first time gets an Onplana account created automatically, as long as their email domain is on your verified list. People who already have an Onplana account with a matching email simply sign in to their existing account.

You choose the Default role for new SSO users: Member or Portfolio Manager. Admin is deliberately not offered as a default; promote individuals from the People page instead.

If you prefer to control account creation from your IdP rather than at first login, switch JIT provisioning off and use SCIM provisioning or manual invites instead.

Best practices

Section titled “Best practices”
  1. Test SSO with a non-admin account first. A misconfigured SSO can lock you out. Test with a Member account before flipping for the org.
  2. Password login stays available regardless. There is no switch to disable it, so it is always your escape hatch during rollout and prevents lockouts.
  3. Pair SSO with SCIM for full lifecycle. SSO authenticates; SCIM provisions/ deprovisions. Together they automate the whole identity flow. See Provision users with SCIM.
  4. Verify domains before enabling. Adding domains after enable causes user provisioning hiccups. Get the domain list right first.
  5. Document the lost-IdP-access path. If your IdP is down or credentials lost, users sign in with their normal Onplana email and password (plus Forgot password if needed) since it is never disabled.

Troubleshooting / common pitfalls

Section titled “Troubleshooting / common pitfalls”
  • First login fails with signature error. SAML: most IdPs sign only the response, not the assertion. Onplana requires both. Fix IdP signing config.
  • Login succeeds but Onplana shows unauthorized. Email domain not on verified list. Add the domain.
  • JIT provisioned user with wrong role. Default role set incorrectly. Update Default role for new SSO users; future users get the new default.
  • MFA double-prompted (IdP + Onplana). Accept your sign-in provider’s two-step check is off. Turn it on in Organization Settings → Security & Compliance, Sign-in section, then Save changes.
  • Connection test passes but real login fails. Different scope or claim required by IdP for real sign-in vs test. Check IdP logs.

Sign-in messages and what they mean

Section titled “Sign-in messages and what they mean”

If an SSO sign-in fails, Onplana returns the person to the sign-in page with one of these messages:

Message Cause and fix
SSO is not configured for this organization. No SSO configuration is saved for the organization slug in the URL. Check the slug and save the configuration.
The SSO response was invalid. Please try again. The SAML response could not be validated. Check the certificate and the IdP Entity ID in Onplana.
Your identity provider did not share an email address. The assertion carried no email claim. Send the email claim, or map its name under Advanced: Attribute Mapping.
Your email domain is not on this organization’s verified domain list. Add the person’s email domain under Verified email domains.
This organization requires accounts to be provisioned before first SSO sign-in. Just-in-time provisioning is off. Invite the person, provision them with SCIM, or turn JIT on.
SSO sign-in failed. Try again or use your password. Validation failed for another reason; the message shows the detail. “Invalid document signature” means the identity provider signs only the response: set it to sign the response and the assertion.
SSO sign-in failed, with the detail “SsoIdentityMismatch” With Microsoft Entra, Onplana links each person’s account to their Entra object ID at their first SSO sign-in. This message means the email now belongs to a different Entra user than the one the account is linked to, usually a reassigned address. Contact support rather than reusing the address.
That sign-in link has expired or was already used. The one-time sign-in code expired. Start the sign-in again.
Your organization only allows sign-in from approved networks, and this network is not one of them. The organization’s IP allowlist blocks the network the person is on. Connect from an approved network or VPN, or check the allowlist under Security & Compliance.

On the Microsoft Entra side, the app’s Sign-in logs show whether Microsoft Entra issued the token, and Microsoft’s own error codes (such as AADSTS50105, the user is not assigned to the app) appear there.

Get help

Section titled “Get help”

Email support@onplana.com with your organization’s slug, the time of the failed sign-in and the message shown.

How this combines with other features

Section titled “How this combines with other features”

Coming from another tool

Section titled “Coming from another tool”
Tool Mapping
Okta SSO Direct concept
Microsoft Entra ID Direct
Google Workspace SSO Direct
OneLogin Direct
Custom SAML provider Standard SAML 2.0

FAQs

Section titled “FAQs”

Does SSO satisfy our two-factor requirement? It can. If your organization enforces 2FA, SSO sessions where the identity provider performed MFA are accepted by default. See Enforce two-factor authentication.

Can I test the configuration before turning it on? Yes, the SSO tab includes a connection test so you can validate credentials before enabling the toggle for everyone.

What role do SSO users get? The default role you picked, Member unless you chose Portfolio Manager. You can promote individuals afterward from the People page.

We use an IdP that is not in the gallery. Are we stuck? No. Any provider that speaks standard OIDC or SAML 2.0 works through the Other OIDC or SAML 2.0 tiles.

Can I have multiple SSO providers? Today: one IdP per org. For mergers/acquisitions, contact support.

Does SSO sync user attributes (job title, manager, etc.)? Basic attributes (name, email) via SSO. Richer attributes via SCIM provisioning.

What happens if the IdP goes down? Password login always remains available alongside SSO, there is no switch to turn it off, so users sign in with their normal Onplana email and password (and Forgot password if needed) while the IdP is unreachable.

Section titled “Related”