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 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.
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.
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:
| Method | Use |
|---|---|
azure_cli | Local development using the signed-in engineer. |
managed_identity | A supported Azure runtime with an assigned identity. |
workload_identity | A pipeline with configured OIDC federation, such as GitHub Actions. |
client_secret | A 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:
- Which system is authoritative for each data item, and who owns its quality?
- Which steps in joining, changing roles and leaving are still manual?
- How are errors surfaced, followed up and reprocessed?
- 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
