Which three stakeholders use IAM directly, what does each do with it, and what does each want?
The user (authenticates and is authorised; wants it simple, ideally SSO), the IT administrator (configures their system's IAM connection and holds privileged identities; wants simplicity and automation) and the developer (programs the IAM connection and needs IAM for the development environment; wants simplicity and standards).
* Three direct users, three ways of touching IAM, one shared wish: keep it simple. *
| Stakeholder | Synonyms | Relationship to IAM | Wish |
|---|---|---|---|
| User (Anwender) | user, Benutzer | Is authenticated at login and authorised for the application | As simple as possible: SSO |
| IT administrator | OPS, operations | Configures the IAM connection of their IT system (parameters); holds privileged identities | As simple as possible: automation |
| Developer | DEV, development | Programs the IAM connection of applications via an API; needs authentication and authorisation for the development environment too | As simple as possible: standards |
All three share the same wish, simplicity, but mean different things by it. The user wants to log in once. The admin wants accounts and settings to flow automatically, not by hand. The developer wants a well-documented standard (OIDC, SAML, SCIM) and a library, not a proprietary interface.
Two details deserve attention. The administrator's privileged identities (admin accounts with far-reaching rights) are the most attractive target for attackers and need special protection, which is a field of its own (privileged access management). And developers are not only implementers but also subjects of IAM: their access to source code, build pipelines and test systems must be managed like any other access.
Go deeper:
Privileged access management (Wikipedia) — why admin identities need their own controls.- How OpenID Connect works (OpenID Foundation) — the kind of standard developers want when they connect an application.