Capabilities
Identity and Access Control extends beyond authenticating users and checking permissions. As applications grow, they often require support for multiple organizations, enterprise identity integration, complex access policies, and programmatic access by external applications and services.
These requirements can be organized into four major capabilities. Each addresses a distinct problem and can be introduced as the application's needs evolve, although some depend on shared identity, authentication, and authorization foundations.
Capabilities
-
Multi-Tenancy: Organize identities, memberships, and permissions across independent tenants within a shared application.
-
Enterprise Identity & Governance: Integrate with enterprise identity infrastructure through SSO, directory synchronization, automated provisioning, and access governance.
-
Fine-Grained Authorization: Control access to individual resources using roles, ownership, relationships, sharing permissions, and contextual policies.
-
API & Machine Access: Authenticate and authorize external applications, services, and automated agents through API credentials, machine identities, scoped tokens, and delegated access.
Support Across Scopes
Each capability can be delivered under different ownership scopes. The distinction is not necessarily whether a capability is available, but which components provide it and which responsibilities the application retains.
| Capability | Managed | Hybrid | Built |
|---|---|---|---|
| Multi-Tenancy | 🔗 Broker-managed organizations and memberships; application enforces tenant isolation. | 🔀 Broker-managed identities with application-owned tenants, memberships, and access policies. | 🛠️ Organization, membership, and isolation models implemented internally. |
| Enterprise Identity & Governance | 🔗 Broker-managed federation, provisioning, directory synchronization, and governance, where supported. | 🔀 Broker handles federation and identity provisioning; application owns access governance and permissions. | 🛠️ Federation, provisioning, directory integration, and access governance implemented internally. |
| Fine-Grained Authorization | 🔗 Broker-managed policies and permissions, subject to platform capabilities. | 🛠️ Application-owned authorization model, evaluated locally or through a dedicated engine. | 🛠️ Authorization policies, relationships, evaluation, and enforcement implemented internally. |
| API & Machine Access | 🔗 Broker-managed API clients, machine identities, credentials, tokens, and scopes. | 🛠️ Application-owned API clients, machine identities, credentials, token issuance, scopes, and access policies. | 🛠️ Complete ownership of machine authentication, credential management, token issuance, and authorization. |
The selected ownership scope influences the implementation strategy, but does not automatically determine which capabilities can be supported. Platform functionality, application requirements, security constraints, and operational responsibilities must be evaluated individually.
Capabilities may also share underlying mechanisms. For example, enterprise provisioning may create organizational memberships, while machine identities may participate in the same authorization policies as human users. These mechanisms should be designed consistently rather than implemented independently for each capability.
Access auditing remains a foundational IAM responsibility rather than a separate optional capability. Authentication activity, permission changes, and security-relevant authorization decisions should produce appropriate events. Durable retention, investigation, search, and export belong to the Audit Trails subsystem.