Entra ID Governance vs midPoint: A Practical Comparison

by with No Comment CompliancemidPoint Tips

Microsoft Entra ID Governance is the default identity governance option for organizations deep in the Microsoft ecosystem. It is cloud-native, tightly integrated with M365 and Azure, and available as an add-on to the Entra ID licenses most enterprises already hold. For pure Microsoft environments, it works.

The question is what happens when your environment is not purely Microsoft.

Most enterprises are not. They run SAP alongside Azure. Oracle databases alongside SharePoint. Custom HR systems alongside Workday. On-premises Active Directory alongside Entra ID. Legacy LDAP directories that predate their cloud migration. And increasingly, Keycloak for application-level authentication and federation that sits outside Microsoft’s reach.

That is where Entra ID Governance’s scope ends and the governance gap begins. This article compares Microsoft Entra ID Governance with Evolveum midPoint – not to declare a winner, but to help you understand which platform governs what, where the gaps are, and how they work together in the hybrid reality most enterprises actually operate in.

DORA Compliance: How midPoint Meets Identity Governance Requirements

by with No Comment Compliance

The Digital Operational Resilience Act (DORA) has been fully enforceable since January 2025. In 2026, European supervisors moved from readiness checks to active enforcement. If your financial institution still treats identity governance as an IT project rather than a regulatory obligation, the gap between your policies and your evidence is where the examiner will start.

DORA applies to more than 22,000 financial entities across the EU – banks, insurers, investment firms, payment providers, crypto-asset service providers, and their critical ICT third-party providers. Its identity and access requirements are not vague best practices. They are specific, article-level legal obligations with penalties reaching 2% of global annual turnover and up to EUR 1 million in personal fines for senior management.

Here is what DORA actually requires for identity governance, where most organizations are falling short, and how midPoint addresses each requirement.

Non-Human Identity Governance in midPoint: Closing the 109-to-1 Gap

by with No Comment CompliancemidPoint Tips

Service accounts, API keys, RPA bots, and AI agents now outnumber human users in the average enterprise by 109 to 1. Most IGA programs barely see them. Here is what that gap looks like, why it matters for your 2026 security posture, and how midPoint treats non-human identities (NHIs) as first-class identities you can actually govern.

The numbers most IGA programs would rather not look at

Palo Alto Networks publishes the 2026 Identity Security Landscape Report, which puts the average ratio of machine identities to human identities at 109 to 1. Rubrik Zero Labs measures the ratio at 45 to 1 in traditional enterprises, rising to 82 to 1 in their most recent Identity Crisis study. Some hyper-automated, cloud-native organizations report ratios closer to 500 to 1.

In absolute terms, the average enterprise now manages over 250,000 non-human identities across its cloud and on-premise estate. That includes:

  • Service accounts on Active Directory, Linux, databases, and middleware
  • API keys, OAuth tokens, and personal access tokens
  • Workload identities (containers, serverless functions, virtual machines)
  • CI/CD pipeline credentials
  • RPA bots
  • Machine-to-machine (M2M) certificates
  • AI agents and copilots, the fastest-growing category, projected to grow 85% over the next 12 months

The governance posture, when measured, is uncomfortable:

  • 97% of NHIs carry privileges beyond what their function requires
  • 71% have not been rotated within the recommended timeframe
  • 68% of identity-related security incidents now involve a machine identity
  • Only 15% of organizations report high confidence in their ability to prevent NHI-based attacks

This is the gap, and it is not a future problem.

What recent breaches tell us

The 2024 and 2025 breach record reads like an NHI governance manual written backwards.

  • BeyondTrust (December 2024). A compromised API key was paired with a command-injection bug to gain unauthenticated remote code execution on customer instances of its Remote Support SaaS.
  • Snowflake customers (May 2024). Stolen credentials for non-MFA-protected service accounts gave attackers data from Ticketmaster, Santander, and dozens more.
  • Dropbox Sign (May 2024). A compromised backend service account opened the customer database, exposing emails, API keys, and OAuth tokens.
  • Schneider Electric (November 2024). Exposed Jira credentials let attackers exfiltrate 40 GB of internal project data.
  • AWS “Codefinger” campaign (January 2025). Ransomware operators used compromised AWS keys plus customer-provided-key encryption to lock S3 buckets.
  • DeepSeek (January 2025). Over one million log lines and sensitive secret keys exposed via an unsecured database.

The pattern is consistent. The attacker rarely needed a zero-day. They needed a credential that nobody owned, nobody reviewed, and nobody had rotated. NHIs.

Why traditional IGA misses non-human identities

Most IGA programs were built around employees: hire date, manager, department, role, leaver event. The data model and the workflows assume a human owner and a human lifecycle. That assumption breaks for NHIs in four ways:

1. No HR feed. A service account does not appear in Workday. There is no source of truth and no “joiner” event.

2. No clear owner. A bot created three years ago by a contractor who has since left has no human attached to it. Ownership rots.

3. No leaver. When the application that created the account is decommissioned, the NHI is rarely cleaned up. Orphan accounts accumulate.

4. No certification. Even where access reviews exist, certifiers either skip service accounts (“don’t touch, it’ll break production”) or rubber-stamp them.

The result is a population larger than your workforce, growing faster than your workforce, with weaker governance than your workforce. Gartner’s 2026 IAM track captured the same observation. Many organizations are still in a basic discovery phase for NHIs, inventorying what exists, assigning ownership, and understanding exposure before any meaningful policy work can begin.

How midPoint governs non-human identities

midPoint was designed around a generic identity object model rather than a fixed “user” type. That distinction matters more for NHIs than for any other category. In midPoint, a service account, an RPA bot, and an AI agent are governed using the same primitives as a human identity (roles, archetypes, policies, approvals, certifications, audit, outlier detection), but with object types, lifecycle rules, and ownership models tuned to non-human reality.

Here is what that looks like in practice.

First-class object model with archetypes

midPoint’s archetype mechanism lets you define distinct identity types such as service-account, rpa-bot, ci-cd-credential, and ai-agent. Each archetype carries its own:

  • Required attributes (purpose, system, owner, expiry, risk tier)
  • Lifecycle states and transitions
  • Approval policies for creation and privilege change
  • Certification cadence
  • Default role assignments via inducement

This is what makes governance possible. An ai-agent archetype can require an explicit human owner, a 90-day certification cycle, and an attestation that the agent’s tool list has been reviewed, automatically on every change.

Joiner-Mover-Leaver, adapted for machines

midPoint extends its JML processes to NHIs with a critical addition: human-dependency triggers. When the responsible person for a service account leaves the organization, midPoint can:

  • Re-route ownership to the leaver’s manager
  • Suspend the account if no owner is reassigned within an SLA
  • Trigger an immediate access review
  • Decommission the account when the underlying application is retired

This closes the orphan-account loop that most NHI breaches exploit.

Role-based and policy-based access for machines

Service accounts get the same RBAC discipline as users. Roles can be:

  • Birthright for a given archetype. An ai-agent may always get logging and observability access.
  • Conditional on attributes. Only agents deployed in production get database read access.
  • Approval-gated for anything sensitive. Write access to a financial system requires the data owner’s sign-off.

Segregation-of-duties checks apply equally. A bot cannot simultaneously hold “create payment” and “approve payment” entitlements without raising a policy violation.

Certifications that cover the whole identity population

midPoint’s access certification campaigns can target NHIs as their own scope. The certifier sees the account, the owner, the assigned roles, the last-used timestamp (when fed from the target system), and the risk tier. Decisions such as keep, revoke, or reassign owner flow back as automated provisioning actions, not Jira tickets.

This is where the “97% over-privileged” statistic finally gets addressable.

Outlier detection for the population you cannot eyeball

When you are governing 250,000 identities, the human eye cannot find the bad one. midPoint’s outlier detection flags accounts whose role assignments deviate from peers in the same archetype, owner group, or organizational unit. That surfaces the rogue bot which has accumulated production write access nobody approved.

Integration with secrets vaults and PAM

midPoint is the governance layer, not the secret store. The pattern that works in production is:

  • midPoint owns the lifecycle, ownership, role assignments, certifications, and audit.
  • A vault (HashiCorp Vault, CyberArk Conjur, AWS Secrets Manager, Azure Key Vault) owns the credential material, rotation, and short-lived issuance.
  • ConnId connectors wire midPoint to the vault, so that creating a service account in midPoint provisions both the identity record and the vault entry, and decommissioning cleans both sides.

This separation means rotation, ephemerality, and policy enforcement live where they belong, while governance, ownership, and audit live in midPoint.

AI agents as a governed identity class

The fastest-growing NHI category is also the least governed. midPoint’s archetype model makes AI agents tractable:

  • Each agent gets a human owner and a documented purpose
  • The agent’s tool list and target systems are modeled as role assignments
  • Privilege escalation requires the same approval flow as a human role request
  • Periodic certifications attest that the agent still needs every entitlement it holds
  • Decommissioning the agent’s owning application triggers automatic clean-up

Gartner predicts that by 2028, at least 15% of daily workplace decisions will be made by AI agents. Each of those decisions traces back to an NHI with access to data. Governing that population the same way you govern people is not optional. It is the only model that survives audit.

A reference blueprint: NHIs in midPoint

For a typical enterprise starting from a midPoint baseline, the working blueprint is:

1. Discovery and inventory. Use midPoint’s resource shadows to pull every service account from Active Directory, Linux, databases, cloud IAM, and SaaS admin consoles. Tag each with its source system.

2. Archetype design. Define service-account, rpa-bot, ci-cd-credential, workload-identity, and ai-agent. Set required attributes and risk tiers.

3. Ownership assignment. Bulk-assign owners from application catalogues, CMDB, or where nothing exists, to the department head responsible for the target system. Make ownership mandatory.

4. Role modeling. Define birthright roles per archetype. Move ad-hoc entitlements into named roles. Apply SoD policies.

5. Vault integration. Connect the credential store. Wire creation, rotation, and revocation events both ways.

6. Certifications and outlier detection. Schedule NHI-specific campaigns. Turn on outlier detection. Make remediation automated, not a ticket queue.

7. Decommissioning rules. Build the JML triggers for application retirement and owner departure. Rehearse them.

Most organizations can stand up steps 1 to 4 within a single quarter on top of an existing midPoint instance. Vault integration and certifications follow in the next cycle.

Common mistakes to avoid

  • Treating NHIs as a discovery problem only. Inventory without governance is a spreadsheet that rots.
  • Building a separate “NHI platform.” A parallel system means parallel ownership, parallel audit, and parallel cost. midPoint already has the primitives.
  • Excluding service accounts from certification campaigns. This is the single most common audit finding.
  • Letting application teams self-manage their bots’ privileges without policy. That is how the 97-percent-over-privileged number was earned.
  • Treating AI agents as “just an integration” instead of an identity. They are identities. They have entitlements. They need owners.

The bottom line

Non-human identities are not a niche category any more. They are the majority of your identity population, they are the majority of identity-related incidents, and they are growing faster than your headcount ever will. The NHI access management market itself is forecast to grow from USD 9.45 billion in 2024 to USD 18.71 billion in 2030, at an 11.9% CAGR. That is the market following a problem that already exists, not creating one.

The good news is that midPoint does not require a new product, a new vendor, or a new program to govern this population. It requires the same IGA discipline you already apply to your workforce, extended to the identities that now outnumber them by 109 to 1.

Start your NHI governance journey

WeKnowIdentity helps organizations extend midPoint’s governance model to the full non-human identity population. That includes archetypes, lifecycle automation, certifications, vault integration, and AI-agent onboarding. If your midPoint deployment governs your workforce but not your service accounts, bots, and AI agents, that is the gap where your next incident will land.

Book a free NHI governance assessment

Related Resources

Sources

Microsoft Identity Manager (MIM) End of Support: Your Migration Options

by with No Comment

Microsoft Identity Manager (MIM) extended support runs until January 2029. If your organization still relies on MIM for identity provisioning, now is the time to plan your next move.

MIM has served enterprises well for over a decade. But Microsoft has made it clear: MIM’s future is limited. The platform receives only security patches, no new features, and its architecture is fundamentally tied to on-premises Active Directory in an era where hybrid and cloud-first identity is the standard.

What happens after MIM?

Microsoft’s own recommendation is Microsoft Entra ID Governance for cloud-native organizations. But for enterprises with complex on-premises infrastructure, hybrid AD environments, and custom provisioning workflows, Entra ID Governance alone may not cover all use cases.

This is where open-source alternatives like Evolveum midPoint become compelling.

Why midPoint is a strong alternative

  • Full lifecycle management: joiner, mover, leaver automation with HR integration, just like MIM but without the deprecated architecture
  • ConnId connector framework: midPoint connects to the same targets MIM does: Active Directory, LDAP, databases, REST APIs, SOAP services, CSV feeds, and SCIM endpoints
  • No per-user licensing: midPoint is open source. You pay for implementation and support, not per-identity fees that scale with your organization
  • Modern deployment: runs natively on Kubernetes with GitOps-based configuration management, Helm charts, and full CI/CD pipeline support
  • Built-in governance: role-based access control, access certification campaigns, segregation of duties, and audit-ready compliance reporting for GDPR, NIS2, and ISO 27001

Planning the migration

A MIM to midPoint migration typically involves these phases:

1. Assessment: Map your current MIM configuration: management agents, sync rules, provisioning workflows, and custom extensions. Identify which connectors and business logic need to be replicated.

2. Architecture design: Define the midPoint deployment model (Kubernetes, Docker, or bare metal), HR source of truth integration, and connector architecture.

3. Connector development: Build midPoint ConnId connectors for each target system. Many standard connectors (AD, LDAP, database, CSV) are available out of the box.

4. Parallel operation: Run MIM and midPoint side by side during the transition period. Validate identity data consistency across both systems.

5. Cutover: Switch production traffic to midPoint with zero downtime. Decommission MIM.

The cost of waiting

January 2029 sounds far away, but enterprise identity migrations are complex projects. A typical migration takes 6 to 12 months depending on the number of connected systems and custom business logic. Starting in 2026 gives you comfortable runway. Starting in 2028 means rushing, cutting corners, and accepting risk.

Our experience with MIM migrations

At WeKnowIdentity, we have delivered 10+ enterprise midPoint deployments managing up to 1,000,000+ identities. Our founder holds four Evolveum midPoint certifications (Professional, Advanced, Deployment, Group Synchronization) and has hands-on experience with MIM migration projects.

We work across telecom, finance, government, healthcare, education, and technology sectors in Slovakia, Switzerland, Germany, Austria, and Poland.

Ready to plan your migration?

Contact us for a free initial assessment. We will evaluate your current MIM setup, map the migration path, and provide a realistic timeline and roadmap to midPoint.

Related Resources

Related: For a comprehensive side-by-side analysis of open source and commercial IGA platforms, read our full guide: midPoint vs Commercial IGA: Which Approach Fits Your Enterprise?

Why Migrate from SAP IDM to midPoint Before 2027

by with No Comment

SAP Identity Management reaches end of maintenance in December 2027. If your organization relies on SAP IDM, the clock is ticking.

For years, SAP IDM has been a reliable workhorse for enterprise identity governance. But with SAP officially ending maintenance, organizations face a critical decision: migrate to a new platform or risk running unsupported identity infrastructure.

Why midPoint?

Evolveum midPoint is an open-source Identity Governance and Administration (IGA) platform that covers everything SAP IDM does, and more. No per-user licensing fees, no vendor lock-in, and a thriving community backed by professional support from Evolveum.

What makes the migration feasible

  • midPoint’s ConnId connector framework supports the same target systems SAP IDM connects to: Active Directory, LDAP, databases, REST APIs, SOAP services, CSV feeds, and SAP systems themselves
  • Role-based access control, access certification, and segregation of duties are built into midPoint’s core
  • midPoint runs on Kubernetes with GitOps-based configuration management, making it cloud-native from day one
  • The migration can be phased: run both systems in parallel during transition, with zero downtime cutover

The cost of waiting

Every month closer to the 2027 deadline narrows your options. Rushed migrations lead to gaps in compliance, broken provisioning flows, and security exposure. Starting now gives you time to properly map connectors, test role models, and train your team.

Our experience

At WeKnowIdentity, we have delivered 10+ enterprise midPoint deployments managing up to 1,000,000+ identities across telecom, finance, government, and technology sectors in Europe. Our team holds 4 Evolveum midPoint certifications and has hands-on experience with SAP IDM migration specifically.

Ready to plan your migration?

Contact us for a free initial assessment. We will evaluate your current SAP IDM setup and provide a realistic migration roadmap to midPoint.

Related Resources

Related: For a comprehensive side-by-side analysis of open source and commercial IGA platforms, read our full guide: midPoint vs Commercial IGA: Which Approach Fits Your Enterprise?

Open Source IAM vs Commercial Platforms: Why Enterprises Are Choosing midPoint

by with No Comment

The identity and access management market is dominated by commercial vendors like SailPoint, One Identity, Saviynt, and Omada. But a growing number of enterprises are choosing open-source alternatives, with Evolveum midPoint leading the shift. Here is why.

The Cost Problem with Commercial IAM

Commercial IAM platforms typically charge per managed identity. For an organization with 50,000 identities, annual licensing alone can exceed EUR 500,000. Add implementation costs, annual maintenance, and mandatory upgrades, and the 5-year total cost of ownership often reaches seven figures.

This per-user model creates a perverse incentive: the more identities you manage (which is the whole point of IAM), the more you pay. Organizations managing contractors, partners, and machine identities alongside employees see costs escalate rapidly.

The Open Source Alternative

midPoint eliminates per-user licensing entirely. The software is free under the Apache License. You pay for:

  • Implementation: Consulting to deploy, configure, and integrate midPoint
  • Custom development: Connectors and extensions for your specific systems
  • Support subscription: Optional professional support from Evolveum
  • Training: Knowledge transfer to your internal team

After the initial implementation, ongoing costs are limited to support subscriptions and internal staff time. There are no surprise license renewals or per-user fee increases.

Feature Comparison: midPoint vs Commercial Platforms

The perception that open-source IAM means fewer features is outdated. midPoint offers enterprise-grade capabilities:

  • Identity lifecycle management: Full joiner/mover/leaver automation, equivalent to commercial platforms
  • Access certification: Scheduled and event-triggered review campaigns with remediation
  • Role management: RBAC, ABAC, role mining, and automatic role assignment
  • Segregation of duties: Policy-driven conflict detection and prevention
  • Audit and compliance: Comprehensive logging, exportable reports, SIEM integration
  • Connector framework: ConnId supports AD, LDAP, REST, SOAP, SCIM, databases, CSV, and custom targets
  • Self-service portal: Access requests, password reset, profile management
  • Organizational structure modeling: Complex multi-tenant and multi-org hierarchies

What Open Source Gets You That Commercial Does Not

No Vendor Lock-In

You own your identity platform. If you decide to change consulting partners, extend the platform, or fork the code, you can. With commercial platforms, your data and configuration are trapped in a proprietary format.

Full Transparency

midPoint’s source code is on GitHub. You can audit every line of code that processes your identity data. For regulated industries and government agencies, this transparency is not optional.

Community Innovation

Evolveum’s development is driven by real customer needs and community contributions, not shareholder expectations. Features are added because they solve real problems, not because they make good marketing slides.

Deployment Freedom

Run midPoint anywhere: Kubernetes, Docker, bare-metal, any cloud provider, or on-premises. No vendor-mandated infrastructure requirements.

When Commercial Still Makes Sense

To be fair, commercial platforms have advantages in specific scenarios:

  • You need the absolute largest pre-built connector library with zero custom development
  • AI-driven access recommendations are a critical requirement today (not in your roadmap)
  • Your organization requires a fully managed SaaS IGA solution
  • You have no internal IT capacity and need a vendor to manage everything end-to-end

The Trend Is Clear

With SAP IDM reaching end of maintenance in 2027 and Microsoft MIM extended support ending in 2029, thousands of enterprises must choose a new IGA platform. Many are discovering that the open-source path offers better economics, more flexibility, and no lock-in.

midPoint is not a compromise. It is a strategic choice.

Explore midPoint for Your Organization

WeKnowIdentity helps enterprises evaluate, implement, and optimize midPoint. We have completed 10+ enterprise deployments across telecom, government, finance, healthcare, and technology sectors. Contact us for a free assessment of how midPoint fits your environment.

Related Resources

Related: For a comprehensive side-by-side analysis of open source and commercial IGA platforms, read our full guide: midPoint vs Commercial IGA: Which Approach Fits Your Enterprise?

NIS2 Directive: How midPoint Helps You Meet Identity Security Requirements

by with No Comment

The NIS2 Directive (Network and Information Security Directive 2) came into force across the EU in October 2024, significantly expanding cybersecurity obligations for essential and important entities. Identity and access management is a core requirement. Here is how midPoint helps you comply.

What NIS2 Requires for Identity Management

NIS2 Article 21 mandates that organizations implement “policies on access control and asset management” as part of their cybersecurity risk management measures. Specifically, entities must:

  • Implement access control policies based on the principle of least privilege
  • Manage privileged accounts with enhanced security measures
  • Maintain an inventory of critical assets and their access relationships
  • Ensure supply chain security, including third-party access governance
  • Report significant incidents within 24 hours of detection

midPoint Capabilities for NIS2 Compliance

Least Privilege Access Control

midPoint’s role-based (RBAC) and attribute-based (ABAC) access control ensures users receive only the permissions required for their job function. Automated joiner/mover/leaver processes adjust access instantly when roles change, eliminating stale permissions that violate least privilege principles.

Privileged Account Management

midPoint tracks and governs privileged accounts across all connected systems. Policies can enforce:

  • Separate privileged and standard accounts for administrators
  • Time-limited privileged access with automatic expiration
  • Mandatory approval workflows for privileged role assignment
  • Enhanced logging and monitoring of all privileged account activity

Asset and Access Inventory

midPoint maintains a real-time inventory of all identities, their role assignments, and the systems they can access. This inventory is always current because midPoint provisions and de-provisions access automatically. For NIS2 compliance, this means you can produce an accurate access map for any identity at any time.

Supply Chain Access Governance

Third-party vendors, contractors, and partners often need access to your systems. midPoint manages external identities with:

  • Separate lifecycle policies for external users
  • Automatic expiration dates on contractor accounts
  • Periodic access recertification for all external users
  • Immediate de-provisioning when contracts end

Incident Response Support

NIS2 requires rapid incident reporting. midPoint’s audit logs provide the evidence trail needed to:

  • Determine which accounts were compromised
  • Identify what data and systems the compromised accounts could access
  • Trace the timeline of access changes around the incident
  • Support forensic investigation with complete provisioning history

Who Must Comply?

NIS2 applies to a broad range of sectors:

  • Essential entities: Energy, transport, banking, health, water, digital infrastructure, ICT service management, public administration, space
  • Important entities: Postal services, waste management, chemicals, food, manufacturing, digital providers, research

Organizations in these sectors with 50+ employees or EUR 10M+ turnover are generally in scope.

Penalties for Non-Compliance

NIS2 introduces significant penalties: up to EUR 10 million or 2% of global annual turnover for essential entities, and up to EUR 7 million or 1.4% for important entities. Management bodies can be held personally liable.

Start Your NIS2 Compliance Journey

WeKnowIdentity helps organizations implement midPoint’s identity governance capabilities to meet NIS2 requirements. We assess your current access control posture, design compliant policies, and deploy automated governance workflows. Contact us for a NIS2 readiness assessment.

Related Resources

Building Custom midPoint Connectors for REST APIs: A Practical Guide

by with No Comment

Most enterprises have at least one system that does not have a pre-built midPoint connector. REST APIs are the most common integration target for custom connector development. This guide explains how midPoint connectors work and what to consider when building one for a REST API.

Understanding the ConnId Framework

midPoint does not communicate with target systems directly. Instead, it uses the ConnId connector framework (originally developed as part of the Sun Identity Manager project, later adopted by the open-source community). ConnId provides a standardized Java API that all connectors implement.

This means every connector, whether it targets Active Directory, a database, or a REST API, follows the same interface contract: Create, Read, Update, Delete, and Search operations on accounts and groups.

When Do You Need a Custom Connector?

You need a custom connector when:

  • Your target system exposes a REST API but has no pre-built ConnId connector
  • The existing generic REST connector does not support your API’s authentication or pagination model
  • You need complex transformation logic between midPoint schema and the API’s data model
  • Your system uses a proprietary protocol that the generic connectors cannot handle

Common examples: custom HR systems, homegrown CRM platforms, SaaS applications without SCIM support, legacy billing systems with REST facades.

Connector Architecture for REST APIs

A REST API connector typically consists of:

  • Configuration class: Defines connection parameters (base URL, authentication credentials, timeout values)
  • Connection management: Handles HTTP client setup, OAuth token refresh, or API key injection
  • Schema discovery: Maps the API’s data model to ConnId’s account and group object classes
  • CRUD operations: Implements Create (POST), Read (GET), Update (PUT/PATCH), and Delete (DELETE) against the API endpoints
  • Search/filter translation: Converts ConnId filter queries into API query parameters or OData filters
  • Pagination handling: Manages cursor-based, offset-based, or link-based pagination for large result sets

Authentication Patterns

REST APIs use various authentication methods. Your connector must handle:

  • API key: Static key passed as header or query parameter
  • Basic auth: Username/password encoded in the Authorization header
  • OAuth 2.0 client credentials: Token acquisition and automatic refresh before expiry
  • OAuth 2.0 authorization code: For APIs requiring user-delegated access (less common for backend integration)
  • Certificate-based (mTLS): Mutual TLS for high-security environments

Error Handling and Resilience

Production connectors must handle real-world API behavior:

  • Rate limiting: Respect HTTP 429 responses with exponential backoff
  • Transient failures: Retry on 5xx errors and network timeouts
  • Partial failures: Handle batch operations where some items succeed and others fail
  • Schema changes: Gracefully handle unexpected fields or missing required fields
  • Logging: Comprehensive logging at appropriate levels for debugging without exposing sensitive data

Testing Your Connector

Before deploying to production:

  • Unit test each operation against mock API responses
  • Integration test against a sandbox/staging instance of the target system
  • Load test with realistic identity volumes to verify pagination and performance
  • Test error scenarios: API downtime, expired credentials, rate limiting
  • Validate schema mapping with midPoint’s resource definition

Deployment and Maintenance

Once built, the connector JAR is deployed to midPoint’s connector directory. Version the connector alongside your midPoint configuration in Git. Plan for ongoing maintenance:

  • API version upgrades may require connector updates
  • New attributes or operations may need schema extensions
  • Authentication method changes (e.g., API key to OAuth) require connector reconfiguration

Let Us Build It For You

WeKnowIdentity has built custom midPoint connectors for REST APIs, SOAP services, databases, CSV feeds, and proprietary platforms. Every connector is built to ConnId standards, fully tested, and documented. Contact us to discuss your integration requirements.

Related Resources

GDPR Compliance with midPoint: Automated Access Certification and Audit Reporting

by with No Comment

The General Data Protection Regulation (GDPR) requires organizations to demonstrate that personal data access is controlled, justified, and auditable. Evolveum midPoint provides the identity governance tools to automate GDPR compliance at scale.

Why Identity Governance Matters for GDPR

GDPR Articles 5, 25, and 32 require organizations to implement appropriate technical measures to protect personal data. In practice, this means knowing exactly who has access to what personal data, why they have it, and being able to prove it to regulators on demand.

Manual access reviews using spreadsheets fail at scale. They are slow, error-prone, and impossible to audit reliably. An IGA platform like midPoint automates the entire process.

Access Certification Campaigns

midPoint’s access certification feature allows you to run automated review campaigns where managers and data owners periodically verify that each user’s access is still appropriate.

Key capabilities:

  • Scheduled campaigns: Run quarterly, semi-annual, or event-triggered reviews
  • Role-based reviews: Managers certify access for their direct reports
  • Application-based reviews: Data owners certify who has access to their systems
  • Escalation: Unreviewed items escalate automatically after a deadline
  • Remediation: Rejected access is automatically revoked via midPoint provisioning

Segregation of Duties (SoD)

GDPR requires that access controls prevent unauthorized combinations of privileges. midPoint’s SoD engine defines exclusion policies that prevent toxic role combinations:

  • A user who can create payments cannot also approve payments
  • A user with HR data access cannot also have payroll system admin rights
  • System administrators cannot assign themselves elevated privileges

Violations are detected in real time and can trigger automatic remediation or approval workflows.

Audit Trail and Reporting

midPoint maintains a comprehensive audit log of every identity event:

  • Who was granted or revoked access, by whom, and when
  • Every role assignment, modification, and deletion
  • All certification campaign decisions with reviewer identity and timestamp
  • Policy violation detections and remediation actions

These logs are exportable and can feed into SIEM systems for centralized compliance monitoring.

Right to Access and Right to Erasure

When a data subject exercises their GDPR rights, midPoint helps you respond:

  • Right to access (Article 15): midPoint can generate a report of all systems and roles assigned to a specific identity
  • Right to erasure (Article 17): midPoint’s de-provisioning workflows can systematically remove a user’s accounts across all connected systems

Data Minimization Through Role Engineering

GDPR’s data minimization principle (Article 5) requires that users only have access to the data they need. midPoint’s role mining and role engineering capabilities help you:

  • Analyze existing access patterns to identify over-provisioned users
  • Design lean role structures based on actual job functions
  • Automatically assign and revoke roles based on HR data (joiner/mover/leaver)

Get GDPR-Ready with midPoint

WeKnowIdentity configures midPoint’s governance engine to meet GDPR requirements from day one. We handle access certification setup, SoD policy design, audit configuration, and integration with your HR and compliance systems. Contact us for a free compliance assessment.

Related Resources

midPoint on Kubernetes: A Production Deployment Guide

by with No Comment

Deploying Evolveum midPoint on Kubernetes brings scalability, reproducibility, and infrastructure-as-code practices to your identity management platform. This guide covers the key considerations for a production-grade midPoint Kubernetes deployment.

Why Kubernetes for midPoint?

Traditional midPoint deployments on bare-metal or VMs work well, but Kubernetes offers distinct advantages for organizations that need:

  • Horizontal scaling for large identity populations
  • Reproducible environments across dev, staging, and production
  • Automated failover and self-healing
  • GitOps-driven configuration management
  • Consistent deployment across cloud providers (AWS EKS, Azure AKS, GCP GKE)

Architecture Overview

A production midPoint Kubernetes deployment typically consists of:

  • midPoint application pods: The core midPoint instances, typically 2-3 replicas for high availability
  • PostgreSQL database: midPoint’s repository, deployed as a StatefulSet or using a managed database service (RDS, Cloud SQL)
  • Persistent storage: For midPoint home directory, keystores, and configuration files
  • Ingress controller: NGINX or Traefik for HTTPS termination and routing
  • ConfigMaps and Secrets: For environment-specific configuration without rebuilding images

Helm Charts for midPoint

Helm charts simplify midPoint deployment by packaging all Kubernetes resources into a single, versioned, configurable unit. A well-structured midPoint Helm chart includes:

  • Deployment/StatefulSet for midPoint pods
  • Service and Ingress definitions
  • ConfigMap for midPoint configuration XML
  • Secret for database credentials and keystores
  • PersistentVolumeClaim for midPoint home
  • Health check probes (liveness and readiness)

Values files allow you to customize the deployment per environment without modifying the chart itself.

GitOps Configuration Management

GitOps takes Kubernetes deployment to the next level by treating your entire midPoint configuration as code stored in Git:

  • ArgoCD or Flux watches your Git repository for changes
  • Any midPoint configuration change (roles, policies, resource definitions) is committed to Git
  • The GitOps tool automatically applies changes to the cluster
  • Full audit trail of every configuration change with Git history
  • Easy rollback by reverting a Git commit

This approach is especially valuable for regulated environments where you need to demonstrate who changed what and when.

Production Hardening Checklist

Before going live, ensure:

  • Database backups are automated and tested
  • TLS certificates are configured for all endpoints
  • Resource limits (CPU, memory) are set on all pods
  • Pod disruption budgets prevent all replicas from going down simultaneously
  • Monitoring and alerting (Prometheus/Grafana) are configured
  • Log aggregation (ELK or Loki) captures midPoint audit logs
  • Network policies restrict pod-to-pod communication
  • Secrets are managed via external secrets operator or vault

Common Pitfalls

  • Shared midPoint home directory: When running multiple replicas, the home directory must be on shared storage (NFS, EFS) or each pod needs its own PVC
  • Database connection pooling: Configure connection pool sizes carefully to avoid exhaustion under load
  • Startup time: midPoint takes time to initialize. Set generous initialDelaySeconds on liveness probes to prevent restart loops
  • Session affinity: If using the midPoint GUI across replicas, configure session affinity on the service or use sticky sessions

Need Help with Your Kubernetes Deployment?

WeKnowIdentity specializes in Kubernetes-native midPoint deployments. We have delivered production environments on EKS, AKS, and bare-metal Kubernetes clusters for enterprise clients. Contact us for architecture guidance.

Related Resources