Setting Up SSO and SCIM in Onplana: A Step-by-Step Guide for Okta, Entra ID, and Google Workspace

Most enterprise PM tools list SSO as a feature. Fewer have complete SCIM support. Fewer still have correct SCIM support: specifically, a per-tenant deactivation model where your offboarding event removes the user from your org only, rather than locking them out of every organization in the system they happen to belong to.

Onplana SSO and SCIM are built around the per-tenant model. SAML 2.0 with certificate validation, OIDC with explicit email_verified gating, JIT provisioning restricted to DNS-verified domains, and SCIM 2.0 deprovisioning that touches your org and nothing else. This guide covers the setup steps for each across the three most common identity providers.

TL;DR: Onplana SSO (SAML 2.0 and OIDC) and SCIM 2.0 are both available on the ENTERPRISE plan. Supported IDPs include Okta, Microsoft Entra ID (Azure AD), and Google Workspace. JIT provisioning is gated to DNS-verified domains with MEMBER as the default role. Per-tenant SCIM deactivation means your deprovisioning events affect only your org's membership.

What SSO and SCIM Actually Do (and Why You Need Both)

SSO lets users authenticate to Onplana with their existing corporate credentials. When someone logs in via Okta, Entra ID, or Google Workspace, the identity provider asserts who they are, and Onplana trusts that assertion. Users do not manage a separate Onplana password, and your IT team controls access centrally through the identity provider.

SCIM adds automated provisioning and deprovisioning. Without SCIM, even with SSO enabled, someone needs to create user accounts manually before first login, unless JIT provisioning handles new users automatically. With SCIM, your identity provider pushes user lifecycle events directly to Onplana: new hire joins Okta, Onplana creates the account. Employee offboards, Onplana deactivates the membership within minutes.

The combination is what most enterprise security teams require for compliance. SSO without SCIM means a deactivated corporate account does not automatically revoke Onplana access. SCIM without SSO still requires users to manage a separate credential. Together, the corporate identity becomes the single credential, and the IdP drives the full access lifecycle.

For a comprehensive view of Onplana's full security architecture, including session policy, 2FA enforcement, audit logging, and data retention, see the security and compliance overview.

Who Gets Onplana SSO and SCIM

SSO (SAML 2.0 and OIDC) and SCIM 2.0 are available on the ENTERPRISE plan. Social sign-in via Google and Microsoft OAuth is available on STARTER and above, which is sufficient for many smaller teams. Password-based login is available across all plans.

Organizations that need SSO for compliance reasons (SOC 2, HIPAA, FINRA, ISO 27001) or that have federated identity requirements from their security team will need ENTERPRISE. For the full tier comparison, see the Onplana pricing page.

Configuring SAML 2.0 SSO

SAML 2.0 is the protocol most enterprise IDPs default to for SaaS integrations. The diagram below shows the authentication flow. One implementation detail worth knowing: Onplana issues a one-time exchange code in the response rather than returning the JWT directly in the redirect URL. This keeps the session token out of browser history, reverse-proxy logs, and the Referer header.

Configure SAML 2.0 SSO with these steps:

1. Open Org Settings → Security & Compliance → SSO in your Onplana admin panel.
2. Select SAML 2.0 as the authentication protocol.
3. Copy the ACS (Assertion Consumer Service) URL and the SP Entity ID from the Onplana SAML configuration screen.
4. Create a SAML application in your identity provider:
   • Okta: Applications → Create App Integration → SAML 2.0
   • Entra ID: Enterprise Applications → New Application → Create your own application (non-gallery)
   • Google Workspace: Apps → SAML Apps → Add App → Add custom SAML app
5. In the IdP SAML application, paste the ACS URL as the Reply URL or ACS URL and the SP Entity ID as the Identifier or Entity ID.
6. Set the Name ID format to emailAddress. Transient or persistent formats require additional Onplana configuration.
7. Map the email attribute so the SAML assertion includes the user's email address in the subject or as a named attribute called email.
8. Download or copy the IdP metadata: the SSO URL, Entity ID, and signing certificate.
9. Return to Onplana and enter the IdP metadata (or paste a metadata XML URL) into the SAML configuration form. Save.
10. Add at least one verified domain in Org Settings → Domains. JIT provisioning creates accounts only for email addresses on domains your org has verified via DNS TXT record.
11. Test with a pilot user before enabling SSO enforcement. Log in via the SSO option and confirm a LOGIN_SSO event appears in the audit log.

To enforce SSO and disable password login for all org members, toggle Require SSO login in the Security & Compliance panel after the pilot confirms the flow works end to end.

For Microsoft's official documentation on configuring SAML-based SSO for a custom enterprise application in Entra ID, see the Microsoft SAML SSO setup guide.

Configuring OIDC SSO

OIDC (OpenID Connect) is the REST-based alternative to SAML 2.0, using redirect flows with JSON tokens rather than XML assertions. Use OIDC when your IdP supports it and you prefer the simpler token format. Google Workspace natively uses OIDC, and many Okta configurations offer it as an alternative.

One constraint: Onplana requires email_verified: true in the OIDC ID token. Most enterprise IdPs assert this for corporate accounts by default. Some Okta configurations with unverified email flows omit the claim, causing silent login failures. If users are redirected back to the login page without an error after authenticating, check the audit log for an EMAIL_NOT_VERIFIED event.

To configure OIDC:

1. Open Org Settings → Security & Compliance → SSO and select OIDC.
2. Copy the Redirect URI from Onplana.
3. Create an OIDC application in your identity provider:
   • Okta: Applications → Create App Integration → OIDC → Web Application
   • Entra ID: App Registrations → New Registration, choose the Web platform
   • Google Workspace: APIs & Services → Credentials → OAuth 2.0 Client ID → Web Application
4. Add the Onplana Redirect URI as an allowed redirect URI in the IdP application.
5. Copy the Client ID and Client Secret from the IdP application into the Onplana OIDC configuration.
6. Copy the IdP's OIDC Discovery URL (typically https://your-idp-domain/.well-known/openid-configuration) into the Onplana Issuer field.
7. Save and test with a pilot user, verifying the audit log records a LOGIN_SSO event.

Setting Up SCIM 2.0 Provisioning

SCIM automates the complete user lifecycle. Once configured, your identity provider pushes create, update, and deactivate events directly to Onplana.

1. Open Org Settings → Security & Compliance → SCIM and enable SCIM provisioning.
2. Copy the SCIM Tenant URL and generate a Bearer Token. Both are required in the identity provider's provisioning settings.
3. Configure provisioning in your IdP:
   • Okta: In your Onplana SAML or OIDC app → Provisioning tab → To App → enable Create Users, Update User Attributes, Deactivate Users. Under Integration → API Integration, enter the Tenant URL and Bearer Token.
   • Entra ID: Enterprise Applications → your Onplana app → Provisioning → Automatic. Enter the Tenant URL as Tenant URL and the Bearer Token as Secret Token.
   • Google Workspace: Apps → SAML Apps → your Onplana app → Auto-provisioning. Enter the SCIM endpoint and Bearer Token, then enable provisioning.
4. Map IdP attributes to Onplana SCIM fields. Required: userName (email address), displayName, active. Optional: title, department, externalId.
5. Test the connection using the IdP's built-in provisioning test, then confirm a SCIM_USER_CREATE event appears in Onplana's audit log.
6. Run an initial sync to provision all existing directory members into Onplana.
7. Verify the deactivation behavior: deactivate a test user in the IdP and confirm they lose access to your Onplana org while retaining access to any other Onplana orgs they belong to.

SCIM provisioning events appear in Org Settings → Security & Compliance → Audit Log with structured before-and-after diffs, letting you reconstruct the complete provisioning history for any user or time range.

How Per-Tenant Deactivation Works

When your SCIM provider sends a deactivate event, Onplana revokes the user's membership in your org only. Their access to the org's projects, tasks, and dashboards is removed immediately. Personal Access Tokens scoped to your org are revoked. The user's prior role is stashed so a reactivation event later restores the original permission level cleanly.

The membership row in your org is preserved rather than deleted, keeping the complete audit history intact. If the user belongs to other Onplana orgs, those memberships are untouched. A contractor working across three client organizations retains access to the other two when one client deprovisions them.

This is the correct model for a multi-tenant system. The alternative (global deactivation on any tenant's SCIM event) would give any tenant admin the power to lock a user out of every organization they belong to across the platform, which is both a privacy problem and a support escalation waiting to happen.

What to Verify After Enabling SSO

Run this checklist before rolling SSO out to the full organization:

• Log in via the SSO option as a pilot user. Confirm a LOGIN_SSO event appears in the audit log.
• With SSO enforcement enabled, attempt a password login and confirm the redirect fires with no password authentication allowed.
• Provision a new test user via SCIM or JIT. Verify the assigned role is MEMBER, not MANAGER or ADMIN.
• Deactivate the test user in your identity provider and confirm their Onplana org access is revoked within the SCIM sync window. Push-based providers like Okta typically sync within 5 minutes; Entra ID and Google Workspace on scheduled sync cycles may take up to 40 minutes.
• Review existing Personal Access Tokens in the compliance dashboard. PATs remain valid after SSO enforcement is enabled; users who previously authenticated via password and have long-lived PATs retain API access until those PATs expire or are manually revoked. For guidance on managing PATs alongside SSO, see Personal Access Tokens in Onplana: When to Use Them.

Once SSO is live, the layered controls described in the security and compliance overview can be added on top: session timeout policy, idle timeout, 2FA enforcement, and per-org password policy for accounts not yet migrated to SSO. For the full enterprise feature set, see the Onplana features page.