Microsoft Entra ID · Single Sign-On

Application integration with SAML

Summary

Several applications authenticated directly against local LDAP. We moved authentication to Microsoft Entra ID with SAML to reduce this dependency, make password management easier outside the organisation and prepare the applications for MFA and access policies.

My role: Requirements analysis, SAML configuration, attributes and validation.
Scope: Several applications and user groups with different requirements.
Result: Authentication centralised in Microsoft Entra ID.
Environment: Microsoft Entra ID, SAML, certificates and dynamic groups.

Simplified authentication flow Attributes change depending on the application

UserCorporate account

IdentityMicrosoft Entra ID

AssertionSAML and attributes

DestinationEnterprise application

The problem

Some applications authenticated directly against the local LDAP server. This created a dependency on local infrastructure and limited access management, especially for password changes, MFA and policies that we wanted to centralise in Microsoft Entra ID.

The first integration looked simple, but I soon learned that using SAML does not mean every application expects the same configuration.

Decisions

First understand what each provider expects: Before configuring Entra ID, I reviewed identifiers, reply URLs, certificates and required attributes.
Separate user groups when access is different: In one integration, staff and students needed different applications. I used dynamic groups to manage the assignments.
Test before expanding access: Each integration was validated with test users and the provider before expanding the assignment.

Implementation

For each application, I prepared the enterprise application in Microsoft Entra ID, configured SAML, exchanged metadata with the provider and adapted the required attributes.

The part that changed most was the content of the assertion: user identifier, user groups, certificates or specific formats. When there was an error, I checked the information sent by Entra ID and compared it with what the provider expected.

In each case, I validated authentication with test users and reviewed attribute or certificate errors with the provider before expanding the assignment.

Result

Several applications now authenticate through Microsoft Entra ID instead of querying local LDAP directly. Users keep the same corporate identity, and authentication is ready for MFA and access policies from Entra ID.

I now follow the same process for new integrations: review requirements, configure attributes, test with a small group and expand access when the flow has been validated.