Why SSO and LDAP decide the edition for open source project management
If project tool access must run through your central identity provider and directory, the edition you buy is decided before the software is chosen. On OpenProject, single sign-on over SAML and OIDC and LDAP group synchronization are Enterprise features, and on self-hosted Plane, SAML and OIDC start at the Pro tier while LDAP support sits in Enterprise. Redmine authenticates against LDAP natively and has no paid edition, but SAML or OpenID Connect sign-on depends on plugins or an authenticating reverse proxy. The decision is therefore about edition, per-user cost and the people who maintain the integration as much as about the protocol itself.
Identity is a control, not a convenience. When joiners, leavers and group changes are driven by HR records, a project account that outlives its owner's employment is an access path nobody reviews. Group membership in the directory should decide which projects, roles and time-tracking permissions a person receives, so that a change in HR reaches the project tool without a manual ticket. Regulated organizations will also want to show that authentication is enforced centrally and that access removal is timely, which makes the sign-on path part of the evidence for their access review, not only an IT setup task.
Before you compare editions, confirm four things with each vendor in writing: which protocol and directory features are included in the tier you price, whether group-to-role mapping is covered or only user login, how the Enterprise or Pro license is counted (for example, by named users or by seats with paid roles), and what happens to existing accounts and permissions when you switch from a Community install. For Redmine, ask a partner to name the specific SAML or OIDC plugin or reverse proxy, its maintenance status and who patches it after each Redmine upgrade. Those answers, not list prices, determine the real cost of single sign-on.
Which identity requirements apply and what each means for the build
This table lists the five identity requirements that usually appear once project management holds regulated or business-record data, along with the source that drives each one and what it means for the build. Read each row as a question to answer before choosing an edition, since SSO and LDAP features are often gated behind paid tiers. Regulations such as 45 CFR 164.312 and SEC Rule 17a-4 require controlled access and auditable activity, not a specific SSO technology.
| Requirement | Where it comes from | What it means for the build |
|---|---|---|
| SAML or OIDC federation with the corporate identity provider | Access control expectations under 45 CFR 164.312(e)(1) for systems reachable over networks carrying ePHI; the rule does not name a protocol | Confirm which protocols your identity provider supports and whether the edition you choose enables them. OpenProject Enterprise lists SAML and OIDC, while on self-hosted Plane they start at Pro, and Redmine usually needs a plugin or reverse proxy |
| LDAP or directory group synchronization | Central, consistent access control across systems that hold business records or ePHI | Decide whether group membership drives project roles automatically. OpenProject lists LDAP group synchronization as an Enterprise feature, Plane lists LDAP under Enterprise, and Redmine supports multiple LDAP sources natively |
| Deprovisioning when access ends | Access control expectations under 45 CFR 164.312, plus the need to keep retained communications attributable under SEC Rule 17a-4(b)(4) | Test that disabling a directory account blocks login and API keys in each tool. Redmine API keys and personal tokens need a separate revocation step, so document who owns that process |
| Audit logging of administrative and access events | Audit controls under 45 CFR 164.312(b) that record and examine activity in systems holding ePHI | Confirm which audit events are in the edition you buy. Plane lists API-enabled audit logs as an Enterprise feature, so budget for log export to your SIEM and retention outside the application |
| Per-group role mapping | Least-privilege access and the ability to show who could view or change project records | Map directory groups to project roles before rollout. Keep the mapping in version control so assessors can compare it with the current configuration after each upgrade |
| Retention of project communications as business records | SEC Rule 17a-4(b)(4) for broker-dealers, which requires preserving communications relating to the business for not less than three years | Project comments and notifications may fall under this rule. Confirm with compliance counsel whether they are records, and plan export or archiving rather than assuming the project tool retains them |
How OpenProject, Plane and Redmine handle SSO and LDAP
OpenProject lists single sign-on through SAML, OIDC, CAS, Kerberos and Okta, along with LDAP group synchronization and custom branding, as Enterprise features rather than Community features. If your directory and identity requirements are mandatory, plan around an Enterprise edition from the start. The on-premises Enterprise plans are priced 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.
- Protocol coverage: SAML, OIDC, CAS, Kerberos and Okta single sign-on are listed as Enterprise features.
- Directory sync: LDAP group synchronization is an Enterprise feature, so group membership can drive project roles.
- Per-user cost: Basic and Professional carry minimums of 25 users, Premium carries a minimum of 100 users, and Corporate is quoted for 250 or more.
- Community baseline: The free Community edition has no SSO or LDAP sync, so pilots that depend on them need an Enterprise trial scope.
- Hosting: Enterprise on-premises licensing applies to self-hosted installs, which is the model most regulated buyers choose.
Confirm the exact protocol list, the per-user tier boundaries and the minimum seat counts against OpenProject's current pricing page before you build a budget, since these details change between releases.
Plane's self-hosted editions are not a single product with a feature toggle. Plane offers Community, Commercial and Airgapped editions, each built on a distinct codebase. Community is AGPL-3.0 and matches the Plane Cloud Free feature set, so SAML, OIDC and LDAP are not part of it. Moving to paid features means switching from Community to the Commercial Edition and activating a license key, which counts seats by users with paid roles.
- SAML and OIDC: On self-hosted Plane, both are available from the Pro plan and above.
- LDAP and audit logs: LDAP support and API-enabled audit logs are listed as Enterprise features.
- Edition switch: A self-hosted Community install must first move to the Commercial Edition before any paid plan applies.
- License key: Paid plans on self-hosted installs require a license key, so activation is part of the rollout plan.
- Per-user cost: Pro is shown at 6 to 8 US dollars and Business at 13 to 15 US dollars per user per month, with Enterprise Grid priced on request.
LDAP is the gap to watch: Pro can meet a SAML or OIDC requirement, but a mandatory directory sync pushes you to Enterprise. Confirm the current feature matrix, the Airgapped edition terms and how seats are counted before you commit.
Redmine authenticates against LDAP natively and supports multiple LDAP authentication sources, which covers directory-based login without an add-on. SAML or OpenID Connect single sign-on is not part of the core product. It depends on plugins or on an authenticating reverse proxy placed in front of Redmine. Redmine is released under GPL v2 and has no paid edition, so the cost comes from hosting, implementation, plugins, upgrades and the people who maintain them.
- Native LDAP: Redmine supports multiple LDAP sources in the core product, so directory login needs no paid tier.
- SAML or OIDC: These depend on a plugin or on a reverse proxy that handles authentication before requests reach Redmine.
- Proxy design: A reverse proxy approach moves trust decisions outside the application, so the proxy, its session handling and its logging become part of your audit scope.
- Plugin upkeep: Each SSO plugin must be checked against the Redmine version you run, and plugin migration is part of every upgrade.
- No license fee: The absence of a paid edition shifts the cost to integration and support, which should be quoted explicitly.
Before you choose this route, confirm the current plugin compatibility with your Redmine release line and the reverse proxy's authentication method in Redmine's documentation.
Which platform fits when identity is mandatory
Once single sign-on and directory sync are mandatory, the choice narrows quickly, because each platform gates these features differently. The cards below set out the decision points, the cost driver for each path, and what to verify before you commit to an edition.
OpenProject Enterprise for SSO and LDAP
Choose OpenProject Enterprise when SAML or OIDC single sign-on and LDAP group synchronization must run in one supported product. OpenProject lists SSO protocols including SAML, OIDC, CAS, Kerberos and Okta, plus LDAP group sync, among its Enterprise features, so these needs are not met by the free Community edition. The cost driver is the named user count, billed per user per month with minimums by tier. Confirm which tier covers your user population, and ask the vendor whether SSO and group sync are included in the on-premises license you are buying.
Plane Enterprise for LDAP and audit logs
Plane fits when LDAP support and API-enabled audit logs are required and a seat-based model suits your organization. On self-hosted Plane, SAML and OIDC arrive at Pro, but LDAP and API-enabled audit logs are listed as Enterprise features, so a team that needs directory sync and audit trails must plan for the top tier. Self-hosting these paid features requires moving from the Community edition to the Commercial edition with a license key. The cost driver is seats counted by users with paid roles, so ask how guest and viewer accounts are counted.
Redmine with native LDAP
Redmine is a fit when LDAP authentication is sufficient and your team can own the rest. Redmine authenticates against LDAP natively and supports multiple LDAP sources, so directory login needs no paid tier because Redmine has no paid edition. SAML or OpenID Connect single sign-on is not part of the core product and depends on plugins, so you must validate each plugin against your Redmine version. The cost driver is internal and partner effort for plugin selection, maintenance and upgrades, since plugins must be migrated with the core during each upgrade.
Reverse proxy pattern for Redmine
An authenticating reverse proxy can place Redmine behind an identity provider without changing Redmine's core code. The proxy handles SAML or OIDC login and passes the verified user identity to Redmine, which is the alternative to a plugin that the product documentation names. The design shifts risk to the proxy: header trust, session handling and logout must be tested, and users who reach Redmine directly must be blocked. The main risk is an unprotected direct path to the application, so verify that the network layout and the Redmine API keys both sit behind the same control.
Matching the edition to your identity model
Before you choose a platform, map your identity requirements to the product tier that provides them: SAML or OIDC only, LDAP group sync, audit logs or all three. Write the requirement list with the protocol, the directory source, the group-to-role mapping and the logout behavior. Then request the edition and license terms in writing from the vendor or from your implementation partner. This list is the basis for a fixed-scope quote, because the tier, seat count and plugin work all follow from it.
Integration points and deployment pattern for identity
Single sign-on and directory sync touch more than the project tool itself. The five components below are where identity decisions meet the deployment, and each one needs an owner and a written answer before an edition is bought.
Identity provider and protocols
The identity provider issues the SAML or OIDC assertions that OpenProject Enterprise and Plane Pro or above can consume. Confirm which protocol your provider supports, which claims carry the user's email and group membership, and whether the provider is itself self-hosted in the same network. Ask the vendor how the application handles a login when the provider is unreachable, and whether the provider's session lifetime matches your policy for privileged project roles.
Directory and group mapping
LDAP group synchronization is an Enterprise feature in OpenProject, and LDAP support is listed as an Enterprise feature on self-hosted Plane. Redmine authenticates against LDAP natively. Map which directory groups become project roles, who owns that mapping, and what happens to an account that leaves a group. Confirm whether group changes apply at next login or on a scheduled sync, because that timing decides how quickly access is removed.
Local accounts and break-glass administrators
The application database holds local accounts, service accounts and any fallback administrators. Keep at least one named break-glass administrator outside SSO, with its credentials stored in a sealed vault and its use logged and reviewed. Confirm with each vendor whether local login can be disabled for ordinary users without disabling the administrator path, and test that path during the rollout rather than during an outage. OpenProject runs on PostgreSQL 16 or later with the pg_trgm, btree_gist and unaccent extensions, so the database team should confirm those are available before the identity change.
Reverse proxy and plugin layer
Redmine's SAML or OpenID Connect single sign-on depends on plugins or an authenticating reverse proxy, so the authentication path runs through components you must patch and monitor. Decide where session handling lives, which proxy terminates TLS, and who owns plugin updates across Redmine upgrades. For a deployment on Docker, Kubernetes with Helm, or packages, confirm which ingress or proxy the team supports and how the login redirect is configured. Ask for the exact configuration keys in the vendor's current documentation rather than copying them from forum posts.
Deprovisioning and log export
Access removal is the control auditors test most often. Confirm how a disabled directory account propagates to the project tool, whether existing API keys and personal access tokens are revoked, and whether audit logs record role changes with user identity. Plane lists API-enabled audit logs as an Enterprise feature. Decide where logs are exported, how long they are retained, and who reviews them, since HIPAA audit controls and SEC recordkeeping rules apply only where the project data itself falls within scope.
How the identity rollout is sequenced
The sequence confirms the edition against the feature lists before any configuration, proves federation and directory sync in a non-production instance, and only then moves users in waves. Each phase closes with a written artifact the client keeps.
Confirm identity requirements and edition
DeployOpen and the client's identity team list the required login methods (SAML, OIDC, LDAP or Kerberos), group sync needs, admin break-glass rules and audit log export needs. Each requirement is matched against the current edition feature lists for OpenProject, Plane and Redmine, including Redmine's plugin-based SSO. The client receives a signed requirements-to-edition matrix that names the edition and any plugin, and the open questions that the vendor must confirm in writing before purchase.
Build a non-production test tenant
DeployOpen installs the chosen platform in a non-production environment that matches the production hosting model, including the database and reverse proxy in the same topology. The client's IdP administrator creates a test application or client registration, and the redirect URIs and certificates are recorded. The output is a working test instance where a sample account signs in through the IdP, and a configuration record listing every identity setting, stored with the infrastructure code.
Federate with the identity provider
The team configures SAML or OIDC against the test tenant, maps the IdP attributes (email, login name, display name) to platform user fields, and confirms that the first login creates the account with the correct permissions. Signature checks, token lifetimes and logout behavior are tested, and failed logins are checked in the logs. The client receives a federation test report with pass or fail results for each case and the attribute mapping table.
Configure LDAP group mapping
The team connects the directory, sets the search bases and filters, and maps directory groups to platform roles and project memberships. Group sync runs on a schedule in the test instance, and the mapping is reviewed against the role model so that no directory group grants more access than intended. The output is a group-to-role mapping document and a sync log showing the test directory's groups applied as expected.
Test joiner, mover and leaver cases
Scripted test accounts cover a new hire added to a project group, a transfer that moves the user between groups, and a departure that removes the directory account. The team checks that access is granted, changed and revoked within the expected sync interval, and that existing work items and time entries remain attributed correctly. The client receives a test script, the results for each case and a list of any gaps, such as manual steps for accounts that exist only locally.
Validate break-glass and audit log export
The team confirms a local administrator account that works when the IdP is unavailable, stores its credentials under the client's secrets process, and tests that it can sign in without federation. Audit logging is checked for login, role change and permission change events, and the export path is tested into the client's log store. The client receives a break-glass procedure and a sample audit export. Where the audit log API or export is an Enterprise feature, the client confirms that entitlement before cutover.
Cut over users in waves
The production instance is configured with the tested settings, and users move in groups, starting with a small pilot group, then the remaining departments. After each wave, DeployOpen and the client review sign-in failures, group membership errors and support tickets before the next wave begins. The output is a wave log with dates, user counts and issues, and a sign-off from the client's identity owner that the local login path has been disabled for regular users only after the last wave.
Run the upgrade path with identity checks
Each platform upgrade is first rehearsed on the test tenant, with the SSO and LDAP settings re-verified after the upgrade. The team checks that the directory and federation settings survive the migration, that plugins used for SSO remain compatible, and that the break-glass account still works. The client receives a repeatable upgrade runbook that includes an identity regression checklist, which is run on each future release.
Evidence auditors and regulators ask for on project tool access
This table lists the evidence assessors typically request for project tool access, the component that produces each item, and what the reader should confirm before an assessment. Read each row as a question to answer with a file, export or log, not a control to assume is in place. DeployOpen prepares this evidence for assessors but does not issue audit reports or attestations.
| Evidence | Produced by | What to confirm before an assessment |
|---|---|---|
| Access list by role and group | Directory (LDAP or Active Directory groups) and the platform's role and group membership export | Confirm the platform's role assignments map to directory groups, and that a dated export can be produced for each project and role |
| Federation configuration record | Identity provider (SAML or OIDC application settings) and the platform's SSO configuration | Confirm the signed record of attribute mappings, certificate or client settings, and who approved each change |
| Deprovisioning test results | Directory account disable events, followed by a login attempt against the platform | Confirm a dated test showing that a disabled user loses access to the platform, including sessions and API keys |
| Administrative activity logs | Platform audit log, where the edition provides one, and the reverse proxy or web server logs | Confirm which edition includes API-enabled audit logs, where logs are stored, and how long they are retained |
| Retention of project communications that are business records | Export pipeline or archive that captures comments, notifications and attachments from the platform | Confirm with legal or compliance whether project comments are business records, and which retention period applies |
| Change records for authentication settings | Configuration management records, such as version-controlled config files or change tickets | Confirm that changes to LDAP filters, SSO settings and group sync rules are approved and traceable |
What the per-user difference looks like in practice
The per-user price is only one line in the total. OpenProject Community and Redmine are free software, so the base cost is hosting, implementation and the staff who run the platform. On OpenProject Enterprise on-premises, the list prices are Basic at 5.95 euros, Professional at 10.95 euros with a 25-user minimum and Premium at 15.95 euros with a 100-user minimum per named user per month, with Corporate on request for 250 or more users. Because the minimums apply, a team of 40 that needs LDAP group synchronization may pay for a Professional block of at least 25 seats and still be billed on the tier's terms, so confirm how the minimum is counted before you size the license. Plane lists Pro at 6 to 8 US dollars and Business at 13 to 15 US dollars per user per month, with Enterprise Grid on request. Treat both Plane figures as list prices to confirm with Plane, since they can change and do not include your hosting or implementation.
Recurring costs are the license, the hosting (including PostgreSQL, object storage and any SSO proxy you run), upgrades and the identity work that follows each release. One-time costs are the federation design, the group-to-role mapping, testing with a non-production directory and the cutover. Costs rise with the number of identity sources, the number of groups that must map to project roles, the number of environments (test, staging, production) that need the same integration, and any requirement for separate audit logging. They fall when the directory is clean, groups are already aligned with roles and you can standardize on one identity provider. Redmine avoids the per-seat license but still needs a plugin or reverse proxy for SAML or OpenID Connect, so the plugin's maintenance becomes a recurring line item.
When you request a written quote, ask the vendor or partner to state the edition and feature names that cover SAML, OIDC, LDAP and group sync, the seat count and how minimums and role types are billed, the price currency and tax treatment, and whether the figure is per month or per year. Ask the partner for a separate estimate covering federation setup, group mapping, a test environment, upgrade support and documentation, and ask which items are fixed scope and which are time-and-materials. Confirm in writing that the Enterprise features you need are included in the quoted edition, because a feature listed on a pricing page can sit in a higher tier than the one your seat count implies.
Questions buyers ask about SSO and LDAP for project management
Can Redmine do SAML single sign-on without plugins?
No, not with the core product alone. Redmine authenticates against LDAP natively and supports multiple LDAP sources, but SAML or OpenID Connect single sign-on depends on plugins or on an authenticating reverse proxy placed in front of the application. The choice between a maintained plugin and a reverse proxy changes who owns the logic: a plugin must be tested against each Redmine release, while a proxy moves login and session handling into your existing access layer. Confirm which option your identity team already supports, and check that the plugin supports the Redmine line you plan to run, since 7.0.x is the fully supported line and 6.1.x receives only bug fixes and security updates.
Does LDAP sync require an Enterprise edition on OpenProject and Plane?
Yes, on both platforms LDAP group synchronization sits in the paid tier. OpenProject lists LDAP group synchronization among its Enterprise features, alongside single sign-on through SAML, OIDC, CAS, Kerberos and Okta. On self-hosted Plane, SAML and OIDC are available from the Pro plan upward, while LDAP support is listed as an Enterprise feature. The practical consequence is that you may need a higher tier than you expected once directory sync is mandatory, so confirm the exact feature list for your edition against the vendor's current pricing page before you commit. Redmine is the exception here, since LDAP authentication is native and the software carries no paid edition.
How much effort do federation and group mapping take?
The effort depends mainly on how clean your directory groups are, not on the project tool. Federation requires a registered application in your identity provider, agreed attribute names, and a decision on whether roles in the project tool follow directory groups or stay managed locally. Group mapping is usually the longest step, because nested groups, stale accounts and mixed ownership of group names all need to be resolved before sync goes live. Your identity team needs to supply the identity provider configuration, test accounts for each role, a named owner for group membership, and a change window for the cutover. Ask any implementation partner to list those inputs in the written scope so that the effort is visible before work starts.
Can our own team configure SSO and LDAP without a partner?
Your team can do it if it already runs the identity provider, has administrator access to the project tool, and has time to test edge cases. The work is mostly configuration rather than custom code, but it touches authentication, so errors affect everyone who signs in. Teams that choose to do it alone should plan a staging environment, test fallback administrator accounts, and document how group changes propagate. A partner is most useful when the identity landscape is complex, when several tools must share one login, or when the team lacks someone who has delivered federation before. Either way, the written plan should show who makes each change and who signs off the production switch.
How long does an SSO and LDAP rollout take?
Timing depends on scope, and the only dependable figure comes from the written plan agreed before work starts. The main variables are the number of identity sources, how many groups need mapping, whether the project tool is hosted in your infrastructure or a managed environment, and how many test cycles your identity and security teams require. Edition changes add time when a licence upgrade or a switch between Plane editions is involved, because a self-hosted Community install must first move to the Commercial Edition before a paid plan can be activated. Ask for milestones, test exit criteria and the dependencies on your team, and treat any date given without those as provisional.
Can a free edition meet SSO and LDAP requirements?
It depends on which requirement is mandatory. Redmine is free under GPL v2 and authenticates against LDAP natively, so directory-based login is available without a licence fee, although SAML or OIDC needs a plugin or reverse proxy. OpenProject Community is free but does not list SSO or LDAP group synchronization among its features, which sit in the Enterprise tier. Plane Community is licensed under AGPL-3.0 and matches the feature set of the Cloud Free tier, so SAML, OIDC and LDAP should be checked against paid plans before you assume they are available. Your cost then comes from hosting, plugin maintenance, upgrades and the staff who run the system, so compare the total against the per-user price of the paid tier.
Questions to ask an implementation partner before signing
Start with the edition question, because it decides what the partner can build. Ask which edition they recommend for your SSO and LDAP requirements and why, and make them name the specific features: SAML or OIDC, LDAP group synchronization, and audit log export. For OpenProject, those features sit in Enterprise plans. For Plane self-hosted, SAML and OIDC start at Pro, while LDAP and API-enabled audit logs are Enterprise features. For Redmine, ask which plugin they would use for SAML or OpenID Connect and who maintains it after go-live. Ask them to show the license or subscription path in writing, with the seat count they assumed.
Next, ask how the identity wiring will be tested and who keeps the break-glass path. Ask for the exact settings they will configure, such as the identity provider metadata, redirect URIs, group claim mapping and LDAP bind account, and for a test plan that covers a successful login, a denied login, a user in a restricted group and a forced logout. Ask how local break-glass administrator accounts are created, stored, protected with a second factor where the platform supports it, and tested on a schedule. Then ask how deprovisioning is verified: disable a test user in the directory and confirm that access ends in the application and that any API keys are revoked. Ask which audit logs are exported, in what format, to which log store, and how long they are retained.
Finally, ask how upgrades affect the identity configuration and what the team will learn. Request a written statement on whether SSO and LDAP settings survive each upgrade, which settings need retesting, and whether a staging environment is included. Ask what training the identity and administration teams receive, who delivers it, and whether it covers edition-specific settings. Most importantly, request a written scope and acceptance criteria before work begins. The document should list each SSO and LDAP function, the test cases that prove it works, the sign-off roles, and what happens if a test fails. Fixed scope in writing is the basis for comparing partners.
How DeployOpen scopes and supports identity integration
How does DeployOpen scope an SSO and LDAP project?
DeployOpen scopes identity integration in a fixed-scope written plan that is agreed before work starts. The plan names the platform and edition, the identity provider or directory in use, the protocols (SAML, OIDC or LDAP), the groups and roles that must map to project permissions, and the environments involved. It also lists deliverables and timelines, so you can check what is covered before you sign. Ask for the plan to state which edition the work depends on, because SSO and LDAP sync features sit behind Enterprise tiers on some platforms.
Where does DeployOpen implement federation and directory sync?
DeployOpen implements federation and directory sync inside your own infrastructure, including your cloud accounts, data centers or air-gapped networks. That covers the identity provider trust, the SAML or OIDC client configuration, LDAP bind accounts, group synchronization and the reverse proxy settings where a platform relies on one. Secrets, certificates and service accounts stay under your control. Confirm with your team who owns the identity provider, because the integration depends on their change process and on the directory schema they run.
How are joiner, mover and leaver flows tested?
DeployOpen tests joiner, mover and leaver flows as part of the written scope. A joiner test confirms that a new account is created or provisioned and lands in the correct project groups. A mover test checks that a change of department removes old permissions and adds new ones. A leaver test confirms that a disabled directory account can no longer sign in, and that API keys and sessions are handled as the plan describes. Ask for the test cases in writing, with expected results and the accounts used, so your security team can repeat them later.
What evidence does DeployOpen prepare for an assessor?
DeployOpen prepares systems, controls and evidence for compliance assessments, such as configuration records, access-control settings, test results for joiner, mover and leaver flows and descriptions of how group mappings are maintained. DeployOpen does not issue audit reports, attestations or certifications. Independent auditors and certification bodies make those determinations. Ask your assessor early which evidence they expect, such as audit log exports or change records, and confirm whether the platform edition you choose provides those logs.
Does DeployOpen offer ongoing support after SSO goes live?
DeployOpen offers retainers for upgrades and ongoing support, which cover work after the initial rollout. For identity integration, this matters because SAML and OIDC settings, certificate rotation, LDAP schema changes and platform upgrades can all break sign-in. Retainer scope is agreed in writing, like the original project. Ask what response arrangements are included, how upgrades are tested against your identity configuration, and who your contact is when an identity provider changes. Do not assume support terms until they appear in the written agreement.
Can our own team handle SSO and LDAP setup without a partner?
Your team can handle SSO and LDAP setup without a partner if it has staff who know your identity provider, directory and the chosen platform's configuration. The work usually includes certificate handling, group mapping, testing sign-in across roles and documenting the result. The cost of doing it internally is staff time and the risk of errors in a security-sensitive area. Ask yourself whether those people will still be available for upgrades, and whether they can produce the evidence an assessor will request. A written scope lets you compare an internal effort with a partner quote on the same terms.
What does DeployOpen need from our side to start?
DeployOpen needs access to the environment where the work will run, the platform edition you have selected, and named contacts for the identity provider and directory. It also needs the group structure you want to map to project roles, your certificate and secret handling rules, and the test accounts that will be used. Gaps in these inputs usually delay the written plan, so ask for an intake checklist at the start. Confirm which of these items are available before the scoping call so the plan reflects your actual environment.
