How OpenCTI SSO changes who signs in and what they can see
A team that runs OpenCTI with local accounts usually starts identity work for one reason: the identity provider should decide who can get in and, just as important, what they can see once inside. OpenCTI SSO is configured through authentication strategies, such as SAML, OpenID Connect or LDAP, and the role and organization mapping you define decides data visibility. Those two decisions shape the project more than the login screen does. Identity work is harder than it looks because the login step is the easy part. Once users authenticate through the identity provider, OpenCTI still needs to know which platform role each person receives and which organization they belong to. Group mapping translates identity provider groups into OpenCTI roles, so an analyst group and an administrator group must not collapse into one. Organization-based segregation then controls which intelligence each user can read, and it needs the same planning as the group design. Treat these as one access model, written down before you change any login settings. Authentication strategies and some of the access features described here are Enterprise Edition capabilities. Since OpenCTI 7.260224.0, defining and using authentication strategies, including SSO, requires the Enterprise Edition, and organization-based data segregation is listed among its features. Confirm the license scope with Filigran before you design around these features, and check which strategy types your chosen edition supports in your own environment. This page assumes a running OpenCTI deployment. It does not repeat sizing, dependency setup or installation, which are covered in the platform sizing and implementation sections. Your first practical steps are to inventory the current local accounts, list the identity provider groups that should map to OpenCTI access, and identify which intelligence sets need separate organizations. Test the mapping with a small set of accounts in a non-production instance before you change production sign-in. Before cutover, plan for the local accounts that will remain. Keep at least one break-glass administrator path that works if the identity provider is unavailable, and document who can use it and how access is logged. Expect some users to lose access they had under local accounts, because group membership now controls visibility, so ask the business owners of each intelligence set to confirm who should see what before go-live.
Choosing an OpenCTI SSO protocol: SAML, OpenID Connect or LDAP
This table compares SAML, OpenID Connect and LDAP against your existing identity provider, how each exposes group claims, who maintains the directory, and the upkeep each option creates. Read each column as the work your team carries after go-live, including setup effort. Exact settings change between releases, so confirm each option's parameters in the current OpenCTI authentication documentation before you commit.
| Decision factor | SAML | OpenID Connect | LDAP |
|---|---|---|---|
| Licensing | Enterprise Edition feature since 7.260224.0 | Enterprise Edition feature since 7.260224.0 | Enterprise Edition feature since 7.260224.0 |
| Best fit | Enterprise identity provider that issues signed assertions to applications | Identity provider that can register OpenCTI as an OpenID Connect client | Directory you already run as the source of truth for user accounts |
| Group claims | Groups arrive as attribute statements. Confirm the attribute name and value format with your identity provider. | Groups arrive as token or userinfo claims. Confirm the claim name, scopes and whether groups appear by default. | Groups come from directory lookups at login, so group search filters determine membership. |
| Who maintains the directory | Identity provider team maintains users and groups. OpenCTI trusts the assertions it receives. | Identity provider team maintains users, groups and the client registration. | Directory team maintains accounts. OpenCTI queries the directory directly. |
| Credentials OpenCTI holds | Identity provider signing certificate and service provider settings. Users authenticate at the identity provider. | Client ID and client secret for the registered application. | Bind account credentials that let OpenCTI search the directory. |
| Recurring upkeep | Rotate signing certificates before expiry. Track metadata changes and clock alignment. | Rotate and store the client secret securely. Track issuer, endpoint and redirect URI changes. | Rotate bind account passwords, tune search base and filters, and maintain directory TLS certificates. |
| Common failure | An expired certificate or mismatched entity ID blocks SSO logins for all users. | A wrong redirect URI or an expired client secret breaks logins for all users. | Broad or slow searches and a locked bind account delay or block logins. |
| Choose it when | Your identity provider is SAML-based and group attributes are already maintained for other applications. | Your identity provider supports OpenID Connect clients and you want group claims in tokens. | The directory is authoritative and your team accepts ongoing query tuning and bind account management. |
How to configure OpenCTI SSO in the right order
This sequence moves OpenCTI from a working local-login install to single sign-on without locking out administrators. Each step ends with a check you can record, so the team can confirm the identity provider, the platform and the recovery path agree before local login is removed.
Confirm the edition, license and release line
Confirm that your deployment can use SSO. Since OpenCTI 7.260224.0, defining and using authentication strategies, including SSO, is an Enterprise Edition feature, so the Community Edition cannot complete this sequence. If you run an LTS release, check that your license key covers that LTS line. Record the exact version you are configuring against so every later check refers to the same build. This step is done when the platform reports an Enterprise license and the version is written into your change record.
Register OpenCTI as a client in the identity provider
The identity team creates an application or client for OpenCTI in the identity provider. For SAML or OpenID Connect, record the client identifier, the secret or certificate exchange method, and the attributes or claims the platform will receive. For LDAP, confirm the bind account, search base and attribute names instead. Keep the identity provider administrator involved, because they own token lifetimes and signing settings. This step is done when a test sign-in from the provider's own portal returns the expected attributes.
Set redirect URLs to the public address
Set the callback or redirect URL in the identity provider to the exact public address users type into the browser, including scheme and path. A mismatch is a common cause of failed sign-in, and it is easy to miss when a load balancer or reverse proxy rewrites hosts. If you run several platform nodes, every node must present the same public address and share the same SSO settings, so a user is never sent to a different configuration partway through sign-in. This step is done when a browser test from the public address completes the redirect without an error page.
Define the authentication strategy in OpenCTI
An Enterprise administrator enters the protocol settings in the platform's authentication configuration, using the values recorded in the registration step. Apply identical values on every platform node, including the strategy name, the identifiers and the attribute or claim names. Do not enable the strategy for all users yet. This step is done when the strategy appears in the authentication settings and each node returns the same configuration when checked one by one.
Map groups and claims to roles and organizations
Decide which identity provider group or claim maps to which OpenCTI role and organization, and write the mapping as a table the security and analyst leads both approve. Confirm in the token or directory response that the group value is actually present before relying on it in the mapping. Organization-based data segregation is an Enterprise capability, so confirm how your release applies organization membership before you design access around it. This step is done when a test user's token or directory response shows the expected group value and the platform assigns the matching role.
Test sign-in with a non-admin account
Sign in with a standard user from a group mapped to a restricted role, not with an administrator. Confirm that the user reaches the platform and can see only the data their organization and role allow. Record one failed attempt, if you produce one, with its cause, because the log of a failure is useful evidence for the runbook. Keep the local administrator account active during this step, so that a mapping error can be corrected from inside the platform. This step is done when a successful login and the expected permissions are both recorded for the test user.
Verify a break-glass admin before restricting local login
Confirm that a named break-glass administrator account can sign in with local credentials on every platform node. Store its credentials under your normal privileged access process, with access limited to the people who would need them during an identity outage. Test the login itself, not only the existence of the account, because a stored password that no longer works is discovered at the worst time. This step is done when a break-glass login has been tested on each node and the result is recorded.
Restrict local login and document recovery
Disable local login only after the break-glass check has passed. Write a recovery runbook that states how to re-enable local login, who holds the break-glass credentials, how to roll back the strategy, and who approves a rollback. Ask someone other than the author to walk through the runbook against a non-production environment if you have one, since gaps are easiest to find that way. This step is done when the runbook has been reviewed and the restricted configuration is recorded as the approved baseline.
Why SSO now needs the Enterprise Edition license
Since OpenCTI 7.260224.0, defining and using authentication strategies, including SSO, is an Enterprise Edition feature. The Community Edition is licensed under the Apache License 2.0, which covers the open-source code, but it does not cover SSO on releases from that point forward. Any identity design that assumes a SAML, OpenID Connect or LDAP login on the Community Edition needs to be revisited before the architecture is approved. Confirm the first release in your plan that includes this change, and check whether your current install is already on a newer release. The release line you choose changes the licensing answer. OpenCTI uses regular releases numbered x.YYMMDD.z and LTS releases numbered x.YYMMDD.z-lts.n. LTS releases are distributed as container images but require a specific LTS license key to run. That means an Enterprise Edition license for SSO does not automatically cover an LTS build, and an LTS key does not automatically cover every regular release. Ask Filigran which license keys apply to the release line you intend to run, and whether the SSO feature set is identical on that line.
Ask Filigran whether a trial or free license fits your use case before you commit to a design. Filigran offers trial licenses, and free licenses for development, research and non-governmental organizations. Those categories do not tell you whether a production identity integration for a security operations team, a pilot or a shared lab qualifies. Get written answers on eligibility, the trial length, what happens to your SSO configuration when a trial ends, and whether a free license can be used alongside a paid environment. The Enterprise Edition documentation also needs a close read for your delivery model. Filigran offers the Enterprise Edition on premises or as SaaS, and the license terms may differ between the two. Confirm how the license key is applied in your environment, whether it can be validated in an offline or air-gapped network, and who is responsible for renewing it. Also confirm whether LDAP and local user accounts fall under the same license gate as SAML and OpenID Connect, because the feature wording covers authentication strategies in general.
Treat licensing as a scope item, not a late procurement step. List the Enterprise Edition license, the LTS key if you plan to use LTS, and any trial or free license terms in the statement of work and in your architecture decision record. In a quote, ask which costs are one-time and which recur, how renewals are priced, and what changes if you move from on-premises to SaaS or from a regular release to an LTS line later. Those answers determine whether an SSO integration remains supported through the period your organization plans to run it.
What drives OpenCTI SSO effort and cost
This table lists the factors that change how much work OpenCTI SSO takes and who carries each part of it. Read each row as a driver, then check who pays for it in your organization and which reduction step applies. The main takeaway is that naming groups consistently and limiting the number of identity paths usually reduces effort more than any single technical setting.
| Driver | Why it changes effort or cost | Who usually pays | How to keep it down |
|---|---|---|---|
| Number of identity providers and strategies | Each SAML, OpenID Connect or LDAP strategy needs its own configuration, certificate or client secret handling, and test cycle. Local users and client certificate paths add further review. | Internal identity team for IdP setup; OpenCTI admins for strategy configuration; partner if the work is scoped as an integration project | Standardize on one primary identity provider for analysts and limit fallback strategies to documented break-glass accounts |
| Number of groups and organizations mapped to roles | Every group that must map to an OpenCTI role or organization segregation boundary adds a mapping rule to design, test and review. Unclear ownership of groups multiplies the review cycles. | OpenCTI admins and data owners decide the mapping; identity team creates or confirms the groups | Adopt one group naming scheme that encodes platform, role and organization, and agree the mapping table before configuration starts |
| Whether the identity team must change claims or attributes | If the identity provider does not send the group or organization claim in the form OpenCTI expects, the identity team must add attribute mappings or claim transforms, which requires change control on their side. | Internal identity team, which owns the IdP configuration and its change process | Confirm the claim names and formats with the identity team before design, and ask whether existing directory groups can be emitted without new transforms |
| Number of environments (test, staging, production) | Each environment needs its own redirect URIs, client registrations or test accounts, and a separate pass through the mapping tests. Drift between environments causes repeat work. | Internal identity team for registrations in each environment; OpenCTI admins for validation | Use one test environment that mirrors production identity settings, and promote configuration as code or documented settings rather than rebuilding it |
| Air-gapped or restricted network paths to the identity provider | Restricted egress, private IdP endpoints or air-gapped networks require firewall rules, proxies, or a directory replica inside the boundary. Each path needs its own approval and testing. | Infrastructure or network team for paths and approvals; internal identity team for any replica; partner for design support where scoped | Document required flows (metadata, token, directory queries) before requesting firewall changes, and reuse an existing approved path where possible |
| Need for evidence for access reviews | Access reviews require exported role assignments, group membership snapshots and change records. Building these outputs after go-live takes more effort than planning them during design. | OpenCTI admins for role evidence; compliance or GRC team for review criteria; partner if evidence design is in scope | Agree the review report format, owner and frequency during design, and confirm that audit logs and group records cover the periods the reviewers need |
Mapping groups and organizations to roles and data segregation
Group mapping decides two things for every signed-in OpenCTI user: what they can do in the platform, and which entities and intelligence they can see. The identity provider supplies group membership or claims, OpenCTI maps those values to roles and capabilities, and organization-based data segregation then limits what each user can read. These are separate decisions, but they usually come from the same identity data, so design them together. Organization-based segregation is an Enterprise Edition feature, and SSO itself requires that edition, so this mapping only applies to deployments licensed for both. Before you build it, ask Filigran which mapping fields the current release accepts, including the claim name, the group value format and how an organization is assigned.
The mapping should be designed with data owners, not only the identity team. The identity team knows group names and directory structure, but the data owners know which sources, sectors and partner sharing agreements require separation. Ask each owner to approve which groups may reach which organizations and which roles those groups receive. A group that grants access to a sensitive organization should be reviewed like any privileged role: name an accountable owner, require approval for new members, recertify membership on a fixed schedule and keep an audit trail of changes. Illustrative example: a partner liaison group added for one sharing agreement quietly inherits read access to another sector's indicators because nobody checked the organization assignment.
Confirm three behaviors in the current release before relying on the design. First, the exact mapping fields and whether a single user can match several groups with conflicting roles or organizations, and which result wins. Second, the default role for a new user who authenticates but matches no mapped group, since some deployments deny access by default and others provide a baseline account. Third, how a removed group member loses access: whether it takes effect at the next login, when a session expires, or immediately, and whether existing sessions or API tokens continue to work. Record the vendor's answer for each point, and check it against your own environment because settings and defaults can differ by version.
Test all of this with sample accounts before go-live. Create test users in the identity provider for each case: no group, each role group, a group tied to one organization, a user in two groups with overlapping access, and a user removed from a group that previously granted access. For each account, log in through the UI and confirm what is visible, then run the same queries through the GraphQL API to check whether API tokens follow the same rules. Compare expected and actual results, fix mismatches and keep the test record as evidence for your access review. Service accounts used by connectors need their own mapping and a separate test, so include them in the plan.
Securing OpenCTI logins, sessions and identity secrets
The identity integration creates a small set of trust relationships: client secrets, signing and encryption certificates, redirect URLs and the accounts that remain when the identity provider is unavailable. Each card below covers one of these, with the checks to confirm before cutover and the ongoing ownership they require.
OIDC client secrets and their lifecycle
For OpenID Connect, the client secret lets OpenCTI exchange authorization codes with the identity provider, so anyone holding it can impersonate the application. Confirm who creates the secret, where it is stored (a secrets manager or the platform's environment configuration, not a repository), and how it is replaced without a long login outage. Record the expiry date the identity provider assigns, if it assigns one.
SAML signing and encryption certificates
SAML integration involves a service provider certificate, if request signing or assertion encryption is used, and the identity provider's signing certificate, which OpenCTI must trust to validate assertions. Confirm which certificate each side presents, the key length and algorithm your policy requires, and whose calendar tracks expiry. A certificate that expires silently is a common cause of a total login failure.
Metadata exchange and trust verification
Metadata is the document each side uses to learn the other's endpoints, entity identifiers and certificates. Decide whether metadata is imported as a file or fetched from a URL, and who approves each change. After any exchange, verify the entity ID, the assertion consumer URL and the certificate fingerprint against the identity provider's own record before testing a user login.
Secret storage and rotation ownership
Identity secrets sit in several places: the OpenCTI configuration, container orchestration secrets, the identity provider console and backup archives. Map each location, restrict read access to the operators who need it, and keep backups from carrying live secrets in plain text. Name one owner per secret and a rotation procedure that is tested in a non-production environment first.
Consistent redirect URLs across environments
Identity providers match the callback URL exactly, including scheme, host, port and path. A mismatch between the public address, an internal address used by a reverse proxy or a test environment produces errors that look like credential problems. Register every intended URL in advance, avoid wildcard callbacks where the provider allows exact values, and confirm the URL OpenCTI generates behind your proxy.
TLS on the public OpenCTI address
Identity redirects and tokens travel through the browser and the reverse proxy, so the public OpenCTI address must present a valid certificate chain that the identity provider and users trust. Confirm the certificate's subject names match the registered redirect host, that intermediate certificates are served, and who renews it. Check that the identity provider's own endpoints also use current TLS.
Local account restriction after SSO proof
Local users remain available after SSO is enabled, which creates a second login path that bypasses the identity provider's controls such as multi-factor policy and account disablement. Once SSO is proven for every role, plan to restrict or disable local accounts, and document the exception process. Confirm which accounts stay active and who approves any reactivation.
Break-glass administrator outside the identity provider
Keep one administrator account that does not depend on the identity provider, so the platform stays manageable during an identity outage or a misconfigured SAML or OIDC setting. Store its credentials offline or in a vault with dual control, enable strong authentication, and test the sign-in path on a schedule. Log every use and review each one, since this account bypasses normal governance.
Proxy headers and client certificate trust
If proxy header or client certificate strategies are used, OpenCTI trusts identity values supplied by an upstream component. Confirm that only the reverse proxy can set those headers, that inbound requests cannot forge them, and which header or certificate attributes map to the user identity. Document the trust boundary and the change process, because a misconfigured proxy can grant access without a password.
OpenCTI SSO questions buyers ask before hiring help
Can OpenCTI Community Edition use SSO without an Enterprise license?
Not for SSO in current releases. Since OpenCTI 7.260224.0, defining and using authentication strategies, including SSO, is an Enterprise Edition feature, according to the OpenCTI authentication documentation. The Community Edition is licensed under Apache License 2.0 and keeps local user accounts. The authentication documentation lists LDAP among supported strategies, but confirm which strategies each edition can use in the current documentation before you plan. Check the exact version you run, because the license gate applies from 7.260224.0 onward. Filigran offers trial licenses, which let your team test SSO in a non-production environment first. A written scope should name the edition and license so the SSO work does not start on a build that cannot use it.
How long does OpenCTI SSO integration take to implement?
The supplied material does not give a duration, so ask for one in the written scope. The effort depends on how many identity providers you connect, whether you use SAML, OpenID Connect or LDAP, and how many groups must map to roles and organizations. Each additional OpenCTI environment, such as test, staging and production, repeats configuration and testing. Data segregation design adds time when organizations must be separated, because each group-to-organization rule needs review by its data owner. Response times from your identity team for metadata, client registrations and test accounts also affect the calendar. Ask the provider to break the estimate into discovery, configuration, testing and handover, and to name which steps depend on your team.
What must our team provide for an OpenCTI SSO project?
The work moves faster when your team prepares these items before the first working session:
Provide:
- Administrative access to the identity provider, or a named contact who can make changes during testing
- Metadata or client registration details for the chosen protocol
- A group design, approved by the people who own access decisions, that lists which groups map to which OpenCTI roles and organizations
- Test accounts in each group, including one account with no group membership
- Sign-off from data owners for any organization-based data segregation
- Enterprise Edition license details and an OpenCTI administrator account
- A non-production environment for testing before changes reach production
If any of these are missing, the schedule should reflect the wait, and the written scope should say who is responsible for each item.
Can an internal team set up OpenCTI SSO without outside help?
Yes, for a simple setup with one identity provider and a small group model, provided the team has OpenCTI administration experience and reads the authentication documentation for its exact version. Harder cases include several identity providers, nested or overlapping groups, and many organizations that need separation. Verification should cover these steps:
- Sign in with a test account from each group and confirm the assigned role
- Confirm that an account with no group membership is denied access
- Confirm that users see only the organizations they are permitted to see
- Confirm that a local administrator account still works as a break-glass path
- Test logout and session expiry
- Review audit logs for the login and role events, which are an Enterprise Edition feature
- Repeat the tests after each OpenCTI upgrade and after any identity provider change
Which protocol should we pick for OpenCTI SSO: SAML, OpenID Connect or LDAP?
The identity provider you already run usually decides this. If your directory or identity platform supports SAML or OpenID Connect, those options follow modern federation practice and are listed among OpenCTI's supported authentication strategies. LDAP suits organizations that authenticate against a directory and do not have a federation service, but it requires direct directory connectivity from the OpenCTI platform. Before choosing, confirm three things in the current OpenCTI authentication documentation: which strategies your edition supports, what user attributes or group claims each strategy passes, and how the platform handles group membership changes after sign-in. Ask your identity team which group attributes they can release, because mapping depends on that data. Record the decision and its reason in the written scope.
What does a fixed-scope OpenCTI SSO engagement cover?
A fixed-scope engagement covers the work listed in a written scope agreed before work starts. Scope, deliverables and timelines are set in writing, so ask the provider to list each one. A typical SSO scope names the edition and license check, the chosen authentication strategy, the group-to-role and group-to-organization mapping, testing with your accounts, the documentation of the final configuration, and a handover to your team. DeployOpen plans, configures, integrates, documents and supports open-source platforms in your infrastructure, and it prepares evidence for compliance assessments. It does not issue audit reports, attestations or certifications, which independent auditors provide. Changes after handover, upgrades and continuous support fall outside a fixed scope and can be covered by a retainer.
What usually goes wrong in OpenCTI SSO and group mapping?
Most failures trace back to a mismatch between the identity provider and the platform. The common causes are:
- Group claim names differ from what the mapping expects, often because of case or prefix differences
- The identity provider does not release group attributes in the token or assertion
- Redirect URIs or callback URLs do not match the registered client settings
- A user belongs to several groups with conflicting roles, and the precedence rules were never defined
- A default role is more permissive than intended for users with no group
- Certificates or client secrets expire without a renewal owner
- Users keep access after leaving a group because the change did not reach the platform
Check these items during testing, and assign an owner to certificate renewal and group review.
How DeployOpen works on this
DeployOpen scopes OpenCTI SSO as a fixed-scope piece of work inside your own infrastructure, with the identity provider, license position and role model agreed in writing first. The build is tested against your identity provider in a non-production instance, and the handover records how logins, groups and organizations map to access.
How we scope
- The written scope names each identity provider and protocol in use: SAML, OpenID Connect or LDAP.
- Scope confirms SSO is covered by an Enterprise Edition license, and who holds and pays for that license.
- Engagements are fixed-scope, so deliverables, timelines and acceptance tests are agreed in writing before work starts.
How we build
- Configure the chosen authentication strategy in a non-production OpenCTI instance before touching production.
- Map identity provider groups and organizations to OpenCTI roles and organization-based data segregation rules.
- Test login, logout, group changes and admin fallback access, and record each result against the agreed acceptance tests.
How we hand over
- Deliver a configuration record covering strategy settings, attribute mappings, group-to-role rules and named owners.
- Document the break-glass access procedure and who may change identity provider mappings after handover.
- Walk your identity and platform teams through role changes, troubleshooting steps and audit log review.
How we support
- Retainers cover ongoing support, upgrades and continuous testing, including re-testing SSO after each OpenCTI upgrade.
- Re-check mappings when identity provider groups change or when staff move between teams or leave.
- Agree with your identity team who owns certificate and client secret rotation, and how it is scheduled.
