midPoint SSO and identity integration guide

How midPoint SSO differs from the login server you already run

midPoint is an identity management system, so it does not act as an SSO or OAuth2, OpenID Connect or SAML server. Its own user interface can sign users in against an external SSO service, which is the part this topic covers. If your organization already runs an identity provider or access management tool, midPoint sits beside it: the login server authenticates people, and midPoint decides which accounts, groups and roles those people should hold in the systems that depend on them. Evolveum describes midPoint's scope in its FAQ as identity management rather than access management or SSO, and the integration work starts from that division of responsibilities.

This topic covers two separate jobs. The first is UI authentication, where administrators and self-service users sign in to midPoint through an external SAML or OIDC provider instead of a local midPoint password. The second is provisioning, where midPoint creates, updates and removes users and groups in access management tools and other target systems so that those tools can make their own login decisions. Teams usually need the first when they want one sign-in policy for all staff, including the people who administer identity, and the second when a downstream tool must hold accounts that match HR-driven lifecycle events. Some organizations need both, and others need only one. Confirm which applies before scoping the work.

The integration is harder than it looks because it creates two trust relationships that must be designed and operated separately. One is between midPoint and the external SSO provider, covering client registration, certificate or secret handling, redirect URIs and claim mapping for administrator roles. The other is between midPoint and each target system, covering the connector account, its permissions and how credentials are protected. A mistake in either relationship can lock out administrators or leave an orphaned account active, and the two failures look different in logs.

The second difficulty is identity consistency. The login server may identify a person by one attribute, while midPoint correlates accounts by HR identifiers, employee numbers or directory attributes, and the access tool may key accounts on a third value. Decide the authoritative identifier before configuring anything, and check that the same person resolves to one midPoint focus and one account per target. Ownership is also split. The SSO team usually owns the provider and its policies, the identity team owns midPoint configuration and connectors, and the application owners own the access tools. Write down who approves a change to each side, because most post-go-live incidents occur at those boundaries.

Which midPoint components touch login and provisioning

Logging in to midPoint and provisioning accounts into other systems involve different parts of the stack. Four components carry most of the integration work: the midPoint web UI, the object model, ConnId connectors, and the external identity provider and access management tool. Knowing what each one owns tells the team where to configure, test and troubleshoot.

midPoint web UI authentication

The midPoint web UI is the administrative interface staff use to manage users, roles and approvals. In an SSO integration, its authentication configuration decides how administrators sign in, whether through an external SAML or OIDC provider or through local accounts. Teams should confirm which login paths exist, which fallback local administrator account is kept for recovery, and how that account is protected.

midPoint object model

midPoint stores users, roles, organizations and groups as its own objects, and every provisioning decision starts from them. Assignments of roles to users drive which accounts exist in target systems. Teams should map which identity attributes come from the HR source, which are derived inside midPoint, and which group objects must exist before a downstream tool can consume them.

ConnId connectors to targets

ConnId connectors are the components that create, update and disable accounts and group memberships in target systems. For SSO and identity integration, the connector to the access management tool is the path that makes a midPoint group visible to that tool's authorization decisions. Teams should confirm which connector supports the target, which account and group attributes it writes, and who holds the credentials it uses.

External identity provider and access tool

The identity provider authenticates users, and the access management tool decides what they can reach. Evolveum states that midPoint is not an access management or SSO server, so these systems remain the authority for sign-in and for runtime access. Teams should confirm which system issues tokens or assertions, which system reads the groups midPoint provisions, and which system is the source of truth for each attribute.

Ownership of login and provisioning

Login and provisioning share identity data but have separate owners and failure modes. A broken web UI sign-in blocks administrators, while a failed connector run leaves target accounts out of step with midPoint. Teams should write down who owns each component, what alerts they receive, and how a failure in one path is detected without relying on the other.

Choosing the protocol, provider and provisioning target

This table compares the four decisions that shape a midPoint SSO and identity integration: how administrators sign in to the midPoint user interface, which identity provider they use, how groups reach access management tools, and which system holds authority. Read each option against the protocols and connectors your team confirms in its midPoint version's documentation, since support differs by release. The main takeaway is that every option adds recurring work, such as certificate or secret rotation, connector upgrades and reconciliation, so choose the option your team can run.

Decision and option	When it fits	Operational cost to plan for
UI login: SAML 2.0	Your corporate identity provider already issues SAML assertions to other applications and your team manages SAML metadata.	Signing certificate renewal, metadata updates when endpoints or certificates change, and attribute mapping for roles.
UI login: OpenID Connect	Your identity provider offers OIDC clients and your team prefers registering clients with redirect URIs and secrets.	Client secret rotation on a schedule, redirect URI changes per environment, and claim checks after provider changes.
Identity provider: existing corporate directory	Administrators already sign in there, so joiner, mover and leaver controls apply to them automatically.	Dependence on the corporate team's change windows, a shared outage path, and access rules that need review for midPoint administrators.
Identity provider: dedicated for administrators	Privileged midPoint administrators need a separate MFA policy, a smaller trust boundary or an identity provider outside the corporate directory.	A second identity service to run, separate certificate or secret rotation, and an administrator account lifecycle to maintain.
Group provisioning: supported ConnId connector	A connector for your access management tool is listed as supported in your midPoint version's documentation.	Connector version ownership tied to midPoint upgrades, testing before each upgrade, and vendor-specific configuration to maintain.
Group provisioning: SCIM2	The target exposes a SCIM endpoint and the SCIM2 connector is confirmed for your midPoint version.	Endpoint and token rotation, schema mapping for group membership, and reconciliation after failed pushes.
Group provisioning: CSV, scripted SQL or scripts	The target has no supported connector or API, or a file-based route is acceptable for a limited period.	Scripts and file handoffs to maintain, scheduled runs to monitor, and manual reconciliation when files or scripts drift.
Source of truth: midPoint authoritative	midPoint owns identity and access decisions, with HR and other sources feeding it and target systems receiving its changes.	Ongoing reconciliation to detect out-of-band changes in target systems and an operations team that treats midPoint as the record.
Source of truth: mirror from another system	Another system must remain authoritative for groups, so midPoint copies its state for governance and reporting.	Sync jobs in both directions to design, conflict rules to define, and drift checks between the two systems.

Building midPoint SSO in the right order

This sequence connects midPoint's user interface to an external identity provider while keeping midPoint in its role as an identity governance system. Each step closes with a check, so administrators can sign in, map to one identity and provision test groups before any production user depends on the integration. The output is a tested, documented trust path that the operations team can run and maintain.

Confirm the midPoint version and Java runtime
The identity team selects the midPoint release line first, because it sets the Java runtime and the support window. Evolveum's system requirements recommend Java 21 for midPoint 4.10 and older, with Java 17 supported, and Java 25 for 4.11 and later, with Java 21 supported. The 4.8 Curie release is long-term support until 17 October 2028, while 4.9 support ends 18 October 2026. Confirm the chosen version, its Java build and the PostgreSQL server it will use. Done when midPoint starts on that runtime in a lab host and the running version appears in the administration console.
Register midPoint with the identity provider
The identity provider administrator creates a relying party or client entry for midPoint using the protocol agreed for the project, SAML or OpenID Connect. Set the redirect or assertion consumer address to the lab hostname, and confirm which metadata or client secret format the provider expects. Create two or three test users, with one holding a group that matches an intended administrator role. Done when a test user reaches the provider sign-in page and the provider issues a token or assertion for midPoint.
Enable external authentication for the console
In a non-production environment, configure midPoint's user interface authentication against the provider using the settings for the chosen protocol. Keep a local administrator account available for recovery, and confirm the exact configuration keys in the documentation for the release in use. Test sign-in with a standard test user and with a user who should be refused. Test sign-out and confirm that the session ends in midPoint and at the provider as the design requires. Done when login and logout behave as documented in every test case.
Map the external identity to one midPoint user
Decide which stable attribute from the provider identifies a person, such as a subject identifier or employee number, and map it to a midPoint user attribute. Configure correlation so that each incoming login matches exactly one midPoint user object, without creating duplicates. Test with an existing user, a new user and a person who has two accounts at the provider. Done when each test login updates one object and the roles expected for that person appear on that object.
Restrict administrative access before go-live
Before any production login is enabled, define which groups or roles from the provider grant access to midPoint administration. Map each one to a midPoint role whose authorizations are limited to what that role needs, and remove broad default access from test accounts. Test by signing in as each test persona and attempting actions outside its role, such as changing a system configuration or viewing another user's sensitive data. Done when every blocked action fails, every permitted action succeeds, and the results are recorded.
Test group creation and removal in the target
Define the access management tool as a provisioning target using a ConnId connector. Check the connector's status in Evolveum's integration catalog before selecting it, because supported, community and experimental connectors carry different levels of assurance. Use a small pilot set of test users and one test group. Verify that midPoint creates the group, adds and removes members, and deletes the group when its assignment is removed. Done when each action appears in the target tool and in the midPoint audit trail.
Document trust settings and assign owners
Record the trust configuration in a runbook: the provider metadata source, where the client identifier and keys are stored, certificate expiry dates, redirect addresses, the mapped attribute and each administrative authorization group. Name a technical owner for midPoint, a business owner for the provider relationship and a contact for certificate renewal. Include the test cases from each earlier step as the regression set for future changes. Done when the owners have signed off the runbook and someone other than its author has walked through a login using it.

Provisioning users and groups into access management tools

In a midPoint SSO and identity integration, midPoint acts as the identity source. It holds the authoritative record of users and their group assignments, and it pushes accounts and group memberships into downstream access management tools. This is different from the login path. midPoint does not decide who can sign in to the tool. It decides which accounts exist there and which groups those accounts belong to, and the access tool then enforces those decisions. Evolveum describes midPoint as an identity management system, not an access management or SSO server, so the team should plan the provisioning side as its own workstream alongside authentication.

The first design decision is which object is the source of truth for group membership. Options include midPoint roles and assignments, group objects that already exist in the target tool, or a directory that feeds both. If the target tool currently lets administrators add people to groups by hand, midPoint will overwrite or conflict with those changes once it is enforcing memberships. Write down, for each group, whether midPoint is authoritative, whether it is read-only in the target, and who may change it. Agree this with the application owners before any connector is configured, because a mismatch here is the most common cause of access drift after go-live.

Existing accounts need correlation before enforcement starts. When midPoint first connects to the access tool, it must match each account already there to a midPoint user, typically on a stable attribute such as an employee identifier or a directory identifier, rather than on display name or email, which change. Unmatched accounts should be listed and reviewed, not deleted or created automatically. Decide in advance what happens to accounts with no midPoint owner and to midPoint users who should have an account but do not. Running correlation in report-only mode first lets the team see the match rate and the exceptions before any change is written to the tool.

How the SSO and provisioning setup changes by deployment model

On a single Linux virtual machine, midPoint runs as one instance with one externally reachable address. The SSO configuration therefore needs one redirect URI that matches the hostname, scheme and port that users enter in the browser. Login state is held by that one node, so no request needs to be routed back to a particular instance. Provisioning tasks also run on this node, and the scheduling behavior is the default for the installed instance.

Points to set up:

Register one redirect URI for the node's external hostname and HTTPS port, and copy it exactly into the identity provider client.
Confirm the callback path that your midPoint version expects in the authentication module configuration.
Place the identity provider's signing certificate where the midPoint service account can read it, and record its renewal date.
Schedule reconciliation tasks outside the hours when administrators run manual imports, since all tasks compete for the same node.
Plan the connection to the separate PostgreSQL server, because a single node still depends on that database for every login and task.

Check the redirect URI string, including scheme and port, against the identity provider's error output after a deliberately failed login.

What drives identity integration effort

This table lists the factors that change how much work an midPoint SSO and identity integration takes, with a way to reduce each one. Read each row as a question to answer before a quote is written, since the count and complexity of the items in each row decide the scope. The main takeaway is that standardizing early on protocols, environments and attribute definitions usually matters more than the number of applications alone.

Effort driver	Why it changes effort	How to keep it down
Identity providers and applications needing login	Each application that relies on the midPoint user interface or a separate sign-on needs its own client registration, redirect settings and testing of the login flow.	Standardize on one protocol, such as SAML or OpenID Connect, and reuse a single identity provider application per environment where the design allows.
Target access tools and connector support	Each target tool needs a connector. Documented ConnId connectors differ in maturity, and a community or experimental connector can add custom development and testing.	Confirm connector status for each target in the Evolveum connector catalog, then pilot one target tool first before adding the rest.
Count and quality of identity attributes to map	Every attribute mapped from the source to midPoint and on to each target adds mapping rules, validation and reconciliation checks. Inconsistent source data adds cleanup work.	Agree an attribute dictionary early with HR, directory and application owners, with names, formats, owners and authoritative sources written down.
Number of environments and consistency	Development, test and production each need matching configuration, connector settings and identity provider registrations. Drift between them slows testing and upgrades.	Keep configuration in version control, promote changes through the same path each time, and document environment-specific values such as URLs and certificates.
Custom attribute and claim mapping	Identity provider claims and target-specific attribute formats often differ from midPoint's defaults, so each custom claim or transformation needs design, review and test cases.	Limit claims to what each application needs, reuse existing mapping patterns, and record the expected value for each claim in the design.
Group modeling	Group membership reaches target tools through roles and assignments. Nested or application-specific groups require decisions on ownership, naming and synchronization direction.	Define a small set of group and role naming rules before build, and decide which system is authoritative for each group type.
Compliance evidence requirements	Auditors may expect records of who approved access, when accounts changed and how sign-on was configured. Each evidence item needs to be produced, retained and shown during the assessment.	Ask the assessor early which evidence they need, then include log retention, audit trail settings and sample reports in the scope from the start. DeployOpen prepares evidence; auditors and certification bodies assess it.
Quote contents	A fixed-scope quote should list the number of identity providers, applications, target tools with connector status, attributes, environments, claims, group types and evidence items.	Ask the provider to name each count in the written scope and to state which items are excluded, so the estimate can be compared with your own team's plan.

Securing the SSO trust and provisioning credentials

Once midPoint delegates sign-in to an external SAML or OIDC provider and pushes accounts into target systems, the weakest points are the administrator roles that can change login settings and the secrets that bind midPoint to each partner. The controls below cover those points for this integration. Repository and audit configuration are covered in the separate security hardening topic.

Limit administrator roles and login changes

Changing the authentication configuration in midPoint can redirect or weaken how every administrator signs in, so it should not sit with the same people who run day-to-day provisioning. Define a narrow administrator role for changes to the SSO connection and assign it to a small named group. Confirm in a test environment which midPoint authorizations allow editing the authentication settings, and check that no broad administrator role grants them by accident.

Protect the provider trust material

The client secret for an OIDC provider, or the signing and encryption keys used with a SAML provider, let midPoint prove its identity to the partner and validate assertions from it. Store these outside configuration files that engineers copy around, restrict who can read them, and record a rotation procedure before go-live. Ask your identity provider team which certificate or secret lifetimes apply and when they expire.

Use TLS on callbacks and connector traffic

The login callback between the browser, midPoint and the identity provider carries tokens or assertions, and connector sessions carry account data and credentials to target systems. Require HTTPS for the midPoint endpoint that receives the callback, and verify the certificate chain that connectors trust for LDAP, directory and SCIM endpoints. Check each connector's TLS settings individually, because some connectors offer plain or optional encryption.

Keep connector accounts to least privilege

Each connector authenticates to a target system with a service account, and a broad account turns a midPoint compromise into a compromise of that system. Create one account per target with only the rights needed for the attributes and objects midPoint manages, such as creating users and managing one group container. Confirm the exact permissions with the target system owner before testing, and review them again after each connector upgrade.

Confirm audit records show login changes

An administrator who changes the SSO connection or a connector setting should leave a record that names the person, the time and the object changed. Test this by making a harmless change in a non-production environment, then reading the audit output that your security team will use. If the record does not show who changed the login configuration, fix the logging before go-live rather than relying on the identity provider's logs alone.

How to verify SSO login and provisioning fail safely

Verification for this integration has one goal: show that a correct login succeeds, a denied or revoked user is blocked, and a failed identity provider leaves administrators a way in. Plan these tests before configuration is signed off, and run them in a non-production midPoint instance connected to a test identity provider tenant. Build a test user for each group that maps to a midPoint role, plus one user with no group membership and one user whose access has been removed. For each case, record the expected result before running it, so the outcome is judged against a written standard rather than what the system happened to do.

Start with login. For each test group, confirm that the user reaches the midPoint interface through the external SAML or OIDC provider, lands with the expected authorizations, and cannot reach administrative functions outside those authorizations. Then test denial: a user outside every permitted group should be refused at the provider or at midPoint, and the refusal should appear in the audit trail. Check logout from both sides, confirming that ending the midPoint session does not silently leave the provider session active, and that an expired session forces a fresh authentication. Confirm the exact session lifetimes with your identity team, since they are set in the provider and the midPoint configuration and must agree.

Next, test failure. Stop or block access to the identity provider from the midPoint network segment and attempt a login. The expected outcome is a clear refusal, not a partial session. Administrators must still have a documented break-glass path that does not depend on the failed provider, such as a local account held in a sealed credential store and used only under a change record. Test that path during the same exercise, confirm it is logged, and confirm it is disabled again afterwards. Do not accept an untested break-glass account as a control.

Provisioning tests show whether identity changes reach the access management tools. Create a new user in the authoritative source, confirm the account and group membership appear in the target system, then remove the user's assignment and confirm the target access is withdrawn. Run a reconciliation task afterwards and confirm it reports no drift between midPoint and the target systems. Keep the outputs of each run.

Record evidence for each test: the test case ID, the date, the tester, the expected and actual results, the relevant audit or log extract, and a reference to the configuration version tested. Keep the handover package complete: a configuration export, a register of trust metadata owners who can approve certificate or metadata changes, the versions of the midPoint release and each ConnId connector in use, the signed test results, and a runbook for certificate rotation with a rollback step. Confirm the supported release line and connector status with Evolveum and your own environment before handover, because support dates and connector maturity change over time.

Questions buyers ask before bringing in a partner

Can midPoint act as the SSO server for our applications?

No. midPoint is an identity management system, and Evolveum states that it does not implement the server side of OAuth2, OpenID Connect or SAML. midPoint creates and maintains accounts, groups and roles in the target systems that need them. Applications that need single sign-on still require an access management or SSO server. midPoint feeds that server the identity data it needs. midPoint's own web interface can authenticate against an external SSO service, which is the pattern this page describes. Before you design the connection, confirm with your access management vendor which protocols, claims and attribute formats it expects.

How much does a midPoint SSO and provisioning project cost?

The cost depends on the scope, and it has four main parts: discovery and design, connector and mapping build, testing against each target, and rollout with handover. DeployOpen is paid for the scoped work. Your organization pays for its own staff time, test environments and any Evolveum subscriptions, which are optional and sold separately. Build and cutover are one-time costs. Support, upgrades and the identity team that runs midPoint recur. Costs rise with the number of target tools, the state of your identity provider configuration and attribute data, the number of environments, and approval flows. DeployOpen does not publish a price list. A quote follows from the written scope, so ask for each target, environment and deliverable to be listed separately, with testing and handover included.

How long does a midPoint identity integration project take?

There is no fixed duration. The main driver is the number of target systems and environments. Each target needs its own attribute mapping, testing and owner sign-off, and each environment repeats that work before production. Other factors include how ready your identity provider configuration is, how clean the HR or directory source is, and how many changes your change board must approve. Ask for a phased plan in the written scope that lists each target and environment with its own milestone. That shows where the time goes and which inputs your team must have ready at each step.

What must our team provide before an identity integration starts?

Plan to supply six things. First, administrative access to the identity provider, so the SSO configuration can be built and tested. Second, an attribute dictionary that defines each attribute, its authoritative source and its format. Third, a named owner for each target tool who can approve mappings and accept test results. Fourth, test accounts in every target and every non-production environment. Fifth, access to the directory or HR source that feeds identities into midPoint. Sixth, change windows agreed with operations. Missing any of these items typically moves dates, so confirm each one with its owner before the written scope is signed.

Can our own identity team build midPoint SSO and provisioning without a partner?

Yes, if your team already has identity and access management skills and a non-production test environment that matches production closely enough to test connectors, mappings and SSO login. Your engineers need to understand the midPoint object model, connector configuration and how your identity provider issues assertions or tokens. Without a test environment, changes reach real users directly, which is the main risk. A partner adds the most value when skills are thin, deadlines are fixed, or you want an independent review of the design. Decide before the project starts which parts your team builds and which parts you buy.

What do Evolveum support subscriptions for midPoint cover?

Evolveum offers two kinds of subscription. Product Support subscriptions cover resolution of product bugs, with either an 8x5 next-business-day SLA or a 24x7 SLA. Platform Subscriptions add feature development and influence over the roadmap. The support subscriptions page lists no prices, so request current terms from Evolveum directly. Neither subscription replaces implementation work in your environment. Neither covers your mappings, custom configuration or operational runbooks. Evolveum funds midPoint development through these subscriptions, training and professional services. DeployOpen retainers can sit alongside an Evolveum subscription, with each party responsible for the work it actually delivers.

Which target systems can midPoint provision accounts and groups into?

midPoint provisions through the ConnId connector framework. Documented connectors include LDAP, Active Directory, CSV, DatabaseTable, ScriptedSQL, Microsoft Entra ID through the Graph API, SCIM2 and SCIMv1. Evolveum also publishes an integration catalog of further connectors, with statuses ranging from supported to community and experimental. Check the status of the connector for each target before you scope the work, because a community or experimental connector carries different support expectations than a supported one. Access management tools that accept SCIM are a common route, but confirm the exact SCIM version and the resource types the tool accepts.

How DeployOpen works on this

DeployOpen scopes midPoint SSO as an integration project. midPoint is an identity governance platform that does not act as an SSO server, so sign-in to its user interface is wired to your existing SAML or OIDC provider. We plan, implement, integrate, document and support that work inside your own infrastructure, including provisioning of users and groups into access management tools. Engagements are fixed-scope, and ongoing support is available as a retainer.

How we scope

Written scope lists which identity sources, target tools and login flows are in and out
We record the SSO protocol, identity provider and attribute mapping before any build starts
Scope names which access management tools receive users and groups from midPoint

How we build

Configure midPoint's user interface to authenticate against the agreed external SAML or OIDC provider
Map identity attributes and groups from midPoint into target tools through ConnId-based connectors
Test sign-in, logout, failure paths and provisioning results in a staging environment first

How we hand over

Documentation covers the SSO configuration, connector settings, mappings and the rollback steps
Runbooks describe certificate renewal, client secret rotation and provider changes for your operators
Knowledge transfer walks your identity team through configuration, testing and troubleshooting

How we support

Ongoing support can run as a retainer covering upgrades, fixes and changes to login flows
Confirm with Evolveum which subscription covers product bugs, and what a support SLA includes
Before each midPoint upgrade, we retest SSO and provisioning flows against the new release

midPoint SSO and identity integration