How MISP SSO works and why the account linking step decides its safety
MISP can log users in through an OpenID Connect identity provider using the OidcAuth plugin, and the difficult part is deciding how an incoming identity is matched to a MISP account and which roles it receives. The matching step must not let a person who controls one identity take over an existing local account. MISP 2.5 is the recommended version for new deployments, so build the integration on that line, since MISP 2.4 is end of life and receives security fixes only.
When a user signs in, the identity provider returns claims about that person, and the plugin uses them to find or create a MISP user and assign roles. The OidcAuth plugin maps identity provider roles to MISP roles and assigns the first matching role by priority. This means the order of your mapping rules decides what a user gets when they belong to several groups. Before go-live, list every identity provider group that can reach MISP, then test a user from each group and confirm the role they receive is the one you intended.
Four configuration choices carry most of the security weight. The first is the identifier, meaning the claim MISP uses to recognize a returning user. Email addresses can change or may not be verified by every provider, so a stable subject identifier is usually the safer choice, but confirm in the plugin documentation what it matches on and whether it links to existing accounts by email. The second is roles, the third is organization assignment, and the fourth is the local fallback. Decide whether accounts are created automatically on first login, and whether a protected local administrator account stays available for recovery and is tested.
This page covers identity integration only. Synchronization with partners, feeds, sharing groups and general hardening are covered on separate pages, so treat them as out of scope here. Before you commit to a configuration, confirm with your identity provider team which claims are verified and how group membership is issued. Then run the account linking test cases in a staging instance that mirrors your production configuration. Ask any implementation partner for a fixed-scope quote that lists those test cases, the number of identity provider groups in scope, and who verifies the results.
Which SSO design fits the team's identity model
This table compares the main decisions for connecting MISP to an OpenID Connect provider through the OidcAuth plugin. Read each row as a choice you must make before configuration, then check the operational cost against how often your teams and partners change.
| Decision | Option | When it fits | Operational cost |
|---|---|---|---|
| User identifier | Stable subject claim from the IdP | Most deployments, because the subject does not change when an email address does | Lowest risk. Confirm with your IdP which claim is stable and unique per user |
| User identifier | Email claim used to link accounts | Only where email is verified, unique and controlled by your IdP, and existing local accounts must be matched | Higher risk of account takeover or linking to the wrong person if email is reassigned or unverified |
| Roles | Mapped from IdP groups | Teams already manage access through groups and want role changes to follow group membership | Mapping rules need upkeep whenever groups are renamed or new roles appear. Plugin assigns the first matching role by priority, so review order |
| Roles | Assigned inside MISP | Small teams or a few administrators who prefer direct control over MISP permissions | Admin workload grows with each joiner, mover and leaver, and access can drift from the IdP record |
| Organization | Derived from claims | Organizations map cleanly to IdP attributes or groups and change rarely | Mapping logic must be tested for each new partner or community. Misplaced users may see the wrong sharing data |
| Organization | Set manually in MISP | Few organizations, or sharing relationships that are decided case by case | Support load when a user changes teams, because someone must update the organization by hand |
| Local accounts | Kept as break-glass admin path | Almost always, so administrators can recover access if the IdP or SSO configuration fails | Requires a tested, documented and protected local admin login, reviewed on a schedule |
| Identity providers | One trusted IdP | Single directory or one federation covers all users | Simplest trust model and one place to review login policy |
| Identity providers | Several trusted IdPs | Partner organizations or communities authenticate with their own directories | Each IdP needs its own claim, role and organization rules, and a review when a partner changes its directory |
Build sequence for OidcAuth with MISP 2.5
This sequence connects a MISP 2.5 instance to an OpenID Connect identity provider with the OidcAuth plugin. It ends with a tested login path in which each identity provider group lands in the intended MISP role and organization, and local password login is limited once that is verified.
Confirm MISP and plugin versions
Start by recording the MISP release on the server and the OidcAuth plugin version it includes. Read the plugin README on the 2.5 branch, because setting names and supported options follow that document and must match the version you install. The platform team or the owner of the MISP host does this work. The project's download page identifies 2.5 as the recommended line for new deployments, so confirm that your target is on that line. Done when the version pair and the README revision are written into the change record and match the staging host.
Register a confidential client
In the identity provider, create an OpenID Connect client of the confidential type, so MISP holds a client secret and uses the authorization code flow. Set the redirect URI to the exact callback address described in the README, built from the MISP base URL, including the scheme, host and path, with no wildcards. Store the secret in your secrets manager and keep it out of shared configuration files. Done when the client exists, the redirect URI matches character for character, and a test authorization request returns to MISP with a code.
Point the plugin at the provider
Enter the provider's discovery endpoint, the client ID and the client secret in the OidcAuth settings, using the setting names listed in the README for your plugin version. Confirm which claim the plugin uses to match an incoming login to an existing MISP user. Choose a stable subject identifier, and make sure email addresses are not used for matching, since users can change them. Check that the requested scopes include every claim your role mapping needs. Done when a test login reaches the provider and a decoded ID token shows the expected issuer, audience and claims.
Define the role mapping and priority
List every identity provider group that should reach MISP, then map each group to one MISP role. The plugin assigns the first matching role by priority, so order the rules from the most privileged role to the least privileged. Decide what happens to users who belong to no mapped group, either a documented default role or denied access. Keep the mapping in version-controlled configuration so reviewers can see every change. Done when a test token for a user in each group shows the expected group claim, and the mapping resolves to the intended role when checked against the mapping table.
Set organization assignment rules
Decide how each user is placed in a MISP organization: from a claim, from a group, or from a fixed value per group. Confirm which of these options the README on the 2.5 branch supports before you commit to one. Tie organization assignment to the same groups that drive roles, so a user's role and organization always come from the same source. Record who owns each organization and who may change the mapping. Done when a reviewer can trace every mapped group to one role and one organization, and a user with no organization claim is refused or sent to an approved default.
Create and test a pilot account
Choose a small pilot set of staff users, one per mapped group. Have each pilot user sign in through the provider so the plugin creates or links the MISP account on the login path. An administrator then checks the resulting role, organization and sharing permissions in the MISP user administration pages, and reviews the authentication log for each login. Remove one pilot user from a group in the provider and confirm the access change at the next login. Done when every pilot user lands in the intended role and organization.
Limit local password login
After the mapping passes the pilot, decide which MISP accounts keep local password login. Keep one break-glass administrator account with a stored credential, and document who may use it and under what conditions. Disable or restrict password login for all other accounts, using the setting names in the plugin README and the MISP authentication options for your version. Record the change in the change log. Done when a standard user is refused password login, the break-glass account works in a controlled test, and the settings change is confirmed in the admin view.
Why linking accounts by email claim is an account takeover risk
Linking an incoming OpenID Connect login to an existing MISP user by matching the email claim is an account takeover risk, and the exposure is greatest when the matched account holds administrator or sync privileges. An identity provider (IdP) asserts an email address, but that assertion is only as trustworthy as the IdP's enrollment and verification processes. If a party can register or control an address that matches an existing MISP user's email, a naive auto-link can attach their login to that account. The attacker then inherits the account's organization, role, sharing groups and API key access, which in MISP can mean reading restricted events or changing distribution settings for the whole instance.
The safer design keys each MISP identity on two values together: the issuer (the IdP that vouched for the user) and the stable subject identifier (the sub claim, which the provider does not reassign to another person). Email is then treated as a contact attribute, not as the identity key. Where the provider asserts that an email is verified, that assertion can be checked before any email-based decision is made, and unverified emails should never drive matching. Auto-linking into administrator accounts, sync users and any account that carries broad sharing permissions should be blocked outright, so that a privileged account can only be bound to an identity through a deliberate administrative action.
Pre-existing local accounts need a one-time migration step rather than silent matching at first login. A typical approach is for an administrator to export the list of accounts to be migrated, confirm each mapping against the IdP's subject identifier for the correct person, and record the binding. Accounts with no confirmed match should remain local until someone resolves them. This step is the point where a mistaken or malicious match is most likely to be caught, so it should be logged and reviewed by someone other than the person performing it.
Before go-live, confirm how the OidcAuth plugin keys users. Read the README for the version you deploy on the 2.5 branch and check whether user lookup uses the subject identifier, the email, or both, and whether there is an option to disable email-based matching. Do not assume a setting is enabled or disabled by default. Test the behavior with a non-privileged test account on a staging instance: register a second IdP identity with the same email, attempt login, and confirm it is rejected or creates a separate account. Ask your implementation partner to document the chosen keying in the configuration baseline so that upgrades do not silently change it.
What drives SSO effort and how to keep it contained
This table lists the factors that move effort and cost in a MISP OpenID Connect integration, with the containment step for each. Read it as a checklist: the rows that carry the most weight are usually the role model and the count of existing local accounts. Each containment step is a scoping decision you can make before a quote is requested.
| Driver | Why it changes effort | How to keep it down |
|---|---|---|
| Identity providers and tenants | Each provider or tenant adds its own client registration, redirect URI, claim behavior and test users, and each must be checked separately. | Start with one provider per MISP instance. Confirm with your identity team whether any second tenant is truly needed before scoping it. |
| Group-to-role model | Every IdP role or group must map to one MISP role by priority, so more groups mean more mapping rules and more test cases. | Begin with a small set of roles such as read-only analyst, publisher and administrator. Add roles only when a documented business need appears. |
| Organizations and sharing communities | Role decisions affect which organization a user belongs to and which events they can see or publish to partner communities, so errors have wider impact. | Map each identity group to one organization where possible. Review sharing community membership with the data owner before the mapping goes live. |
| Existing local accounts | Users who already hold local MISP accounts must be matched, migrated or retired, and duplicate identities must be avoided. | Export and count local accounts before scoping. Decide early which accounts stay local (for example, break-glass administrators) and which move to SSO. |
| Environments (test, production, air-gapped) | Each environment needs its own provider configuration, test identities and change record. Air-gapped instances may need a different approach to reach the IdP. | Build and test in a non-production instance first, then promote the same documented configuration. Confirm with your network team how an air-gapped instance would reach the provider, if at all. |
| Access review evidence | Assessors and internal reviewers expect a record of who holds which role, when it was granted and who approved it, which adds work if none exists. | Agree the report format before build. Ask the IdP team for a periodic export of group membership and keep the role mapping under version control. |
| Mapping ownership | Without a named owner, mapping changes are made ad hoc, and the reasons for them are lost during upgrades or staff changes. | Name one person accountable for the mapping document and its change log. Record each mapping rule with its purpose and approver. |
| Claim and account linking rules | Linking accounts by an email claim can merge or hijack identities, which requires extra design and testing. | Link on a stable subject identifier from the provider, not on email. Confirm the exact claim settings against the OidcAuth plugin documentation for your version. |
| What a fixed-scope quote should itemize | Without itemized scope, the number of providers, roles, accounts and environments stays unclear, and changes become disputes. | Ask the quote to list: providers and environments in scope, the role and organization mapping, account migration rules, test cases, handover documents and the access review evidence format. Exclusions should be written out. |
How SSO changes on single node, load balanced and air-gapped deployments
On a single MISP server, the SSO configuration is the most direct. There is one public hostname, one web server, and one place where the session and TLS certificate live. Most of the work is confirming that the identity provider and MISP agree on the exact URLs, and that the certificate presented to users is trusted by the browsers and the identity provider.
Points to verify:
- The configured MISP base URL matches the public hostname users type into the browser, including scheme and any non-default port.
- The redirect URI registered with the identity provider matches the callback path that the OidcAuth plugin uses, character for character.
- The TLS certificate chain is complete, including intermediates, so the identity provider can call back over HTTPS without warnings.
- Role claims arrive in the token as expected, and at least one test account maps to the intended MISP role.
- Local fallback administrator access is documented and tested before SSO is enforced.
Confirm with the vendor or in your environment: the exact callback path and claim names for your OidcAuth plugin version in the plugin README for your release, and how your identity provider handles token lifetimes and sign-out.
A single node is the simplest place to get the redirect and certificate right, so verify those first before adding any other complexity.
When several MISP web nodes sit behind a load balancer, the identity flow passes through more components, and small inconsistencies appear as intermittent login failures. Every node must present the same public base URL, produce the same redirect URI, and accept the same session state. Otherwise a login started on one node can return to another node that does not recognize it.
Points to verify:
- Every node uses the same public base URL and the load balancer forwards the original host and scheme headers that MISP relies on.
- The redirect URI is identical on all nodes and registered once with the identity provider, not per node.
- Session handling is consistent: either sticky sessions are configured at the load balancer, or the session store is shared so any node can complete the callback.
- Clock skew across nodes is within what the identity provider tolerates for token validation.
- Logout and session expiry behave the same on each node, so a user cannot remain signed in on one node after signing out on another.
Confirm with the vendor or in your environment: whether your MISP release and OidcAuth plugin version support your chosen session store, and the load balancer's sticky session behavior with the identity provider redirect.
Test a complete login, role change and logout while requests are routed to different nodes, because single-node tests will not reveal these failures.
On an air-gapped or restricted network, MISP and the identity provider often cannot reach public internet services. The identity provider must be reachable from MISP over an internal path, and the discovery metadata that MISP uses to learn endpoints and signing keys must be fetched from an internal source or pinned in configuration. Any step that assumes public access, such as fetching metadata from a public URL or downloading key sets at runtime, needs an internal alternative.
Points to verify:
- MISP can resolve and reach the identity provider's token, authorization and key endpoints over the internal network, including DNS and firewall rules.
- Metadata and signing keys are either served from an internal location or pinned in the plugin configuration, with a documented process for rotating them.
- The internal certificate authority chain is trusted by the MISP server and any proxy involved in the flow.
- Browsers of users on the restricted network can reach both the MISP hostname and the identity provider login page.
- Key rotation and metadata refresh have an owner and a tested procedure that does not require internet access.
Confirm with the vendor or in your environment: whether your OidcAuth plugin version can load metadata from a local file or internal URL, and how your identity provider publishes key rotations to closed networks.
Because public fallbacks are unavailable, validate every dependency in the restricted network before cutover, and document how an expired key or certificate will be detected and fixed.
Securing the client secret, redirect URI and fallback login
The OIDC client secret, the redirect URI and the fallback login decide how well the MISP single sign-on setup resists misuse, so review them before the integration goes live. The client secret lets MISP prove its identity to the identity provider during the token exchange. If it sits in a plain configuration file readable by anyone with server access, anyone who gets that access can impersonate the application. Where your environment allows, keep the secret in a managed secret store or an environment variable injected at runtime, restrict read access to the account that runs the web server, and plan a rotation procedure that you have rehearsed. Confirm with your identity provider how secrets are generated, how long they last and how a rotation is applied without breaking active sessions. The connection between MISP and the provider must use TLS, and MISP must validate the provider's certificate chain. Disabling certificate checks to get a test working is a common shortcut that often survives into production. Check that the discovery document and token, authorization and JWKS endpoints all resolve over HTTPS with a certificate your MISP host trusts, including any internal certificate authority. Also confirm the exact issuer string the plugin expects, because a mismatch between the configured issuer and the one in the token is a frequent cause of failed logins that teams work around by loosening validation. Redirect URIs should be registered exactly as MISP will call them, including scheme, host, port and path. Wildcard or broad redirect patterns let an attacker who controls a related path receive authorization codes. Register only the callback URL of each MISP instance you operate, and separate production, staging and test instances with distinct client registrations. Limit who can edit the OidcAuth plugin settings, since changing the redirect target, the role mapping or the trusted issuer is effectively changing who can become an administrator. Treat plugin configuration as a controlled change, recorded and reviewed like any other access rule. Every SSO deployment needs a break-glass administrator account that works without the identity provider. Create it before enabling SSO, store its credentials under dual control, and test the login path on a schedule. Its existence should be documented as an exception to the normal login policy, and its use should generate an alert. Keep it separate from named administrator accounts so it is not used for routine work. Finally, separate MISP API keys from interactive SSO sessions. API keys are a separate authentication path with their own lifecycle, scope and exposure, and they are not governed by the OIDC login flow. Automation such as feed ingestion or PyMISP scripts should use keys owned by a service identity rather than a person's login, so that offboarding a user does not break integrations. Review how keys are issued, stored, rotated and revoked as a distinct item in the security review, and confirm with the MISP documentation for your version how key expiry and per-user key limits are handled.
What to monitor, review and document after SSO goes live
Once OidcAuth is live, the work shifts from building the integration to keeping it correct. The five items below cover the recurring checks that keep sign-in, role assignment and account lifecycle aligned with the identity provider. Most depend on each other: a mapping change, a patch or a departure can each change who holds access to shared threat intelligence.
Monitor login and role-change events
Review MISP's authentication and audit logs for successful and failed SSO logins, and for every role change applied to a user. Failed logins can point to a misconfigured redirect, an expired client secret or a user outside the expected IdP groups, while unexpected role changes can show a mapping rule matching more broadly than intended. Decide in advance who receives these events, how often someone reviews them and which patterns should trigger investigation. Confirm with your own logging pipeline whether MISP events reach your SIEM and how long they are retained.
Review group-to-role mappings
OidcAuth assigns the first matching MISP role by priority, so the order and content of each IdP group rule decide who holds administrative or publishing rights. Review the mapping table on a fixed schedule, and again after any change to IdP group names, nesting or ownership, because a renamed group can stop matching or match a different role. For each rule, confirm the target role, the organization that users land in and whether the rule still reflects a current job function. Record the reviewer and the date so the review itself is evidence you can show an assessor.
Reconcile accounts when people leave
Removing someone from the IdP may not by itself disable the matching MISP account. Confirm how your configuration handles deprovisioning before go-live, and test it with a dummy account. Run a recurring comparison between active IdP accounts and MISP users, and treat any MISP account with no matching identity as a finding. Pay particular attention to API keys, which can outlive an interactive session, and to accounts linked by email address in earlier configurations. Document who approves account removal and how quickly it must happen.
Re-test after each 2.5 patch
MISP 2.5 receives frequent releases. MISP 2.5.47, released on 17 September 2026, introduced a new database migration system with PostgreSQL support, and MISP 2.5.50 followed on 9 October 2026. Each core update and each OidcAuth or other plugin update can change login handling, session behavior or role logic, so treat every release as a change to the SSO flow. Keep a short regression script covering a successful login, a denied login, each mapped role and a logout, and run it on a non-production instance before the production upgrade. Note any plugin version the upgrade depends on.
Document architecture and break-glass
Keep a current record of the architecture: the IdP tenant, the client registration, redirect URIs, the OidcAuth configuration, the mapping table with a named owner for each rule, and where the MISP instance and database run. Document the break-glass procedure separately, covering which local administrator accounts exist, how their credentials are stored and who can access them, the conditions for using them and the steps to disable them afterwards. Test the break-glass path before you need it, and review both documents after every mapping or infrastructure change. An auditor or incident responder should be able to follow them without the original project team.
Questions teams ask before connecting MISP to SSO
How much does it cost to connect MISP to SSO?
The cost depends on how much identity work sits behind the connection, not on MISP itself, which is free and AGPL licensed. The main drivers are:
- The number of identity providers and whether each one needs its own mapping
- The size of the role model and how many MISP organizations and roles map to IdP groups
- How many existing local accounts must be migrated, reconciled or retired
- The depth of testing across login, role assignment, logout and account lifecycle
A fixed-scope quote from DeployOpen should list each of these as a line item, with the deliverables and acceptance tests named. Ask for the one-time build work separately from any recurring support, and ask what changes if a second identity provider is added later. No public price list exists, so the written scope is the basis for the number.
How long does MISP SSO integration usually take?
The duration is driven by the same factors as cost, and the largest variable is usually how quickly the identity provider team can make group and claim changes and test them. The work generally runs in phases: agreeing the group model, configuring the OpenID Connect client, building the role mapping, testing with real test users, and then cutting over. Delays tend to come from waiting on IdP administrators, from unclear ownership of group membership, or from discovering that existing accounts do not match the intended organizations. Ask any partner to show the phases and the client dependencies in the written plan, and to state which phases depend on your test window.
What does the team need to provide for MISP SSO?
The integration needs four things from your side before work starts:
- Identity provider admin access to create the OpenID Connect client and inspect or add the claims and groups MISP will read
- A group model that says which IdP groups correspond to which MISP roles and organizations
- A named owner who can approve role decisions and answer questions about access
- A test window where test users can sign in, be checked against the expected role, and be removed or changed without disrupting analysts
Without a clear group model, the mapping work expands quickly. Without a named owner, approvals stall. Confirm these with your identity and MISP teams before asking for a quote.
Can our internal team connect MISP to SSO without a partner?
Yes, if the team has two skill sets and the time to use them. The first is identity administration: configuring an OpenID Connect client, reading tokens and claims, and managing groups in your provider. The second is MISP administration: the OidcAuth plugin settings, roles, organizations and the way MISP assigns the first matching role by priority. Most teams underestimate the testing. Plan time to verify each role, confirm that account linking does not merge accounts by email address alone, and check how deprovisioning behaves. If either skill set is thin, a partner is usually more useful for the mapping and testing than for the configuration itself.
What does a partner add to a MISP SSO project?
A partner adds structure around the decisions that are easy to get wrong. In practice that means scoping the providers, roles and accounts in writing, delivering a tested role mapping that is checked against named test users, and producing evidence for access reviews, such as the mapping documentation, the test results and the configuration baseline. It also means a second pair of eyes on account linking, where an unsafe rule can let one person take over another account. Ask the partner to show which artifacts they hand over and who in your organization owns them after the engagement ends.
Does DeployOpen issue compliance certifications for MISP SSO?
No. DeployOpen does not issue audit reports, attestations or certifications. It can prepare the access controls, configuration baselines and evidence that your organization may need for an assessment, such as documented role mappings and test results. Independent auditors and certification bodies assess those controls and decide whether they meet the relevant requirements. Before the engagement, ask which controls the evidence is intended to support, and confirm with your auditor what format they expect.
Which MISP version should we use before connecting SSO?
Use MISP 2.5, which the project recommends for new deployments. MISP 2.4 is end of life and receives security fixes only, and the project advises against installing new 2.4 instances. If you run 2.4 today, plan the upgrade before or alongside the SSO work, because the plugin configuration and testing should happen on the version you will keep. Check the current release notes in the MISP GitHub releases page before you fix the target version in the scope.
How DeployOpen works on this
DeployOpen plans, implements, documents and supports self-hosted open-source platforms inside the client's own infrastructure, and MISP SSO work follows the same arc. The engagement starts with a written scope that names the identity provider, the OidcAuth configuration, the role and organization mapping and the test accounts involved.
How we scope
- Confirm the OpenID Connect identity provider, its client registration settings and which MISP version runs in your environment.
- Agree the IdP role-to-MISP role map and the organization assignment rules, including the priority order the OidcAuth plugin applies.
- Record how user accounts are matched to the IdP subject, and confirm that linking by email claim is excluded from the written scope.
How we build
- Configure the OidcAuth plugin against a test IdP tenant, then validate login, logout and session handling before any production change.
- Build the role mapping in staged test groups, including users who hold several IdP roles, and check which MISP role each one receives.
- Test denial paths, such as users with no mapped role or an unexpected organization claim, and record the results for review.
How we hand over
- Deliver the configuration, mapping tables and test evidence as documentation your administrators can read and maintain.
- Walk your identity and MISP administrators through the mapping, the change process for new roles and the procedure for disabling a leaver.
- Provide a runbook for rotating the OIDC client secret and for restoring the previous configuration if a login change fails.
How we support
- Ongoing support and upgrades are available as a retainer, which can cover re-testing SSO after MISP and plugin updates.
- Review IdP group changes and role mapping drift on a schedule agreed in the retainer, so access stays aligned with policy.
- Confirm with your own environment and the MISP project which plugin and MISP versions your support scope covers before go-live.
