OpenProject SSO and identity integration guide

How OpenProject SSO and identity integration changes access for your teams

Identity integration decides who can sign in to OpenProject, which groups they inherit and how access is removed when someone leaves or changes role. If your instance is self-hosted today, logins, group membership and offboarding are probably handled outside OpenProject, in a directory or identity provider that your identity team owns. Until those rules are agreed, OpenProject will keep its own local accounts and group assignments, and every access change becomes a manual task that someone must remember to perform. The edition decision comes first. OpenProject lists single sign-on through SAML, OIDC, CAS, Kerberos and Okta, along with LDAP group synchronization and custom branding, among its Enterprise features (OpenProject pricing page). The Community edition is free but does not include these identity features. That means the choice between editions shapes the design before any configuration starts: if you need group membership to follow the directory, the Enterprise tier is a requirement, not an optional upgrade. Confirm the current feature list against the pricing page and your own user counts before you commit to a design, because Enterprise pricing is per named user per month with minimums that depend on the plan. The integration is harder than it looks for four reasons. First, the identity provider must send the attributes OpenProject expects, such as a stable user identifier, email address and name, and any group or role claims. Second, group names in the directory rarely match the project roles and groups you want in OpenProject, so a naming and mapping scheme must be agreed in advance. Third, users who already have local OpenProject accounts need a plan for linking those accounts to the external identity without creating duplicates or losing their work history. Fourth, the provisioning rules must be written down: who is created automatically at first login, who is deactivated when they leave the directory, and who is allowed to hold administrator rights. The practical next step is a working session with your identity team before any installation. Bring a list of the groups that should grant access, a sample of the claims your identity provider can send, and a decision on how existing local accounts will be migrated. Ask the identity team to confirm which protocol they support and which attributes they can release, because those answers determine whether SAML, OIDC or LDAP is the right path for your environment.

Which identity components and settings are involved

An OpenProject identity integration touches four areas: the identity provider that authenticates people, OpenProject's authentication settings, group synchronization, and the user and group records OpenProject creates from them. Each one has a different owner, so the team should agree on who controls what before any configuration begins.

Identity provider and protocol

This is the system that proves who a user is: a SAML or OIDC provider, an LDAP directory, or Okta. The choice sets which OpenProject single sign-on option applies, and SSO methods such as SAML, OIDC, CAS, Kerberos and Okta are listed as Enterprise features on the pricing page. Confirm the protocol, the metadata or client registration details, and which team operates the provider before anything is configured.

OpenProject authentication settings

These are the administration settings in OpenProject that enable an identity provider, define how login is handled, and decide whether local password login stays available as a fallback. The OpenProject team usually owns them, but changes can lock out every user if made incorrectly. Ask the identity owner which claims or attributes arrive at login, then confirm the exact configuration keys and supported attribute mappings in the OpenProject administration documentation for your release.

Directory and attribute source

The directory or claim source supplies the user attributes OpenProject relies on, such as login name, email address and display name. Where the source is an LDAP directory, its schema and bind account determine what OpenProject can read. Confirm with the directory owner which attributes are authoritative, whether values are maintained for every user who needs access, and how leavers are removed from the directory.

Group synchronization

Group synchronization maps directory or provider groups to OpenProject groups, which can then carry project roles and permissions. LDAP group synchronization is listed as an Enterprise feature. Decide which groups should drive access, who names and owns them, and whether nested groups are used in the source, since the mapping logic must match that structure. Confirm the sync frequency and behavior when a group is deleted upstream with the identity owner.

User and group records created by OpenProject

OpenProject creates or updates user and group records as people sign in or as synchronization runs. These records hold roles, memberships and activity history, so their behavior affects audit trails and access reviews. Test with a small pilot group to see how accounts are created, matched to existing local accounts, deactivated and reactivated. Confirm the deprovisioning behavior with the security team before go-live.

Release-specific configuration limits

Identity features, supported attribute mappings and configuration keys can change between OpenProject releases, and the release cycle includes frequent minor versions. Treat the settings described in this page as a planning guide only. Before building, read the OpenProject administration documentation for the exact release you will deploy, and record which version the configuration was tested against so upgrades can be checked against it.

Which authentication method and provisioning model to choose

This table compares the main sign-in and provisioning choices for OpenProject and the operational cost of each. Read the fit column first to find the conditions that apply to your identity provider and directory, then check the cost column for ongoing admin work. SAML, OIDC, LDAP group synchronization and SSO group mapping are all Enterprise features, so settle the identity design before sizing licenses.

Option	When it fits	Operational cost
SAML SSO	Your identity provider already issues SAML assertions and your security team manages it that way.	Requires an Enterprise plan. Certificates and metadata must be tracked and renewed on both sides.
OIDC SSO	Your identity provider already exposes OpenID Connect endpoints for applications.	Requires an Enterprise plan. Confirm client registration, redirect URIs and claim mapping with your provider.
LDAP group synchronization	Your directory is the source of truth for groups and teams already maintain them there.	Requires an Enterprise plan. Group changes flow from the directory, so directory clean-up becomes an OpenProject concern.
Group mapping from the SSO provider	Your SSO provider holds the group model and no separate directory feeds OpenProject.	Requires an Enterprise plan. Group names must be mapped, which duplicates some group management effort.
Just-in-time account creation	Any employee with a valid login should get an account on first sign-in.	Lower setup effort. Accounts still need deactivation at offboarding, so confirm how departed users are handled.
Pre-provisioned accounts	Access must be approved before a user can sign in, such as for restricted projects.	Admins create and maintain accounts in advance. Offboarding and role changes add ongoing admin and support load.
Local admin break-glass login	Every deployment where SSO could fail and an administrator still needs access to the instance.	Credentials must be stored, tested and monitored separately. Limit use to named administrators and log each use.

OpenProject SSO and identity integration build sequence

This sequence takes OpenProject from a planned identity integration to a documented production sign-in path. Each step closes with a check that both the identity owner and the platform team can observe. Work starts in a test environment and moves to all users only after a pilot group signs in and deprovisioning behaves as expected.

Confirm the edition and required features
The platform team lists every identity feature the rollout needs, such as SSO through SAML or OIDC, LDAP group synchronization and any SSO for the Nextcloud integration. Each item is checked against the OpenProject pricing page for the edition and user band being purchased. Single sign-on and LDAP group synchronization appear in the published Enterprise feature list, so a Community installation cannot use them. Ask OpenProject to confirm in writing which features the chosen plan includes for the target release. Done when the sponsor signs the feature list and the purchase matches it.
Agree the attribute and group model
Meet the identity owner and agree which directory attributes map to login name, email, first name and last name. Record which groups grant project or administrator roles, the OpenProject role each maps to and who approves membership changes. Confirm which attribute serves as the unique identifier so accounts do not duplicate if an email address changes. Done when the identity owner and the OpenProject administrator sign the mapping sheet and every administrator-granting group has a named owner.
Register OpenProject or configure LDAP in test
In a test environment, either register OpenProject as a client in the identity provider using its SAML or OIDC settings, or configure the LDAP connection with a read-only service account. Keep redirect addresses, certificates and bind credentials separate from production values. Run the connection test from the OpenProject host, since that is the network path production traffic will use. Done when the identity provider metadata or the LDAP bind succeeds from the server and a test user reaches the sign-in screen.
Map user attributes and groups
Configure the attribute mapping and group synchronization from the agreed sheet, then sign in with a small set of test accounts that cover each group. Check that new accounts are created with the expected name and email and that group membership produces the expected OpenProject roles. Confirm whether a removed group member loses roles at the next sign-in or at the next sync run, and document that behavior. Done when a group membership comparison between the directory and OpenProject matches for every test account.
Test sign-in with a pilot group
Enable SSO or group synchronization for a pilot group of live, non-administrator users chosen across at least two teams and roles. Each pilot user signs in, works on a work package within their project permissions and reports any mismatch. Run a deprovisioning test by disabling one pilot account in the directory and confirming that sign-in is refused and existing sessions end within the interval the identity owner accepts. Done when pilot logins succeed, permissions match the mapping sheet and the disabled account is blocked.
Enable the setting for all users
Plan a change window with the identity owner and business sponsors, then switch the setting on for all users. Keep the pilot configuration and a written rollback path ready, including how to restore local password sign-in if the identity provider becomes unavailable. Watch failed sign-ins and new account creation during the first sign-in period after the change, and compare the OpenProject user list with the directory group. Done when the two user lists match and failed sign-in volume stays at a level the identity owner has agreed.
Document and test the break-glass admin path
Create a local administrator account excluded from SSO and store its credentials in the organization's sealed credential process, recording who can release them. Test the login in a non-production copy and confirm it works while the identity provider is unreachable. Write the procedure covering when the account may be used, who approves its use and the review that follows each use, and review the account on the same schedule as other privileged accounts. Done when a test login with the break-glass account succeeds and the identity owner approves the runbook.

What drives the effort and cost of identity integration

This table lists the factors that change the effort and cost of connecting OpenProject to an identity provider or directory, with a way to keep each one down. Read each row as a decision to settle before the written scope is agreed. The main takeaway is that directory cleanup, group scope and edition choice usually shape the work more than the protocol itself.

Driver	Why it changes effort or cost	How to keep it down
Edition and feature tier	SSO and LDAP group synchronization are listed as Enterprise features, so the tier decides whether the work is possible.	Ask the vendor which tier covers each feature before choosing a protocol (OpenProject pricing).
Published per-user pricing	Basic 5.95 euros, Professional 10.95 euros (25-user minimum), Premium 15.95 euros (100-user minimum), per named user per month.	Ask for a written quote from the written scope. Corporate is on request for 250 or more users (OpenProject pricing).
Number of identity sources	Each source needs its own connection, attribute mapping and test logins, and multiple sources add account matching work.	Confirm the source of truth for users during design. Connect one source first and add others only where needed.
Groups and nested structures	Many or deeply nested groups need mapping rules to OpenProject project roles, which takes review with directory owners.	Sync only groups used for project roles. Flatten nesting where the directory allows it.
Directory data quality	Duplicate, stale or incomplete accounts, and missing email or name attributes, cause failed logins and manual cleanup.	Clean the directory before go-live. Disable leavers and fix attribute gaps during the pilot.
Protocol choice	SAML, OIDC, CAS, Kerberos and Okta each need their own configuration, certificates or client registrations and test cases.	Choose the protocol your identity provider supports well, and confirm it is available in your edition.
Existing local accounts	Users who already sign in with local OpenProject accounts must be matched to directory identities, and duplicates need a decision.	Export local accounts before go-live. Agree a matching rule and cutover steps for each user group.
Environments	Test, staging and production each need their own identity provider settings, redirect URLs and test users.	Build in test first, promote the same settings through staging, and run a pilot group before production.
Compliance evidence from access reviews	Access reviews need reports showing who holds which group or role, and when that access changed.	Agree the report format early and confirm group membership can be exported. Independent assessors reach the audit conclusion.

How identity integration differs by installation method

Docker is the installation method OpenProject recommends, so most SSO planning assumes a container running behind a reverse proxy. The identity provider sends users back to the public address they type into the browser, which means the proxy's external hostname, scheme and forwarded headers must match what is registered with the provider. Certificates usually terminate at the proxy, and the application trusts the provider's certificate chain through a trust store or setting that you confirm for your version.

Network path: the container must resolve and reach the identity provider's discovery or metadata endpoints from inside its network, which may require DNS entries or egress rules.
Redirect URLs: register the exact public callback URL, including scheme and path, and confirm the base URL setting in the container configuration.
Secrets: inject client secrets and key material at startup through an environment file, Docker secrets or a secrets manager, and keep them out of images and version-controlled Compose files.
Rollout: configuration changes usually mean recreating the container with new environment values, so schedule a restart window and test login after each change.

Before go-live, confirm the callback URL, certificate trust and secret injection against the Docker section of the installation documentation for your version.

How to test OpenProject sign-in, group mapping and failure paths

Test the identity integration before any user depends on it, and test the failure paths on purpose rather than waiting for an outage to reveal them. The plan below covers five areas: sign-in for each identity method, group and project role mapping, deprovisioning, identity provider outage, and invalid or expired tokens. Each area should have a pilot user in every group that will exist in production, so that a single successful login does not hide a mapping gap for a whole department. Start with sign-in. For each identity method you enable (SAML, OpenID Connect, or LDAP), sign in as a pilot user from each directory group and confirm that the account is created or matched correctly in OpenProject. Check the login name, email address and display name against the directory record. If you use LDAP group synchronization or another Enterprise identity feature, confirm in the administration area that the feature is licensed and enabled before you test it, because a feature that is missing from the plan will fail in a way that looks like a configuration error.

Next, confirm that group membership and project roles match the directory. For each pilot user, compare the OpenProject groups and the roles held on sample projects with what the directory says should apply. Verify both directions: a user who leaves a group should lose the access that group granted, not just gain new access. Record which group maps to which global role and which project role, because mapping errors usually come from a role assigned at the wrong level rather than from a missing group. Deprovisioning needs its own test. Disable a pilot account in the directory, then attempt to sign in through every enabled method, including any API token the user created. A disabled account should not sign in or continue an existing session once its session lifetime expires. Confirm how long an open session remains valid after the directory change and set your expectation accordingly, since that window is a decision for your security team to make.

Test the outage path next. Simulate the identity provider being unreachable, for example by blocking network access from the OpenProject host to the provider in a non-production environment. Users should see a clear failure, and a break-glass local administrator account should still be able to sign in. Confirm that this account exists, that its credentials are stored under your normal secrets process, and that its use is logged. Do not treat the break-glass path as proven until someone has actually signed in with it during the test. Finally, test invalid and expired tokens. Present a token with a bad signature, an expired assertion or a mismatched audience, and confirm that OpenProject rejects it and records the attempt. For OpenID Connect, also test a user whose session has expired at the provider. If your team uses the Nextcloud OpenID Connect add-on, which OpenProject lists as an Enterprise add-on for Nextcloud SSO, run the same sign-in and deprovisioning checks against Nextcloud separately, because the two integrations can drift apart. Before each test, write down the expected result: the page shown, the account state, the role granted and the log entry expected. Compare the actual result against that record. A test without a written expectation tends to pass by default. Confirm the exact behavior of each identity method and log output with your OpenProject release notes and documentation for the version you run.

How to protect identity secrets and admin access

An SSO or LDAP connection gives OpenProject a trusted path to user accounts, so the credentials and settings behind it deserve the same care as the administrator accounts themselves. The cards below cover the controls we check on most identity integrations, each with an owner and a verification step. Confirm the specific hardening options for your release in the OpenProject security documentation before you finalize the design.

Client secrets and LDAP bind credentials

The OIDC or SAML client secret and the LDAP bind password let OpenProject query your directory or identity provider. Keep them out of configuration files in source control and out of plain text in shared runbooks, and store them in your existing secrets manager or a restricted vault. Owner: the platform team. Check: confirm where each secret lives, who can read it, and that it does not appear in container images or logs.

Rotation schedule for integration secrets

Identity secrets should have a defined rotation interval and a tested procedure for replacing them without a service outage. Rotation of an OIDC client secret usually requires updating both the identity provider and OpenProject in a short window. Owner: the identity team with the platform team. Check: run one rotation in a test environment and record the steps, the downtime observed and who approved the change.

Least-privilege directory service account

The LDAP bind account should be a dedicated service account with read access only to the users, groups and attributes OpenProject needs for synchronization. It should not be a personal account or a directory administrator. Owner: the directory team. Check: review the account's permissions against the attributes your group mapping uses, and confirm that it cannot write to the directory or reset passwords.

Restricted authentication settings changes

Changes to SSO providers, LDAP connection details, group mapping and login rules alter who can sign in and with what privileges. Limit edit rights for these settings to a small named group of administrators and require a change record for each update. Owner: the OpenProject administrators with the security lead. Check: list every account with administrator rights, confirm the list matches approved roles, and review the audit trail for recent settings changes.

Break-glass local administrator custody

Keep one local OpenProject administrator account that works without the identity provider, so you can recover access if SSO or LDAP fails. Store its credentials under dual control in a sealed record and document who may retrieve them and under what incident conditions. Owner: the CISO or delegate. Check: test that the account can sign in in a non-production copy, confirm that its use triggers an alert, and reset the credentials after each use.

TLS on the identity provider connection

The connection between OpenProject and the identity provider or LDAP server must be encrypted, and certificate validation must be enabled so that OpenProject verifies the server it connects to. Use certificates issued by your internal authority and make sure OpenProject trusts that chain. Owner: the infrastructure team. Check: confirm that the LDAP connection uses encrypted transport, that certificate expiry is monitored, and that no setting disables verification.

Authentication event logging

Sign-in successes, failures, lockouts, administrator setting changes and group sync results are the evidence you need during an incident or assessment. Forward OpenProject application logs and the identity provider logs to your central log platform with a retention period set by policy. Owner: the security operations team. Check: generate test sign-in failures and confirm that they appear in the central platform with user, time and source fields.

What to monitor, document and review after go-live

The ongoing work starts the day SSO goes live, and it needs a named owner who checks it on a fixed schedule. The most common silent failure is expiry. When the identity provider's signing certificate or the OpenID Connect client secret used by OpenProject reaches its end date, sign-in stops for everyone at once. Record every expiry date in the configuration record, set reminders well ahead of each date, and agree the renewal procedure with your identity team. A new certificate or secret usually has to be deployed on both the identity provider and the OpenProject side, so plan an overlap window where both values are valid and rehearse it in a staging instance first. Ask your identity provider vendor how it notifies administrators before expiry, and confirm that the notice reaches the owner of the OpenProject integration.

Group membership changes constantly, so schedule a reconciliation instead of waiting for a complaint. Compare the groups that synchronize into OpenProject with the groups in your directory, and confirm that people who left or changed teams no longer hold roles they should not have. Check the group-to-role mapping for drift, especially where a project administrator was added by hand and never removed. LDAP group synchronization is listed as an Enterprise feature on the OpenProject pricing page, so confirm your license covers it before you depend on it. Monitor failed sign-ins and provisioning errors as well. Decide who receives the alerts, which failure patterns trigger a response, and where the logs live for your installation method, since Docker, package and Kubernetes deployments expose logs differently. Confirm these locations with your own deployment team.

Review access after every minor release. OpenProject ships frequently, and the 17.x line shows the pace: 17.7.0 was released on August 5, 2026, 17.8.0 on September 2, 2026, and 17.9.0 on September 30, 2026, followed by 17.9.2 on October 15, 2026. Upgrades can change authentication behavior, so read the release notes for each version you adopt and search them for references to SSO, OpenID Connect, SAML, LDAP and group handling. Then test sign-in in staging with a set of representative accounts, including at least one account that should be denied access, before promoting the upgrade to production. A successful build or a working homepage does not show that login and group-based roles still behave as before.

Hand over documentation that lets someone other than the builder operate the integration. The configuration record should list the identity provider metadata version, the redirect and callback addresses, the attribute and claim mappings, the certificate and secret expiry dates, and where secrets are stored, without including the secret values themselves. The group-to-role mapping should show each directory group, the OpenProject role it grants, its global or project scope, and the owner who approves changes. The offboarding procedure should cover disabling the identity account, deactivating the OpenProject user, and reviewing the work packages and shared links that user owned. Assign each step to a role so that it still works when people move on.

The break-glass procedure covers the case where the identity provider is unavailable or misconfigured. Document the local administrator account kept for that purpose, where its credentials are stored, who may use it, how each use is logged and reviewed, and how the password is rotated after use. Keep the test evidence from verification with this set: the test cases, the results, the retest after each fix, and the sign-in checks from each release review. DeployOpen prepares systems, controls and evidence for compliance assessments, but independent auditors and certification bodies decide whether that evidence meets your requirements. Agree the review cadence and the owners for each record with your security and compliance leads before go-live.

OpenProject SSO and identity integration questions buyers ask

Does OpenProject SSO or LDAP group sync require an Enterprise plan?

Yes. OpenProject lists single sign-on (SAML, OIDC, CAS, Kerberos and Okta) and LDAP group synchronization among its Enterprise features, so both need an Enterprise plan for an on-premises installation. The Community edition is free and includes work packages, Gantt charts, agile boards, time tracking and dashboards, but it does not include these identity features. OpenProject's published pricing lists Enterprise on-premises per named user per month: Basic at 5.95 euros and Professional at 10.95 euros with a 25-user minimum, Premium at 15.95 euros with a 100-user minimum, and Corporate on request for 250 or more users. Edition boundaries can change between releases, so confirm the current feature list on the pricing page and ask your implementation partner to show which edition covers each identity feature you plan to use.

What drives the cost of OpenProject SSO and identity integration?

Cost has two parts: the license and the implementation work. The license is recurring and depends on edition and named user count. The implementation is usually one-time work under a written scope, unless you add ongoing support. The main drivers of the implementation effort are the number of identity sources (one identity provider or several directories), group complexity (nested groups, overlapping groups, and how groups map to OpenProject roles and projects), the number of environments that need configuration (test, staging and production), and compliance evidence such as documented attribute mappings, test records and change records. Each driver raises the effort when it is larger. Ask for a quote that itemizes each environment, each identity source, the group mapping work, and the evidence deliverables, so you can compare options and see what changes if the scope grows.

What do we need to provide for an identity integration project?

Your team supplies the access and decisions that the work depends on. A directory owner provides the LDAP or Active Directory details, a service account for queries, and the group and organizational unit structure. An identity provider administrator registers OpenProject as an application, configures redirect addresses and claims, and supplies the metadata or client credentials. Your team also needs test users that cover each role and group, a named person who signs off the attribute mapping (which fields supply login, email, name and group membership), a test environment, and administrator access to OpenProject. Agree on these owners and dates in the written scope before work starts, because delays in access are a common reason identity projects slip.

Can our internal team set up OpenProject SSO without a partner?

Yes, if the team has the right skills and a safe place to test. You need people who understand SAML or OIDC, LDAP queries and group design, plus administrators who know OpenProject's configuration and its Enterprise identity settings. A test environment that mirrors production is essential, so that failed logins and wrong attribute mappings do not lock out real users. Expect some iteration with the identity provider administrator on the first configuration, because claim names and group identifiers often need adjustment after the first test. A partner is most useful when your team lacks one of these skills, does not have the capacity to run the project alongside its normal work, or wants an independent review of the configuration and the runbook before go-live.

How does directory quality change the time an identity integration takes?

Directory quality is usually the largest variable in the schedule. A clean directory has unique login names, consistent email attributes, groups that match real access needs, and clear ownership of each group. A messy directory has duplicate accounts, stale or disabled users that are still in groups, nested or overlapping groups, missing attributes, multiple domains, and inconsistent naming. Each problem adds discovery work, decisions that need an owner, mapping rules and additional test cycles. Because the scale of these issues varies by organization, no general duration applies. Ask for an estimate that is tied to a short inventory of your directory, including the number of identity sources, the approximate number of groups and users, and any known data problems, and ask the provider to state which assumptions the estimate depends on.

Does the integration change how users are deprovisioned in OpenProject?

Single sign-on controls how users authenticate, and LDAP group synchronization controls which groups they belong to. Neither should be assumed to remove an account, disable access or reassign work on its own, so confirm this against the documentation for the release you plan to run. Ask how a user removed from the directory is handled: whether the account is deactivated at the next login or synchronization, whether existing assignments and open work packages stay with the account, and who receives the reassignment task. Test this with a disabled test account before go-live, and write an offboarding runbook that names the owner for each step. Your offboarding process should still cover sessions, API tokens and any other access paths outside the identity provider.

What should we check in a quote for OpenProject identity work?

A usable quote lists the scope in writing before work starts. Check that it names each identity provider and directory source, the group mapping rules, every environment that will be configured, and the acceptance criteria for each test. Look for stated exclusions, such as changes to the identity provider beyond the OpenProject application registration, and for assumptions about the directory and the network. Confirm who holds the Enterprise license, how licenses are counted and whether they are billed separately from the services. Make sure the quote covers the knowledge transfer and the runbook, and explains what happens if the scope changes during the project through a written change request. Ask whether post-go-live support is included or sold as a separate retainer, and request the quote as a written scope with deliverables and timelines.

How DeployOpen works on this

DeployOpen plans, implements and supports OpenProject inside your own infrastructure, including the identity layer that decides who signs in and which groups they belong to. Identity work starts with a written scope that names the protocol, edition and directory sources in use. Fixed-scope engagements set out deliverables and timelines in writing before work begins, and ongoing support is available as a retainer.

How we scope

The written scope names the protocol: SAML, OIDC or LDAP, and the identity provider involved.
It records which features need an Enterprise plan, such as SSO, LDAP group synchronization and custom branding.
Provisioning rules, group mapping and account ownership are agreed with your identity team before build starts.

How we build

Configure the identity provider and OpenProject side by side in a non-production instance first.
Map directory groups to OpenProject roles and projects, then test each role with named test accounts.
Test failed sign-ins, locked accounts, group changes and removal of leavers before go-live.

How we hand over

Deliver configuration records covering protocol settings, certificate or client details and group mappings.
Document the sync schedule, the admin runbook for adding identity providers and the rollback steps.
Walk your administrators through sign-in troubleshooting and the process for renewing certificates or secrets.

How we support

Ongoing support can cover identity changes, OpenProject upgrades and re-testing sign-in after each release.
Coordinate identity provider changes, such as certificate rotation, with a scheduled re-test.
Confirm with your identity provider and OpenProject which Enterprise features your edition includes before you commit.

OpenProject SSO and identity integration