All insights
Identity & security Article

Taking control of identity

From MIM to an open synchronisation chain.

How Wigo4it connected AFAS, Keycloak and Entra ID to reduce duplicate administration and make identity operations easier to understand.

English edition of the article by Pascal van der Horst on developer.overheid.nl, originally published on 3 April 2026 in his role as Platform & Cloud Engineer at Wigo4it.

The architecture in one sentence. AFAS supplies employee data, Keycloak is the central identity store and Entra ID retains its role for Microsoft services and the existing security setup.

In this article

When identity means doing the same work twice

A new colleague joins. HR records their details, IT prepares the account and several systems need to keep reflecting the same reality. Without a connection between those steps, reliability depends on people copying changes at the right time.

At Wigo4it, HR worked in AFAS while IT also maintained users in Microsoft Identity Manager (MIM). There was no automatic connection between the two systems. A new employee or a name change therefore meant extra work and an opportunity for the records to diverge.

The question behind the migration was practical: how can employee data become the authoritative source, how can manual administration be reduced while preserving architectural choice?

AFAS and MIM were not automatically connected. IT copied HR changes into MIM, which synchronised with Entra ID.AFAS and MIM were not automatically connected. IT copied HR changes into MIM, which synchronised with Entra ID.
The previous situation: manual transfer between the HR and IT records.

AFAS as the source. Keycloak as the link.

The new chain uses AFAS as the authoritative source for employee data. The first synchronisation step retrieves and validates that data, then processes it in Keycloak. The second step synchronises the identities from Keycloak to Microsoft Entra ID.

Keycloak provides a central identity store. Entra ID continues to support Microsoft services. Separating these roles makes it clearer which system owns which data and where changes are processed.

AFAS supplies employee data to Keycloak. A second synchronisation step processes identities in Entra ID.AFAS supplies employee data to Keycloak. A second synchronisation step processes identities in Entra ID.
The provisioning flow. This diagram does not describe the sign-in route.

Open components do not automatically make a platform portable. Data models, configuration and knowledge of each component still matter. Open source also brings responsibility for updates, security, availability and maintenance. Replacing an identity platform remains a change that needs design and testing.

Why Entra ID remains part of the solution

Wigo4it runs its cloud infrastructure in Azure. Microsoft 365 and the existing security setup also use Entra ID. Those functions have an established place in the environment:

  • Identity Governance supports access management and periodic access reviews.
  • Privileged Identity Management supports temporary activation of administrative permissions, with configured approval and control processes.
  • Conditional Access applies access policies based on signals including device, location and risk.
  • Microsoft 365 uses Entra ID for services such as Teams, SharePoint and Exchange.

The architecture preserves these functions while making HR data processing less dependent on MIM. Digital autonomy becomes a practical capability: deciding where data comes from, how it is processed and which parts can be changed.

“Autonomy does not remove risk. It puts it in your hands.”

Translated from the original article by Pascal van der Horst

Reliable automation starts at the source

Automated synchronisation only helps when its input is usable. The process therefore checks required fields, email address structure and expected telephone number formats. JSON schema validation helps identify deviations early.

If a required field is missing, that user is skipped and the responsible team is notified. HR remains responsible for employee data; IT manages the integrations and their processing.

Offboarding belongs in the design too

The employment end date in AFAS drives the account lifecycle. Active users are updated. When employment ends, the synchronisation disables their accounts in Keycloak and Entra ID. After a configured period, the accounts are deleted from both systems.

Active accounts are updated. Accounts are disabled when employment ends and deleted after the configured retention period.Active accounts are updated. Accounts are disabled when employment ends and deleted after the configured retention period.
The account lifecycle in the published case. The organisation sets the retention period.

A complete offboarding process also needs to address existing sessions, application access and retention obligations. These broader checks matter when applying this approach elsewhere; the diagram only shows the account processing described in the case.

Make the processing visible

Events trigger Teams notifications to HR, the operations team and, where relevant, office management. Examples include a created or deleted user, an incomplete profile or a failed account creation.

A periodic overview counts created, updated, disabled, deleted and failed operations. An audit log records actions, timestamps and outcomes, making it easier to see when the chain needs attention.

Designed for testing and handover

The solution consists of Bash scripts and JSON configuration. Its steps are modular: retrieve, validate, transform and process data. An API change can be addressed in the relevant component while checking the consequences for the rest of the chain.

In the original publication of 3 April 2026, Pascal van der Horst described 333 automated tests covering the two synchronisation pipelines and shared utilities. The tests use BATS and cover new employees, changes, departures and invalid profiles. This count describes that point in time; it is not a current quality measurement.

A dry run performs authentication and validation and shows planned actions without executing the associated changes. This supports acceptance and handover. Its output still needs to be treated as sensitive information: identity data in logs and reports requires restricted access and appropriate retention periods.

Authentication that fits the environment

The solution supports four authentication methods for Azure connections:

MethodUse
azure_cliLocal development using the signed-in engineer.
managed_identityA supported Azure runtime with an assigned identity.
workload_identityA pipeline with configured OIDC federation, such as GitHub Actions.
client_secretA service principal with a managed, rotated secret.

Where supported by the runtime, managed identity and workload identity are preferred. They avoid a long-lived client secret for that Azure connection. Permissions, federation conditions and other credentials in the chain still require attention.

Lessons for other organisations

The outcome described in the original article is primarily operational: duplicate user administration is removed, personnel changes are processed automatically and responsibilities between HR and IT are clearer. The dependency on the MIM server is removed while the selected Microsoft services remain.

The case does not publish quantified savings or lead-time measurements. Its value lies in the structure of the chain and the controls around it.

Four questions provide a starting point for a similar project:

  1. Which system is authoritative for each data item, and who owns its quality?
  2. Which steps in joining, changing roles and leaving are still manual?
  3. How are errors surfaced, followed up and reprocessed?
  4. Can the operations team test, review and hand over changes?

The right solution follows from those answers. In this case, combining AFAS, Keycloak and Entra ID brought greater coherence to the identity landscape. The broader lesson is that autonomy also requires day-to-day care: clear responsibilities, visible processing and a maintainable architecture.

About this publication
This experience concerns Wigo4it. The original publication names Pascal van der Horst as author and Platform & Cloud Engineer at Wigo4it. This edition does not present the project as a client engagement for Horst IT Consultancy.

Read the original Dutch article. The diagrams were redrawn from the described architecture. Guidance on operations, logging and applying the approach elsewhere includes editorial additions.

Greater control over identity and operations.

From an HR change to application access: a clear chain starts with understanding the current environment. Horst IT Consultancy provides support with architecture, automation and operations.

Discuss an identity challenge