Contact
All systems System

Identity and access management

A role-based access model for users and systems, with one identity provider for all applications and single sign-on for Microsoft 365, SaaS and internal applications over OIDC or SAML. Every user, service account and key is listed with where it has access, and secrets are kept in a secrets manager.

Describe what you need

What you get

  • An identity map of every user, service account, automation and key, with where each one has access
  • An access model of roles, permissions and boundaries between systems, applied through role-based groups
  • Authentication in one consistent, documented way: single sign-on (SSO) for Microsoft 365, SaaS and internal applications over OIDC or SAML, and tokens or keys for systems
  • One identity provider for all applications, accepting existing Microsoft, Google and other OIDC or SAML accounts, and on-premises Active Directory accounts over LDAPS, with SCIM provisioning where applications support it
  • Secrets kept in a secrets manager, and an inventory of service accounts and keys with what uses each one and how it is rotated
  • Onboarding and offboarding tied to roles, with documentation of how to add and remove access

How it works

  1. 01

    Map identities

    We list every user, service account, automation and key, and where each one has access.

  2. 02

    Design the access model

    We define roles, permissions and boundaries between systems from real usage, so access matches responsibilities.

  3. 03

    Set up authentication and credential handling

    Users and systems authenticate in one consistent, documented way, with SSO, tokens or keys. Secrets are kept in a secrets manager and rotated without anyone having to remember it.

  4. 04

    Connect the systems

    Microsoft 365, SaaS and internal applications sign in through the identity provider with OIDC or SAML. It accepts Microsoft, Google or any other OIDC or SAML account, and on-premises Active Directory over LDAPS, with SCIM provisioning or a custom brokering layer where needed.

  5. 05

    Document and hand over

    We document how access works, including how to add and remove it, and hand it over to your team.

Problems it solves

  • ProblemAccess granted temporarily for an old project is still active, so people hold rights their current job does not need.

    SolutionAccess is granted to role-based groups instead of individuals, so it can be reviewed per role and removed when a role changes.

  • ProblemOne login is shared across the team, so nobody can tell who did what, and changing its password disrupts everyone.

    SolutionShared logins are replaced with personal and service identities wherever the application allows it, with SSO where supported. Actions can then be traced to a name.

  • ProblemService accounts and API keys created by people who have left are still in use, so rotating them risks an outage.

    SolutionEvery service account and key is recorded with what uses it, secrets move to a secrets manager, and rotation stops depending on someone's memory.

  • ProblemStaff sign in to the network with Active Directory accounts, but every new cloud application asks for a separate login.

    SolutionThe identity provider checks Active Directory credentials over LDAPS, so people use their existing username and password everywhere. Microsoft, Google or other OIDC and SAML accounts can sign in too.

  • ProblemNew starters get access from an informal checklist, and leavers keep theirs until someone remembers to remove it.

    SolutionOnboarding and offboarding are tied to roles, with SCIM provisioning where applications support it, so new starters get access on day one and leavers lose it when they leave.

What it covers

  • For exampleZITADEL, Keycloak, Entra ID, Okta
  • SSO for Microsoft 365, SaaS and internal apps
  • Sign-in with Microsoft or Google accounts
  • Any OIDC or SAML identity provider
  • Active Directory over LDAPS
  • SCIM provisioning
  • Access through role-based groups
  • For exampleHashiCorp Vault
  • Onboarding and offboarding by role
Typical scope

Typical engagements run 2–6 weeks, depending on how many systems are involved, how tangled the current access is, and whether an existing model is cleaned up or replaced.

Next step

Send a short description of what you need and the systems involved. We reply with proposed next steps.

Describe what you need