Open source identity governance and administration

Open source identity governance and administration: when self-hosted IGA fits

Access in most organizations grows unevenly. Joiners get accounts in the HR system, directories and business applications at different speeds, movers keep access from their previous roles, and leavers are often caught late. Access reviews then depend on spreadsheets and manual exports that are out of date by the time they are signed off. The main open source option for identity governance and administration (IGA) is midPoint, an identity management and governance platform licensed under the European Union Public License 1.2 or later. Whether self-hosting it fits depends on three things: the quality of your HR source data, the number of target systems you need to connect, and whether your team can operate the platform after go-live.

Regulated organizations are the most common candidates. The HIPAA Security Rule at 45 CFR 164.312 requires covered entities and business associates to implement access control with unique user identification and audit controls over systems that hold ePHI, and the FTC Safeguards Rule at 16 CFR 314.4 requires covered financial institutions to monitor the activity of authorized users. Neither rule prescribes a tool, but both expect you to show who has access, why, and that someone reviewed it. Self-hosting usually fits when you have a clear joiner, mover and leaver source in an authoritative HR system, a manageable set of target applications that can be connected through connectors or APIs, and identity engineers who can own the mappings, roles and policies. Confirm each of these before you commit, because they are the inputs that drive the scope of any quote.

Self-hosting is a weaker fit when HR data is inconsistent, when most applications are SaaS products with no provisioning interface, or when no internal team can maintain the deployment and its connectors. In those cases, a commercial IGA service, or an open source platform run with an implementation partner under a retainer, may be the better route. Before you decide, ask your HR, directory and application owners to list the systems that must be governed, which of them support automated provisioning, and who will approve access requests. Those answers tell you more about the fit than any feature comparison, and they give a partner the information needed to write a fixed-scope proposal.

Requirements to agree before choosing a platform

Six decisions shape the midPoint design, the connector work and the effort before any platform is installed. Settle them in writing with HR, application owners, risk and audit, because each one changes which integrations you need and how much of the rollout is configuration versus custom development.

Authoritative HR source and joiner events

Identify the system of record for employees, contractors and their lifecycle dates, such as the HR platform or a contractor management system. Confirm which events it can emit (hire, transfer, leave of absence, termination), whether they arrive as a feed, an API call or a file drop, and how often. Joiner timing and identifiers such as employee number determine whether midPoint reads from HR directly or through an intermediate directory.

Target systems and connector options

List every application that should receive accounts, with its owner, protocol and whether it offers an API, SCIM support or only a database or directory interface. Each system without a supported connector becomes custom integration work with its own testing and maintenance. Ask which systems hold privileged or regulated data, since those usually need stricter reconciliation and review.

Role model and ownership

Decide who defines business roles, who approves changes to them, and whether roles are built from job profile, department or entitlement bundles. An unowned role catalog tends to grow into duplicate roles that are hard to certify. Agree on a naming standard, a review cadence for each role, and the rule for retiring roles that no longer match a job.

Certification scope and reviewer model

Define which accounts, roles and entitlements are certified, how often, and who reviews each one. Managers are a common default, but application owners or data owners may be needed for shared or privileged access. Confirm how reviewers will decide when they lack context, and whether revocations must flow back to the target system automatically or through a ticket.

Approval workflows and segregation of duties

Map who may request access, who approves it at each risk level and what happens when an approver is absent. Include conflict rules that stop one person from holding incompatible entitlements, such as payment entry and payment approval. Each rule needs a named owner, because midPoint can enforce policy only once the business has defined it precisely.

Audit retention and evidence needs

Set how long provisioning history, approval records, certification decisions and reconciliation results are kept, and where they are stored. Map the retention to the regulations you answer to, including the audit controls in 45 CFR 164.312 if electronic health information is in scope. Confirm with legal and internal audit before the platform is sized, because log volume and storage follow directly from this choice.

Which open source IGA option fits which situation

This table compares midPoint, a full identity governance suite, with Keycloak, authentik and ZITADEL, which handle sign-in and provisioning but not certification campaigns. Read each row against your own requirements for access reviews, licensing and operating effort, then confirm connector coverage for your specific target systems before you choose.

Capability or factor	midPoint (IGA suite)	Keycloak, authentik or ZITADEL (access platforms)
Primary purpose	Identity governance and administration: joiner, mover and leaver provisioning, access requests, certifications and role management	Authentication and single sign-on, with SCIM or connector-based provisioning into applications
Access certification campaigns	Yes	No
Role management and access requests	Built-in governance workflows for roles and requests, to be confirmed against your design	Limited to application and group assignment; confirm whether your workflows need more
License	European Union Public License 1.2 or later	Keycloak: Apache-2.0. ZITADEL: AGPL-3.0. authentik: MIT, except the authentik/enterprise directory under a separate enterprise license
Current release and support	Latest release 4.10.5; 4.8 Curie long-term support until October 17, 2028	Confirm the supported release line and upgrade cadence with the project or your partner
Target system connectors	Confirm connector coverage for each target, including custom or legacy systems	Confirm SCIM or protocol support for each application; directory federation covers some sources
Operating effort	Higher: data model, mappings, workflows and connector maintenance usually need specialist skills	Lower for sign-in; provisioning rules still need design and ongoing testing
Best fit	Regulated organizations that must evidence who has access and why, and review it on a schedule	Organizations that need SSO and MFA first, with provisioning limited to a few well-known applications

Reference architecture components and how they connect

A midPoint deployment is a set of connected parts: an authoritative HR source, the midPoint core and its repository, connectors to target systems, and the workflow, certification and audit functions that sit on top. The cards below describe each part, the link between it and its neighbors, and the checks to make before build starts.

midPoint core and repository

The midPoint core holds the identity model, reconciles projected accounts against each target, and stores users, roles, assignments and task state in its repository. Plan for one authoritative instance per governed population, sized for the number of identities and the number of target accounts, not for the number of applications alone. Confirm with the vendor and your own environment which release line and database engine your team will support, and who applies patches. The Curie 4.8 long-term support line is one option to check against your upgrade cadence.

HR source connector

The HR system of record drives joiner, mover and leaver events, so it is the most important input in the design. Map the employee identifier, employment status, manager, department and job code, and agree which system wins when two sources disagree. Decide whether midPoint pulls from HR on a schedule or receives events, and how contractors and non-HR identities enter. Ask your HR team for a data dictionary and for the rules that govern rehires and retroactive changes, because these cause most reconciliation exceptions.

Directory and application connectors

Connectors read and write accounts in Active Directory, LDAP, cloud directories and business applications. Each connector needs a service identity with the narrowest rights that still allow create, update, disable and delete. Test each connector in a non-production target before go-live, and confirm which operations it supports for your specific application version. Applications without an API usually need a manual fulfillment task, which should be tracked as an exception with an owner and a deadline.

Connector credentials and secrets

Connector service accounts and API tokens are privileged credentials, so they must not sit in configuration files or in plain text in the repository. Store them in a dedicated secrets platform, grant midPoint access by identity and policy, and rotate them on a schedule your operations team can keep. The choice of secrets product is covered in the self-hosted secrets management topic. Here, confirm that rotation does not break running reconciliation jobs and that secret access is itself logged.

Role and policy model

Roles bundle entitlements, and policies decide who may receive them and under what conditions. A workable model separates business roles (for job functions), application roles (for target permissions) and governance rules (for segregation of duties and approval thresholds). Keep the role count small enough to certify. Before build, write down which conflicting access pairs must be blocked and who approves exceptions, since these rules become the evidence your reviewers and auditors will test.

Request, approval and certification flows

Access requests and approvals run through midPoint workflows, and certification campaigns re-validate existing access on a schedule or after a trigger. Both depend on accurate manager relationships and on owners assigned to every role and resource. Decide how approvals reach reviewers, how delegation works during leave, and what happens when a reviewer does not respond. Each decision should record the reviewer, the time and the outcome so that the campaign results can be reproduced later.

Audit log store

The audit log records provisioning changes, approvals, certification decisions and administrative actions. Send it to a store that your security team can search and that is retained for the period your regulators and internal policies require. Confirm the retention rules with your compliance lead rather than relying on defaults. Protect the store from edits by administrators of midPoint itself, because an access review is only as credible as the record of what changed and who approved it.

Build in-house, partner or buy SaaS for identity governance

Building on an open-source IGA platform such as midPoint keeps the identity data, the connector code and the operating runbooks inside your organization. The license is the EUPL 1.2 or later, so there is no per-identity license fee to the vendor, but the internal team carries the full cost of design, build, testing and upgrades. Expect the largest share of the effort to sit in HR source mapping, target system connectors and the approval logic that auditors will read.

Data and connectors: Your team owns every mapping, connector and policy. You can change them without a vendor queue, but you also own every defect.
Skills needed: Identity architects who understand provisioning models, Java or XML configuration skills for midPoint, directory and database administration, and staff who can read application APIs.
Connector maintenance: After go-live, your team patches connectors when target applications change their APIs or schemas. Plan a named owner for each connector.
Cost structure: Most spend is one-time build labor and testing. Recurring cost is staff time for upgrades, monitoring and access review support.
Upgrade discipline: Track the midPoint release cycle and the 4.8 Curie long-term support date of October 17, 2028, and decide which line you will run.

Before choosing this model, confirm that you can staff at least two people who can operate the platform without leaving the team during the first year.

Build, partner or SaaS: control, effort and cost structure

This table compares building midPoint internally, engaging an implementation partner to run a self-hosted midPoint, and buying a hosted IGA service across data residency, connector ownership, upgrades, certification evidence and cost. Read each row as a question to put to every option, then use the cost rows to shape the written scope you request for a quote.

Dimension	Build in-house	Partner-delivered self-hosted	Hosted IGA SaaS
Data residency	Identity data stays in your own accounts or data centers	Identity data stays in your environment; the partner works inside it	Identity and HR attribute data sit with the vendor; confirm regions and sub-processors
Connector ownership	Your team writes and maintains connectors to HR and target systems	Connectors are scoped and delivered in writing; confirm who owns the code after handover	Vendor-provided connectors; confirm coverage for your target systems and who builds custom ones
Upgrade responsibility	Your team plans and tests midPoint upgrades, including the 4.8 long-term support line	Upgrades can be a retainer item; confirm test scope and rollback steps	Vendor applies upgrades on its schedule; confirm change notice and your testing window
Certification evidence ownership	You produce access review records and retain them	You own the evidence store; the partner prepares configuration and review exports	Evidence may sit in the vendor platform; confirm export formats and retention before signing
Recurring cost	Staff time for engineering, operations and upgrades	Support or retainer fees plus your hosting and licensing costs	Subscription, often per identity or per connector; confirm the pricing unit and growth terms
One-time cost	Design, connector build, testing and training	Fixed-scope discovery, design, integration and cutover	Onboarding, connector setup and data migration; confirm whether these are separate fees
Main cost drivers	Number of target systems, HR data quality and team skills	Scope of connectors, number of phases and support hours	Identity count, modules enabled and custom integrations
What to request in a quote	Staff plan, tooling list and training plan	Written scope, deliverables, acceptance criteria and retainer terms	Subscription terms, exit and data return conditions, and onboarding statement of work

How a phased midPoint rollout runs

The sequence moves identity governance from a role model and a trusted HR source to automated joiner, mover and leaver processes, then to access requests, certifications and a handover the internal team can run. Each phase closes with a written output so scope and progress stay visible to the sponsor and the auditors.

Define scope, sources and the role model
The implementation partner and your identity, HR and application owners inventory the target systems, the authoritative HR source, and the existing groups, roles and entitlements. The team drafts a role model that maps job functions to access bundles and records which applications are in the first wave. The step closes when the sponsor signs off the role catalog, the source list and the wave one application list, all written into the agreed scope.
Connect the HR source and run a joiner pilot
Engineers connect midPoint to the HR system of record and to a small directory or target group, mapping employee attributes such as identifier, department, manager and employment status. A limited set of new hires is provisioned end to end, and the team checks that accounts, group memberships and the notification to the manager match the role model. The step closes when the pilot population is reconciled against HR records with no unexplained differences.
Automate movers and leavers
The team adds rules for job changes so that old access is removed and new access is granted according to the role model, and for terminations so that accounts are disabled and entitlements withdrawn on the effective date. Test cases include rehires, leave of absence and contractors if they are in scope. The step closes when the test log shows every mover and leaver case produces the expected change in each connected system, and exceptions route to a named owner.
Enable access requests and approvals
Self-service requests for roles and resources go through approval workflows that name the approver for each type of access and record the justification. Segregation rules and approval timeouts are configured with the risk owners. The step closes when a sample of requests shows the full chain: request, approver decision, provisioning result and audit record, and the escalation path has been tested.
Run the first certification campaign
Reviewers, typically line managers and application owners, attest to the access in scope for the campaign, and the team confirms that revocations flow back to the target systems. Results are exported with reviewer identity, decision, timestamp and remediation status. The step closes when the campaign is complete, revocations are verified in the target systems, and the evidence pack is accepted by the control owner. Ask the partner which control objectives this evidence is intended to support and confirm them with your auditor.
Hand over runbooks and operating ownership
The partner delivers runbooks for connector maintenance, reconciliation, role changes, certification scheduling, patching and upgrades, backup and restore, and incident response. Your team runs a supervised cycle with the partner observing, then takes over day-to-day operations. The step closes when your operators have completed the agreed run cycle, the open issues list is assigned, and any ongoing support or upgrade retainer is documented separately in the written scope.

Systems IGA must connect to and what each integration involves

An identity governance deployment is only as accurate as the systems it reads from and writes to. Each connection carries its own data model, credentials, failure modes and test plan, so scope them one by one before any role design begins. The cards below cover the authoritative source, directories, SaaS targets, ticketing and sign-in platforms.

HR system as authoritative source

The HR system defines who is a joiner, mover or leaver, so every downstream account depends on its accuracy. Confirm which fields are authoritative (employee ID, legal name, department, manager, employment status, effective dates) and who owns them. The connector typically reads changes through an export, API or database view, and you need to agree how future-dated hires and retroactive terminations are handled. Test with a sample of real-world edge cases such as rehires, contractors converted to employees and leave of absence.

Active Directory or LDAP directories

Directories usually hold the accounts, group memberships and credentials that applications still depend on, so IGA changes here have immediate effect. Confirm the write path (LDAP over TLS, a service account with scoped rights, or a provisioning gateway), which organizational units IGA may modify, and how disabled accounts and group nesting are handled. Test account creation, attribute updates, group changes and disablement against a non-production forest before any production run, and confirm rollback steps for a bad mapping.

Cloud directories and identity providers

Cloud directories and federated identity providers often become the primary home for workforce accounts, with group sync from on-premises sources. Confirm which API permissions the connector needs, how license assignment is driven by roles, and whether the directory is the source of truth or a downstream target. Test throttling behavior on bulk changes, sync latency between directories, and how conflicts are resolved when an account exists in both places.

SaaS applications and their entitlements

Each SaaS application has its own role model, admin APIs and sometimes no API at all, which makes entitlement mapping the hardest part of the project. Inventory the applications by access type (SCIM, vendor API, CSV import or manual task), and record which roles map to business roles. Where no connector exists, plan a manual fulfillment task with evidence capture. Test each entitlement path end to end, including removal, since revocation failures are the most common audit finding.

Ticketing for manual provisioning tasks

Some targets will always need a person to act, so the IGA platform must open tickets with enough context for fulfillment and close the loop automatically. Confirm the ticketing system's API, the fields needed for a complete request, and the approval and completion states that IGA must track. Define service levels for manual tasks and escalation when they stall. Test ticket creation, update callbacks, reassignment and the case where a fulfiller closes a ticket without completing the change.

SSO platforms where access is enforced

Provisioning only matters if sign-in enforces it, so the SSO platform, such as Keycloak, is where a removed entitlement must take effect. Confirm how group or role claims reach applications, whether IGA updates the identity store that SSO reads from, and how quickly existing sessions end after a revocation. Keycloak supports LDAP and Active Directory user federation, which is one common path to connect the directory to sign-in. Test that a revoked user cannot obtain a new token and that application roles in claims match the certified state.

What do buyers ask about IGA cost, effort and time?

How much effort does a midPoint implementation take?

Effort depends mostly on the number of authoritative sources, the number of target systems that need provisioning, and how well roles and entitlements are defined before build starts. No effort figure for midPoint is supplied here, so ask any partner to size the work from a written scope that lists each HR source, each target application, the approval paths and the review scope. Ask for the effort broken into discovery, role design, connector build, testing, cutover and hypercare, and for the assumptions behind each line.

What parts of an IGA project carry the most cost?

The largest cost components are usually connector work for applications without standard connectors, role and entitlement design that business owners must agree on, and testing of joiner, mover and leaver scenarios against real HR data. Software licensing for midPoint is not a line item because the platform is licensed under EUPL 1.2 or later, so the recurring costs sit in infrastructure, support and maintenance. Ask a quote to separate one-time build work from recurring operations, and to state who is paid for each part: the client's staff, the platform vendor, or an implementation partner.

Can our internal team run a midPoint implementation alone?

A capable internal team can run an IGA project alone if it has engineers who know identity protocols, directory services, and the target applications, plus an owner who can make decisions about roles and approvals. Most teams find the gaps in connector development, reconciliation logic and test automation, and in the time required to keep the project moving while daily operations continue. Decide early which parts you will build, which you will buy as a fixed-scope engagement, and which you will hand to a retainer after go-live. DeployOpen plans, implements, integrates and documents self-hosted platforms in the client's own environment, under written scope.

What does the HR team and application owners need to provide?

The HR team must confirm the authoritative source of employee records, the fields that define job, department, manager and employment status, and the events that trigger joiners, movers and leavers. Application owners must name the accounts that exist in their systems, the entitlements they carry, and who approves access. Without these inputs, role models stall and reconciliation produces many exceptions. Ask any partner to list these inputs in the statement of work with named owners and dates, and to state what happens when a dependency is late.

How long does a phased IGA rollout take?

No duration is supplied for this topic, so the timeline should come only from the written scope. A phased rollout usually starts with one authoritative source and a small set of target systems, then adds applications, access requests, certifications and role-based provisioning in later phases. Ask for a timeline per phase with exit criteria, such as reconciled identities, tested leaver removals and a completed first access review. Treat any date offered before the scope is agreed as an assumption to test, not a commitment.

What recurring work follows go-live?

After go-live, recurring work includes running certification campaigns, reviewing orphaned and excessive accounts, updating roles when job structures change, maintaining connectors when target applications upgrade, and keeping midPoint itself current. Platform upgrades and security patches also recur. Ask the partner whether these tasks sit in the client's team, in a retainer, or both, and what response times and upgrade support the retainer includes. Costs for these tasks recur every year, so compare them with the one-time build cost in any quote.

How are access reviews evidenced from IGA records?

An IGA platform records who holds which access, who approved it, when it was granted or removed, and the outcome of each certification decision. These records support the access control and audit control requirements in the HIPAA Security Rule at 45 CFR 164.312, which covers unique user identification and activity examination, and the FTC Safeguards Rule at 16 CFR 314.4, which covers monitoring authorized user activity. Confirm with your auditor which evidence they accept, such as campaign exports, reviewer attestations and reconciliation reports. DeployOpen prepares systems and evidence for assessments, but independent auditors issue any audit report or certification.

Questions to ask an implementation partner before signing

Start with the platform version. Ask the partner which midPoint release they propose and why, and what their policy is for moving between releases. The current release is 4.10.5, while the 4.8 Curie long-term support release is supported until October 17, 2028. Ask whether the design targets an LTS line or the latest release, who applies patches to custom code and connectors on each upgrade, and how long a typical upgrade test cycle runs in your environment. Confirm the answers in writing, because they set your upgrade effort for the life of the deployment.

Next, test connector coverage against your actual target list. Ask for each named system (directory, HR-linked applications, ERP, cloud tenants and any mainframe or legacy systems) whether the partner will use an existing connector, adapt one, or build one, and what each option means for scope. Ask how they will verify that a connector handles account creation, attribute updates, disablement and entitlement reads for your version of each target. Also ask how the HR source will feed midPoint: whether through a direct database or API read, a file feed, or an intermediate directory, and who owns the mapping of HR job codes to roles. Request the written role model workshop plan, including who from your business and HR must attend and what sign-off the partner expects before build starts.

Finally, settle the operating model before you sign. Ask how certification campaign results will be exported, in what format, with which fields (reviewer, decision, timestamp, justification and the access state at review time), and whether the export is produced by the platform or by custom reporting that the partner must maintain. Ask for the handover package, including runbooks for joiner, mover and leaver failures, connector restarts and campaign administration, and who keeps them current. Most importantly, ask who maintains connectors after go-live, under what support terms, and at what cost. Ask for a written scope, deliverables, acceptance criteria and a quote before any work begins, and check that each item from this list appears in that document.

Open source identity governance and administration