An Enterprise AWS Tenant Needs a User Identity Lifecycle Contract

Separate enterprise SSO, tenant membership, administrator scope and session withdrawal from AWS workload identities, using explicit lifecycle and denial evidence.

A separate AWS deployment does not establish an enterprise user lifecycle. Define how the customer's identity provider authenticates people, how the application grants current tenant membership, what a tenant administrator can change and how access ends across sessions, APIs and delayed work. Keep AWS workload and cloud-administration identities in separate records. They answer different permission questions.

This article helps a product security owner and customer identity administrator qualify enterprise single sign-on (SSO) for one tenant. It uses Amazon Cognito user pools as a documented federation example, not a required architecture. All users, timings, case counts and expected outcomes are fictional teaching inputs. No identity provider, AWS service, customer session or account was tested. The article does not certify compliance, supply a production policy or authorize changes to a customer's identity configuration.

1. Write three identity boundaries before choosing the login screen

The enterprise identity provider, or IdP, establishes an authenticated person according to its configuration. The application then decides which tenant memberships and actions are permitted. AWS workload identity grants a running service access to selected cloud resources. A person who can view a report should not inherit the worker's ability to read an entire store, and a worker's IAM role should not stand in for a person's tenant membership.

Amazon Cognito's SAML guidance distinguishes user-pool sign-in federation from separately configured identity-pool federation. User pools can process Security Assertion Markup Language (SAML) assertions and issue JSON web tokens (JWTs) for applications. That service behavior does not decide your application's tenant membership, administrative delegation or data ownership. Document those decisions alongside the selected relying-party configuration.

For each boundary, identify its authoritative record and changing owner. The customer may operate the enterprise directory while the vendor maintains application memberships. A permitted provisioning integration may update those memberships, but its accepted fields and lifecycle semantics still need review. Do not assume that enabling federation also enables a particular provisioning protocol or guarantees that directory deletion propagates to every application permission.

Cloud administration needs another duty allocation. A customer identity administrator might configure enterprise users without permission to change AWS resource policies. A vendor platform engineer might administer deployment identities without authority to grant customer business roles. Record the distinction even when one person performs several duties. Consolidating people does not make the underlying trust and permission questions interchangeable.

2. Bind a stable person to an explicit tenant membership

Use a reviewed provider-and-subject relationship to identify the person. Resolve that identity to a current internal membership before accepting a tenant action. An email domain can help a user find the correct login path, but it should not by itself grant membership. A person can work for several organizations, an address can change and a reused address can belong to another person later.

For the Cognito SAML example, AWS identifies a returning federated user through the case-sensitive NameId claim and recommends using an attribute whose value does not change. Its documented mapping behavior explains why changing an email-based NameId can disrupt sign-in. Treat a changed identity mapping as a migration needing reviewed ownership, rather than automatically merge two profiles because their display names match.

The application membership should specify the tenant, permitted role, status, source revision and the authority that may change it. A user in two organizations needs an explicit authorized active tenant for a request. A client-supplied tenant parameter remains untrusted until checked against current membership. The multi-tenant architecture paper covers enforcement across data, cache and queue paths; this article focuses on when membership changes and which evidence proves the change reached those paths.

Define exceptional relationships separately. A customer administrator can invite or manage users only within its accepted tenant scope. A delivery partner managing several customer installations needs an explicit relationship for each context. Support access should have a purpose, scope and expiry, rather than be represented as an ordinary customer membership with permanent platform-wide reach. Removing the support relationship should not delete the customer's business data.

3. Treat join, role change and leave as observable transitions

Joining requires more than a successful assertion. The application must establish the permitted membership and prevent unintended privilege. A first login might create a profile, but creation should follow the approved tenant-admission rule. An authenticated outsider with a valid assertion from the expected issuer is a useful negative case when that outsider lacks application membership. Preserve why the application denies it.

A role change needs an effective boundary. Specify which actions consult current authorization, what caches can retain and how queued work is handled. A worker can preserve the job's business inputs while rechecking whether the actor and tenant still have authority to execute. A stored role name in a job should not silently become an indefinite permission grant after the customer removes it.

Leaving requires separate checks for fresh sign-in, already issued sessions, refresh and relevant application APIs. Cognito's token-revocation documentation warns that revoked JWTs can still pass a library check that verifies only signature and expiry. Revocation for Cognito token-authorized operations and application enforcement are different boundaries. The application's accepted withdrawal behavior needs its own implementation and observations, including direct API calls outside the interface.

Returning later also needs an explicit rule. Re-enable or recreate membership only through its current approved authority. Decide whether the returning person retains past work, receives a new internal identity or requires reviewed reconciliation. Never use deletion and recreation of a profile as an unexamined fix for a mapping failure. The identity store and business data can have different lifecycle obligations.

4. Test a fictional departure that leaves a session usable

In fictional record U9, an enterprise administrator removes a report approver at 09:00 UTC. The IdP blocks a new login. At 09:02, the user's already issued application token remains within its signature and expiry checks. A queued export was admitted at 08:58. The teaching rule requires current membership for both a new approval and execution of that export. These timestamps are supplied assumptions; they are not measurements of propagation or AWS revocation.

The defective implementation denies the login but accepts the approval because its API checks only the token. It also runs the queued export from stored role text. The correct expected outcomes under this example's policy are denial of the new approval and a held export pending authorized disposition. The team must investigate the implementation gap, not declare offboarding complete from a blocked browser sign-in.

Authoritative change

U9 membership removed by the fictional customer administrator at 09:00. Actual production propagation evidence is uncollected.

Fresh login

Expected denied after removal. This tests the fresh authentication path, not an already issued application session.

Existing-session API

Expected new approval denied by current membership. Signature and expiry alone are insufficient for the stipulated rule.

Refresh and session lifecycle

Expected behavior must be declared for the selected mechanism and checked separately. No instant universal revocation claim.

Queued export

Expected held because current execution authority is missing. Preserve its work reference and any uncertain external effect.

Review disposition

Hold the offboarding completeness claim until all required paths have attributable evidence.

For a compact test plan, use three lifecycle changes: join, role change and leave. Apply four paths to each: fresh sign-in, existing-session direct API, refresh and queued work. Three times four produces 12 planned cases. This is a planning count, never 12 observed passes or exhaustive security coverage. Add tenant-administrator, mapping-change and recovery cases where the product requires them; the additional work cannot be implied by the original count.

5. Separate logout, withdrawal and business-effect recovery

Cognito's SAML single-logout documentation describes a configured sign-out flow to the IdP, with specific metadata and response requirements. It should not be interpreted as automatic offboarding across all application sessions, membership caches and background processes. Verify the selected browser flow separately from API authorization and any server-side session controls.

An IdP outage changes admission availability without necessarily ending existing application authority. Decide which supported sessions can continue under the accepted policy, which high-risk actions hold and how an authorized administrator investigates. A recovery route must be separately scoped and observable. Adding a shared permanent administrator account during the outage can undermine the boundary that enterprise federation was intended to provide.

Stopping new access does not reverse an earlier export or approval. Preserve the operation reference and destination evidence before retrying work. If an export might already have been delivered, an identity correction does not establish that it failed. The business workflow owner must reconcile the result. Keep this duty distinct from the administrator who restores sign-in or removes a membership.

When a claim mapping changes, hold admission for unresolved identities rather than guessing a match. A reviewed repair may restore the intended provider-subject relationship, with allowed and denied cases repeated. Record its effect on existing sessions and membership records. Changing a mapping until login succeeds is weak evidence if it silently admits the wrong person or transfers data ownership.

6. Build a reusable identity contract with explicit unknowns

Record the selected IdP, provider reference, stable-subject rule, application client and membership authority without copying assertions or tokens. Include the permitted tenant selection, administrator scope and lifecycle events. For each event, write an expected result for every relevant path, the observer, controlled evidence reference and the condition that invalidates the result. Use unknown where a required behavior is undocumented or untested.

Add authorization-cache and session limits as actual configured values with measured evidence. This article supplies no universal acceptable duration. The security owner should decide the workload's allowed exposure, and the implementation owner should demonstrate the chosen response. A local fixture can count cases and reject invalid counts, but cannot verify a real token or establish the actual delay of an identity change.

Test valid unintended identities as well as intended users. Include wrong tenant, expired support relationship, removed membership and a tenant administrator requesting platform administration. An invalid signature is useful cryptographic failure evidence but does not test an otherwise valid person's tenant denial. Distinguish transport or setup failures from the intended enforcement outcome before marking a case complete.

STOP when a subject cannot be mapped safely, a required lifecycle path remains observable only through administrator privileges or a denied user still receives protected data. Preserve the evidence and narrow the affected functionality through approved means. Recovery should restore the reviewed identity relationship and current authorization, then repeat affected cases. It should not broaden membership until a failing test becomes green.

7. Keep the customer-user contract separate from workload migration

The cloud workload identity paper supports the service process accessing AWS resources. Its principal, trust and refresh questions are necessary, but they do not replace this enterprise user contract. A correct worker identity can still execute a job whose customer membership was removed. A correct person identity can still be served by an overprivileged worker. Review the join between those boundaries explicitly.

Bring the product security owner and enterprise identity administrator one departure scenario. Trace it through login, an existing session, a direct protected API and one delayed job. Record the expected result, missing evidence and next approved check before claiming the tenant's identity lifecycle is ready. Keep real identifiers and receipts in restricted evidence storage, while retaining sanitized record structure for handover.

Download the editable offline boundary records. The ZIP includes a blank identity contract and a bounded case-count fixture. It requires no email or provider request and does not authenticate identities or prove enforcement.