Identity management connects people, applications and platforms through traceable identities and access. The starting point is therefore an organisational question: who needs access to what, who approves it and when does it end? A new sign-in portal alone does not answer these questions.
Verify identity, grant specific access
Authentication verifies who is signing in. Authorisation determines which data and functions that identity may use. An identity provider can handle sign-in for several applications; business-level permissions still need to be enforced in the connected systems. OpenID Connect describes how identity information is communicated and validated [1].
Single sign-on (SSO) reduces repeated sign-ins. Sign-in planning needs to cover multifactor authentication (MFA), recovery paths and controlled emergency access. It also matters whether critical actions require another check. A lost device should cause neither uncontrolled access nor permanent exclusion.
Manage joining, moving and leaving throughout
The lifecycle starts with a reliable source, such as an HR system or maintained directory. Joining means granting the access needed. A change of responsibilities means adding new permissions and reviewing existing ones. Leaving means withdrawing access. These phases are called joiner, mover and leaver [2].
Each transition needs a trigger, an accountable owner and verification in the target system. Disabling a central account does not automatically end every existing session. Applications, tokens and local accounts must be covered by the withdrawal process. Guests and temporary project access also need an expiry date and a responsible person.
Distinguish sign-in from account provisioning
Different protocols address different integration needs. OpenID Connect and SAML enable federated sign-in; the target application trusts validated information from an identity service [1][3]. SCIM defines interfaces for creating, changing or removing identity data such as users and groups [4].
An SSO integration therefore does not automatically maintain accounts. Before selection, check which protocols, attributes and access-removal functions each application actually supports. Where integration is missing, a documented alternative process with verifiable completion is needed.
Limit roles and machine identities
Roles should reflect business responsibilities and group permissions clearly. Sensitive privileges need approval, limited validity and regular review. Too many broad roles merely move the complexity into exceptions.
Applications and automations need their own machine identities with clear ownership. They should not share personal accounts. Their permissions, credentials and lifetimes need separate management; unused identities must be identifiable. This also helps manage team changes without leaving unknown dependencies behind.
Plan selection and operations together
Keycloak, ZITADEL or Microsoft Entra ID can be components, depending on the environment. Existing applications, user groups, integration options and the intended operating model are decisive. Capabilities and operational responsibilities should be checked against the edition and deployment required.
The decision also includes updates, availability, logging, key rotation and recovery. A pilot should exercise sign-in, role changes and complete access removal in selected applications. The result is a verifiable integration decision with known limitations.
What you can decide first
- Which source reliably supplies identities and changes.
- Who approves, reviews and removes roles.
- Which applications are connected first and how access removal is demonstrated.
- Who operates the identity service and remains able to act during outages.
Sources
- OpenID Connect Core 1.0OpenID Foundation
- What are lifecycle workflows?Microsoft Learn
- SAML 2.0 Technical OverviewOASIS
- RFC 7644: SCIM ProtocolIETF