7.1 What the combination actually is
Viewed from an enterprise architecture seat, this lab is not seven unrelated products. It is a complete identity control plane assembled from best-of-breed parts, with each concern handled by a component that does only that job:
| Capability | Component here | What the enterprise gets |
|---|---|---|
| System of record | HR feed | one authoritative source; every downstream account is a consequence of it |
| Governance & lifecycle | midPoint | joiner/mover/leaver, approvals, SoD, reviews, reconciliation |
| Identity store | OpenLDAP | a single directory every application can consume |
| Authentication | Keycloak | SSO, MFA, federation, one place to cut access |
| Authorization | Open Policy Agent | policy as code, versioned and testable like any other artefact |
| Privileged access | Teleport / Guacamole | no standing credentials; recorded, replayable sessions |
| Detection | Wazuh | identity events become alerts a SOC can act on |
The architectural value is in the seams, not the boxes. One authoritative source, one writer to the directory, one place users authenticate, one place policy is decided. That discipline — not the choice of vendor — is what makes an IAM programme defensible at audit.
7.2 What competes with what
A common mistake in vendor conversations is comparing whole stacks. The honest comparison is layer by layer — and the open-source components are not equally strong across the board:
| Layer | This stack | Typical commercial equivalents | How the gap looks |
|---|---|---|---|
| Directory | OpenLDAP | Active Directory, Entra ID | Comparable as a store; AD wins on Windows-estate integration |
| Governance (IGA) | midPoint | SailPoint, Saviynt, One Identity, Omada | The real gap — see §7.5 |
| Access management | Keycloak | Okta, Entra ID, Ping | Genuinely competitive on protocol support; behind on out-of-box integrations and adaptive risk |
| Authorization | Open Policy Agent | PlainID, Axiomatics, in-app logic | Ahead of most — externalised policy-as-code is a modern pattern many suites lack |
| Privileged access | Teleport, Guacamole | CyberArk, BeyondTrust, Delinea | Strong for infrastructure access; behind on vaulting breadth and legacy/Windows PAM |
| Detection | Wazuh | Splunk, Sentinel, QRadar | Capable; behind on scale, content packs and analytics depth |
Read that table honestly and a pattern appears: the open-source stack is strongest at authentication and authorization, solid at directory and detection, and weakest, relative to the market leaders, at governance — which is unfortunately the layer enterprises buy first.
7.3 The case for self-hosting
Self-hosting is a deliberate choice with real benefits — and they are strategic, not technical.
Data sovereignty and residency
Identity data is among the most sensitive an organisation holds: the full workforce, their roles, their entitlements, and by implication the shape of the business. Self-hosting means it never leaves infrastructure you control. For organisations bound by data-residency rules, sector regulation, or public contracts that forbid offshore processing, this is frequently the deciding factor — not cost.
It works disconnected
SaaS identity governance requires connectivity to the vendor. Defence, critical national infrastructure, manufacturing OT networks and classified environments often cannot have that. A self-hosted stack runs in an air-gapped network; most SaaS suites simply cannot be deployed there.
No lock-in on the crown jewels
Your directory, your role model and your entitlement history stay in systems you can read directly — standard LDAP, standard SQL. Migration away is a project; it is not a negotiation. That materially changes your position at renewal.
Transparency you can audit
The source is readable. For supply-chain assurance — an increasing procurement requirement — being able to inspect, build and pin what you run is a genuine advantage over an opaque binary or a multi-tenant service.
Cost that scales differently
Commercial IGA is typically priced per identity. Self-hosted cost is driven by infrastructure and engineering effort, which does not rise linearly with headcount. For large workforces, or ones that swing seasonally, the difference compounds. But see §7.6 before treating this as free.
7.4 The security posture you inherit
Self-hosting moves the security burden onto you. That is neither good nor bad in itself — it is a transfer of responsibility that has to be resourced.
| You now own | What that means in practice |
|---|---|
| Patching | Six products, six CVE streams, six upgrade cadences. Someone must watch them. |
| Availability | The IdP becomes a single point of failure for every application. HA, backup and tested restore are mandatory, not optional. |
| Secrets | Service credentials, bind accounts and client secrets need a real secret manager and a rotation process. |
| Hardening | Network segmentation, TLS everywhere internally, least-privilege service accounts, no default credentials. |
| The identity system's own access | Who administers midPoint and Keycloak? Those accounts are the highest-value target in the estate and belong behind PAM and MFA. |
| Evidence | Audit logs must be retained, tamper-evident and searchable for as long as the regulator requires. |
7.5 Compared with SailPoint and similar suites
Taking the governance layer specifically, since that is where the comparison really bites.
Where the open-source stack wins
| Advantage | Why it matters |
|---|---|
| No per-identity licensing | Cost is decoupled from headcount. At tens of thousands of identities the difference is transformative — and predictable. |
| Deployment freedom | On-premises, private cloud, sovereign cloud or air-gapped. No architecture is off the table. |
| Deep customisation | midPoint's expression and mapping model is genuinely powerful, and you are not waiting on a vendor roadmap or a professional-services engagement to change behaviour. |
| Policy as code | OPA policies live in Git, get code review, run in CI. Most suites still configure authorization through a GUI, which is far harder to test and diff. |
| Composable | Replace one layer without replacing the programme. Suite migrations are all-or-nothing. |
| No commercial pressure on scope | Connect a system because it needs governing, not because a connector licence is already paid for. |
Where the commercial suites win — honestly
| Advantage | Why it matters |
|---|---|
| Connector breadth | The single biggest gap. Established suites ship large libraries of vendor-tested connectors for major SaaS and ERP platforms, and maintain them as those APIs change. With open source you build and, more importantly, keep maintaining the long tail yourself. |
| Identity analytics | Role mining, peer-group analysis, outlier detection and access recommendations are mature commercial capabilities. The open-source stack has little equivalent; you would build it or go without. |
| Certification at scale | midPoint can run certification campaigns. Asking 500 managers to review thousands of entitlements — with reminders, escalation, delegation and a reviewer experience they will not revolt against — is where commercial tooling is clearly ahead. |
| One accountable vendor | When provisioning fails during month-end close, a support contract with an SLA has real value. Best-of-breed means integration failures land between suppliers, and you own the seam. |
| Compliance content | Pre-built SOX, GDPR and sector reporting, plus audit artefacts auditors already recognise. |
| Auditor and market familiarity | Big-four auditors know the major suites. A bespoke stack is defensible, but you will spend more time explaining it — and hiring an experienced engineer for it is harder. |
| Time to first value | A suite with working connectors can govern a major application in weeks. An open-source build reaches the same point more slowly. |
7.6 Total cost of ownership — the honest version
The licence saving is real. It is also the easiest number to over-claim.
| Cost | Commercial suite | This stack, self-hosted |
|---|---|---|
| Licensing | Per identity, annual, rises with headcount | None, or optional support subscriptions |
| Infrastructure | Often included (SaaS) | Yours — compute, storage, HA, DR, backup |
| Implementation | High, usually a partner-led programme | High, and it lands on your own team |
| Connectors | Bought and vendor-maintained | Built and maintained by you, indefinitely |
| Run cost | Vendor patches and operates | Your engineers patch, upgrade and monitor six products |
| Upgrades | Vendor-managed, sometimes forced | Your schedule — and your regression testing |
7.7 Choosing, honestly
| Choose this open-source stack when… | Choose a commercial suite when… |
|---|---|
| Data must stay in your jurisdiction or on your infrastructure | Your application estate is large and heterogeneous, and connectors decide the timeline |
| The environment is air-gapped or intermittently connected | Internal engineering capacity is limited or already committed |
| You have — and will keep — a capable platform team | You need a vendor contractually accountable for outcomes |
| Identity counts are high enough that licensing dominates | You need identity analytics and role mining from day one |
| Your culture is GitOps: everything versioned, reviewed, tested | Audit scrutiny is heavy and familiar artefacts reduce friction |
| You need behaviour a vendor will not build for you | Time to value matters more than unit cost |
The hybrid most enterprises actually land on
The choice is rarely binary, and the pragmatic answers are worth knowing:
- Split by audience. A commercial suite for workforce governance, Keycloak for customer-facing identity — where per-identity licensing on millions of consumers would be prohibitive.
- Split by layer. Keep the incumbent directory and IdP; add OPA for application authorization, which most suites do not cover well anyway.
- Split by environment. Open source in development, test and sovereign regions; commercial in the primary production estate.
- Start open, buy later. Build the role model, the SoD matrix and the data quality on an open stack. Those artefacts are the expensive part and they are portable — if you later buy a suite, you arrive with your homework done and a far shorter implementation.
7.8 What this lab would need to become production
An honest closing note: the lab is a teaching configuration, not a reference architecture. It runs on one host, with one instance of everything and no redundancy. Before it governed anything real:
| Area | What production demands |
|---|---|
| Availability | Clustered IdP and IGA, replicated directory, HA databases, tested restore — the IdP is now critical infrastructure |
| Authoritative source | A real HR system over an API, not a CSV |
| Secrets | A managed secret store with rotation, not an .env file |
| Admin access | Platform administrators behind MFA and PAM, with their own break-glass procedure |
| Segregation | Separate development, test and production instances with a promotion path for configuration |
| Configuration management | Every object in Git, deployed by pipeline — never edited by hand in production |
| Monitoring | Availability and performance monitoring, not just security alerting |
| Data retention | Defined retention for audit records and session recordings, matched to the regulator |