IAM / IAM-02
Single sign-on and identity federation
Centralised application sign-in using a governed identity, with access policies, monitoring and emergency access.
WHEN IT HELPS
A focused response
to a defined need.
CIO or application owner; scattered passwords, SaaS deployment or a shared access portal.
SCOPE & OUTCOMES
What the engagement covers.
Scope
- Select the identity provider
- integrate SAML/OIDC as supported
- configure roles, sessions, logs and emergency procedures
Deliverables
- Connected applications
- role matrix
- documentation, access tests and recovery procedure
Acceptance evidence
Authorised profiles reach the correct functions and others are denied; emergency access is tested and governed.
DELIVERY
How the work is structured.
Approach
Inventory identities and applications; define roles and policies; pilot with one group; test allow/deny/recovery paths; roll out and hand over.
Prerequisites & responsibilities
Customer: application owners, HR, administrators, pilot groups and emergency accounts. Provider: design, integration and testing within agreed permissions.
Scope factors
Users, directories, applications, protocols, privileged accounts, compatibility and migration. Licenses, physical keys and recurring operations are separate.
Questions to clarify
Which applications support federation? Which roles exist? How is access recovered if the identity provider fails?
IMPORTANT BOUNDARIES
SSO creates a critical dependency and does not replace MFA; verify revocation, sessions and availability.
Recovery and emergency access are tested before rollout. Authentication, authorisation and privileged-access management are complementary layers.
IN PRACTICE
Illustrative situations.
These examples describe possible engagements and target outcomes. They are not customer references or achieved results.
Scenario 01
An SME has five technical consoles with separate accounts. Project: federate access and map groups. Target outcome: consistent sign-in and centralised revocation, with emergency accounts outside normal use.
Scenario 02
A partner extranet applies inconsistent application roles. Project: define a shared matrix and test profiles. Target outcome: organisation-specific access; successful sign-in does not authorise all data.
Technology and reference context
Keycloak, Entra ID or a compatible SAML/OIDC provider; confirm compatibility and licensing.
The final technology set is agreed during scoping, based on interoperability, licensing, access rights and operating requirements.
CONNECTED SERVICES
Build the next step.
These services can complement the engagement. They are not automatically included.
START A CONVERSATION
Make the scope clear.
We will clarify the objective, dependencies and responsibilities of this service before proposing delivery.