3. Basic Requirements

The basic authorization pattern serves as a minimum bar for application of IAM principles to a cloud-native application. In this model, authentication and authorization is performed primarily by the primary workload which receives the user's access token or session state. Note that the authentication and authorization (PEP) is performed by the workload using resource-specific parameters supplied to the PDP, and is not implemented by ingress or gateway rules which only have access to the request context.

3.1. Common Requirements

Implement the requirements from FAPI and RFC 9700. For human users, apply the appropriate assurance levels from NIST SP800-63.

note: this covers TLS (FAPI), ID verification (SP800-63A), multiple auth factors (SP800-63B), federation security (SP800-63C), authorization code flow (RFC9700), including many other requirements not currently specified in the whitepaper.

Implement authorization (PEP) using a consistent framework or pattern which supports checking authorization at both the resource (object) level and on specific parameters and object methods. Select a framework or pattern which will "fail closed" in the absence of a resource check - for example, requiring a PEP check definition associated with each endpoint. Consistent access control patterns can help avoid broken authorization checks, 3 of the OWASP Top 10 API Security Risks 2023.

note: this implicitly adopts the NIST SP 800-162 P*P architecture by reference, in addition to covering the OWASP Top 10 API list, with specific actions to take.

Workloads which make authorization decisions (PEPs) should log all requests. These logs should include a unique per-request identifier and the authorization decision, but MUST not include sensitive information such as access tokens or PII. Prefer logging generated identifiers such as object UIDs which can be anonymized later by deleting the resource to avoid privacy issues.

note: this covers both Workload #1 and Workload #2 components, reducing duplication.

3.2. Initial Workload (Workload #1) Requirements

Workloads will receive an ID token either from the client, or from the OIDC OP as part of a stateful session establishment. This token must be validated following the OIDC Core specification before using the identity in authorization decisions. Stateful clients take on the additional requirement of safely managing the session state, including logout and timeout functionality.

Once the user has been authenticated, the workload acts as the primary PEP, calling the PDP for authorization decisions and logging the results as needed. The workload may additionally choose to further propagate the user's identity for additional PEP checks to workloads within the cluster (e.g. workload #2), supplying either the original ID token or an internal access token received via token exchange. Internal access tokens may contain additional sensitive information not exposed outside the cluster, or may provide additional security guarantees such as RFC 8705 or RFC 9449 binding of tokens to clients.

note: I've omitted several of the "can optionally do X" informational requirements, as "can optionally do" isn't really a requirement.