IAM Capabilities and Boundaries designed
This page is the concrete IAM reference for platform reviewers and service owners. It explains what the product IAM model owns, what the identity provider owns, and where service accounts and MFA fit.
Boundary Model
| Capability | Platform IAM owns | Identity provider owns |
|---|---|---|
| Human login session | Product session use, product-scoped read model, authorization meaning | OIDC login, token issuance, JWKS, refresh, logout |
| Membership and roles | Tenant/project/platform memberships, role bindings, capability bundles | Not authoritative |
| Service accounts | Ownership, scopes, rotation policy, audit, lifecycle | Not authoritative |
| MFA | Product posture, requirement state, recovery and UX integration | Factor enrollment and human-factor enforcement |
| API keys and machine auth | Product scope model and audit path | Not authoritative |
Core rule: the external IdP is an authentication boundary, not the product IAM source of truth.
Canonical IAM Objects
| Object | Purpose |
|---|---|
| Principal | Human, service account, or group that receives access |
| Membership | Places the principal into tenant or project scope |
| Role binding | Grants capability bundles at platform, tenant, or project scope |
| Service account | Machine principal for scoped automation and app/runtime control |
| Invitation | Controlled entry path into tenant/project membership |
| External identity binding | Authn anchor, not authorization truth |
Service Accounts
Service accounts are first-class product actors.
Use them for:
- app controllers and runtime operators;
- project or tenant automation;
- scoped API access where a human session is not appropriate.
Do not use them for:
- human admin work;
- MFA-sensitive human actions;
- hidden bypasses around tenant/project authorization.
Service-account expectations:
- ownership is explicit;
- scopes are minimal;
- rotation and disable paths are auditable;
- product APIs treat them differently from human principals.
MFA
MFA belongs to the human authentication boundary, but the product still has to express the result usefully.
Product responsibilities
- show the account’s MFA posture and session evidence;
- route setup and management through the account security flow;
- expose recovery and removal boundaries;
- keep sensitive-operation step-up separate from ordinary sign-in posture.
Provider responsibilities
- verify TOTP, WebAuthn, or other human factors;
- enforce the configured browser-login flow;
- issue tokens or sessions after the factor step.
Important exclusions
- service accounts are not MFA subjects;
- API keys are not MFA subjects;
- break-glass handling is not ordinary self-service MFA.
IAM Scope Hierarchy
What IAM Reviewers Usually Need
| Question | Open first |
|---|---|
| What does platform IAM own versus Keycloak? | this page |
| How does MFA work from product and provider perspectives? | this page, then MFA Walkthrough |
| How should service accounts be used by apps and operators? | this page, then Add a New App |
| How do tenant/project boundaries affect authz? | Tenant, Billing Unit, Department, and Project Hierarchy |
Current Portal Gap This Page Closes
Previously the IAM path mostly told readers what else to read. This page is the portal-native answer for the three recurring IAM questions:
- where product IAM stops and provider auth starts;
- how service accounts should be treated;
- how MFA fits without making the IdP the whole product model.
Canonical sources