Plane SSO and identity integration

Role assignment in a self-hosted Plane workspace is a licensing decision as well as an access decision. On the Commercial Edition, seats are counted by users with paid roles, so the role a person holds at sign-in can change what your organization pays for. Before you connect SAML, OIDC or LDAP, decide who should be a paid-role member, who should remain a lower-cost member, and who should have no access at all. Those answers determine whether roles belong in Plane, in your identity provider, or in both.

There are two practical patterns. In the first, your team signs people in through the identity provider and then an administrator sets each user's role inside Plane. This is simple to run for a small workspace, but every joiner, mover and leaver needs a manual change, and a user who signs in with the wrong role can consume a paid seat until someone notices. In the second, roles or group membership arrive from the identity provider as claims or directory groups, so the assignment follows the person's HR-driven group membership. This reduces manual work but depends on the claim or group mapping being correct and on Plane applying it the way you expect.

Whichever pattern you choose, confirm with Plane, for the specific protocol you plan to use, whether it supports automated provisioning (such as SCIM-style user lifecycle changes), whether it can read group claims to set workspace roles, and whether directory group sync is available on your plan. Plane's pricing page lists SAML and OIDC on Pro and above and LDAP among Enterprise features for self-hosted installs, but it does not, in the material supplied for this page, describe provisioning or group sync. Treat any assumption about these features as unconfirmed until Plane's documentation or account team states it in writing.

Before go-live, run a short test with a few accounts across each role. Sign in as a new user, confirm which role Plane assigns, and check the seat count in the admin view. Then remove that user from the relevant group in your identity provider and confirm what happens on the next sign-in and whether the seat is released. Record the results. These checks show whether seat consumption will match your expectations and give you evidence for the procurement and finance conversations that follow.

Plan for drift. Roles change, contractors leave and groups get renamed. Assign one owner to review the role-to-group mapping on a fixed schedule, and ask Plane to confirm how it handles users removed from the identity provider, including whether their seats are reclaimed automatically. If it does not, the seat review becomes an operational task with a named owner rather than an assumption about the software.

The purpose of SSO testing is to prove that each sign-in path admits only the people you intend, gives each of them the right workspace role, and fails closed when something goes wrong. Start by writing the test plan against your own identity provider groups and Plane workspace roles, not against a generic checklist. Run every case in a dedicated test workspace on the same edition, version and identity configuration you plan to use in production, because a passing test on a different build proves little. Confirm the exact protocol you are testing (SAML, OIDC or LDAP) and the plan it requires before you start, since the availability of these methods on self-hosted Plane depends on the plan, as described in the pricing notes for this topic.

Cover successful sign-in for each role type you will assign in Plane, including administrators, members, guests or any custom role your organization uses. For each role, sign in through the identity provider, confirm the user lands in the correct workspace, and check that project and module visibility matches the role. Then test the negative cases that matter most: a user who exists in the identity provider but has no assigned seat, role or group membership, and a user who has been disabled or removed. The expected result is a denied sign-in with no new Plane user record and no partial account. Check the Plane user list and the database before and after each attempt, so you can show the reviewer that nothing was created. Confirm the outcome for a user who is removed from the identity provider while holding an active Plane session.

Test sign-out from Plane and from the identity provider, and confirm which one ends the other. Then test session expiry by letting an idle session lapse and by forcing a re-authentication, recording how long the session remains valid as configured in your environment. Next, rotate the signing certificate for SAML or the client secret for OIDC in a staging copy, and verify that sign-in fails until the new credential is loaded and succeeds afterward. Record the exact rotation steps, because the window between the identity provider change and the Plane configuration change is where most production outages occur. Confirm that the old certificate or secret no longer works once rotation is complete.

Test what happens when the identity provider is unreachable, for example by blocking its endpoint at the network layer in the staging environment. A safe failure means users see a clear error, no session is granted, no account is created or modified, and local access paths behave as your documented break-glass policy specifies. Also confirm that local sign-up is restricted as intended. Attempt to register a new account through the sign-up page and any invitation flow, and verify the result matches your sign-up policy. Do not treat a disabled button as proof. Test the endpoint directly.

Store the evidence in a form an internal reviewer can reproduce. For each case, record the test identifier, the date, the Plane edition and version, the identity provider configuration reference, the user account used, the expected result, the observed result, and the relevant log lines or screenshots. Keep the before and after database counts for denied cases. Remove real personal data from the evidence, and keep test credentials out of the record. Agree in writing with your security or compliance lead which failures block go-live and which are accepted risks with an owner. If your organization wants an independent review of this test evidence, confirm with the reviewing party which artifacts they require before the tests run.

Cutover is not the end of the identity work. Once users sign in to self-hosted Plane through SAML, OIDC or LDAP, someone needs to own four recurring checks: sign-in failures, redirect errors, credential expiry and seat consumption. Start by deciding who receives these signals. Your identity provider's sign-in logs will show rejected assertions, unknown users and failed token exchanges, while Plane's own application and reverse proxy logs will show callback errors. Confirm with your identity team which log sources they can export, how long they are retained, and whether an alert can fire when failures spike after a change to DNS, TLS or the Plane base URL. A redirect URI that no longer matches the registered value is one of the most common post-cutover breakages, so include it in the first alert set.

Certificates and client secrets expire on their own schedule, independent of Plane releases. For SAML, track the signing certificate that Plane trusts and the metadata you published to the identity provider. For OIDC, track the client secret or any client credential used for the token exchange. Record each expiry date in your change calendar with an owner and a renewal window, and confirm with your identity provider how it handles rollover, because some providers let you publish a second certificate before the first one lapses. Rotate on a schedule rather than in an emergency. Keep the procedure in a runbook that names the Plane configuration values to change and the restart or redeploy step required after each change. Seat counts need a separate review. On the Commercial Edition, seats are counted by users with paid roles, so a group sync that grants roles broadly can increase cost without anyone noticing. Compare the seat count shown in Plane's administration area with the membership of the identity groups mapped to paid roles, and check whether users who left the organization are deprovisioned in Plane. Confirm with Plane which plan and seat terms apply to your license before you set a review cadence, because the pricing page lists plans and per-user figures that may not match your contract.

Before every Plane upgrade, back up the configuration and secrets that the identity integration depends on. That includes the environment values for the identity provider, the client identifiers, the signing material held in your secrets store, the Helm values or Compose files, and the database that holds users and workspace memberships. Store backups where the restore can be tested, and record which Plane version each backup belongs to. Upgrades follow the separate release cycles of each edition, so a Community release does not tell you what the Commercial build changed. After every upgrade, rerun the sign-in test for each protocol you use, verify group-to-role assignment for at least one user per role, and confirm that the redirect URIs still match. The step-by-step upgrade process is covered in the Plane upgrades and support topic, so use that page for sequencing.

Finally, document the mapping of identity groups to Plane roles. The document should list each identity provider group, the Plane workspace or project role it grants, whether that role is a paid role, who approved the mapping, and the date it was last reviewed. Include the rule for users who belong to several groups, since the outcome depends on how your configuration resolves conflicts. Keep the mapping under version control next to the configuration, so auditors and new administrators can see what changed and when. Illustrative example: if a group named engineering-leads maps to a role that consumes a paid seat, a quarterly review should confirm that the group membership still reflects current responsibilities.