Configure single sign-on (SSO)

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.

Where to configure it

1. Open Integrations from the sidebar 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.

Caution

For SAML, Onplana requires both the SAML response and the assertion to be signed by your identity provider. Most IdPs sign only the response by default, which makes the first login fail with a signature error. Check your IdP’s signing option before testing.

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

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. Keep password login on during rollout. Don’t disable password until SSO is proven for all users. The escape hatch 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, how do users sign in? Password fallback
   • admin recovery email are the answer.

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). Trust IdP MFA option off. Turn it on.
• Connection test passes but real login fails. Different scope or claim required by IdP for real sign-in vs test. Check IdP logs.

How this combines with other features

• SSO + SCIM. SSO authenticates; SCIM provisions/deprovisions. The full lifecycle pair. See Provision users with SCIM.
• SSO + 2FA. IdP MFA satisfies Onplana’s 2FA requirement when Trust IdP MFA is on. See Enforce two-factor authentication.
• SSO + Session management. SSO sessions follow the same idle timeout
  • revocation rules. See Manage sessions and devices.
• SSO + Audit log. SSO logins write to audit log. See Read audit logs.

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

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 fallback (if enabled) lets users sign in. Plan for IdP outage with password fallback configured.

Related

• Provision users with SCIM — lifecycle pair
• Enforce two-factor authentication — IdP MFA delegation
• Manage sessions and devices — SSO session policies