SSO, federation and provisioning: three different parts of the access journey

The demonstration works. An employee clicks the application tile, signs in and sees the right screen. For an application owner, that is a promising start. It says little about what will happen when the employee changes job, leaves the company or already has a second account inside the application.

Identity procurement often compresses those questions into one requirement: “supports SSO”. That phrase describes an important part of the experience, but a complete integration needs separate answers for authentication, account maintenance and permissions.

What each term contributes

Single sign-on describes the ability to access multiple applications without repeatedly completing separate sign-in journeys. Federation is a trust arrangement in which an application relies on identity information from another system. Provisioning creates and maintains accounts and related attributes in the target system. Authorisation decides what those accounts can do.

These mechanisms can cooperate without being interchangeable. An application can accept a federated login while its accounts remain manually maintained. It can create an account at first login without maintaining that account through every subsequent employment change. A successful login does not establish either outcome.

Microsoft Entra’s provisioning documentation describes using an application’s SCIM endpoint to create, update and remove users. The documented process also depends on attribute mappings and scope. Those are integration decisions beyond the login protocol.

Follow a role change, not just a login

Consider a hypothetical employee moving from procurement to finance. The identity provider still recognises the same person, and single sign-on still works. The business question has changed: which procurement permissions should end, which finance permissions should begin, and who can approve a temporary overlap?

The application may receive a new department attribute but leave a locally assigned role untouched. Alternatively, it may correctly update the role while retaining a separate local account created before the integration. Neither issue is visible in a demonstration limited to authentication.

Specify the expected application outcome. If the employee should lose purchase-order approval rights, inspect that permission in the application. Do not substitute a successful identity-provider event for the result the business needs. For SaaS lifecycle management, the destination is where completion matters.

Account matching is a business continuity issue

Before enabling account creation at scale, establish how existing application accounts will be matched to incoming identities. A changed email address, inconsistent naming convention or historical duplicate can turn a straightforward integration into a resource-ownership problem.

An employee might successfully enter a newly created account and find that the documents, approvals or records associated with the old account are missing. The authentication is correct; the migration outcome is wrong. Application owners should therefore test continuity of work, not simply access to a landing page.

Agree which system owns each maintained attribute. If administrators can change a value locally and a later synchronisation overwrites it, the support team needs to understand that behaviour. Otherwise it may repeatedly “repair” a value that the integration is deliberately managing.

The departure test needs more than one observation

Disabling new sign-ins, changing an application account and ending an existing session are separate events. Their relationship depends on the application and integration. Test the departure path your organisation needs, including established sessions and any local access route, rather than assuming they all end together.

A manual step can be an acceptable interim arrangement when it is visible, resourced and bounded. Calling that arrangement automated offboarding hides the work and makes the service harder to manage. Put the retained task into the operating cost and acceptance criteria.

Write the requirement as an outcome

A useful integration specification says who must gain access, what they must be able to do, how a role change takes effect and how departure is confirmed. It then identifies the mechanisms that support each outcome.

That gives suppliers a fairer test and application owners a clearer handover. Use the IAM evaluation guide to turn those outcomes into a common demonstration. The login is one scene in the access journey; buy the rest of the journey deliberately.