AWSAWS Certified Generative AI Developer - Professional2026-102.3 Design and implement enterprise integration architectures
Separate workforce sign-in from service permissions
Completed by the knowledge check
Learning objective
Federate enterprise identity using IAM Identity Center or Cognito and define least-privilege service access.
Core idea
An enterprise identity proves who signed in. It does not determine everything an agent may do after sign-in. You need separate decisions for workforce access to AWS accounts, application access through an API, and workload access to downstream services.
IAM Identity Center connects workforce identities to assigned accounts and applications. Amazon Cognito user pools authenticate application users and issue tokens. IAM roles give workloads temporary AWS credentials and define service permissions. Choose each mechanism for the boundary it controls rather than copying an employee’s permissions into an agent role.
For an architect integrating enterprise identity, the outcome is a permission map: who authenticates each caller, which principal performs each AWS operation, and which policy limits that operation. End-user authorization to individual tools and documents is the next boundary; see 2.3.7.
How it works
Federate the workforce
IAM Identity Center supports external identity providers through Security Assertion Markup Language (SAML) 2.0 and System for Cross-Domain Identity Management (SCIM). SAML handles federation; it does not query the identity provider for its users and groups. Provision applicable users and groups through SCIM or manual provisioning before assigning account or application access.
Keep these two flows distinct in your design. A successful SAML sign-in does not prove that group provisioning is complete. A group synchronized through SCIM does not, by itself, receive an account assignment. Test a joiner, a group change, and a leaver against the resulting assignments rather than checking only whether the sign-in page works.
For AWS account access, define an IAM Identity Center permission set. It is a template containing IAM policies. Assign it to users or groups in target accounts; Identity Center creates corresponding IAM roles and attaches the specified policies. The permission set defines the account session’s authority, while the group assignment defines who can obtain that session.
For example, separate a production observer permission set from a deployment operator permission set. An engineer who can inspect failures should not automatically be able to change the agent’s production permissions. This is a design choice implemented through different policies and assignments, not through a naming convention on the groups.
Federate application users
A Cognito user pool can authenticate users directly or through enterprise SAML and OpenID Connect (OIDC) providers, then issue JSON web tokens (JWTs). For SAML federation, configure the provider’s metadata, the user pool’s relying-party details, and the app clients that use that provider. The SAML assertion becomes the input to the user pool’s application-token flow.
For SAML users, Cognito identifies returning users through the case-sensitive NameId claim. AWS recommends mapping NameId from an attribute whose value does not change. An email address that changes with a rename can therefore be a poor durable identity key. Treat stable identity mapping as part of the integration contract, alongside the permissions derived from enterprise groups.
A user pool and an identity pool solve different problems. The user pool issues tokens to an application or API. An identity pool exchanges a trusted identity-provider token for temporary, limited-privilege AWS credentials. Use both when a signed-in client needs direct AWS resource access. A backend-only application can authenticate with a user pool without giving its browser AWS credentials.
Do not add an identity pool merely because the backend calls AWS. The backend can use its own IAM role. Decide whether the client genuinely needs AWS credentials and, if so, limit the resulting role to the client’s intended resources and actions.
Only the identity pool path gives the client AWS credentials; a backend-only application reaches AWS through its own IAM role.
Bound service authority
AWS recommends IAM roles and temporary credentials for workloads. Define least privilege with the policy’s actions, resources, and conditions. Separate the role that deploys infrastructure from the role that runs the application, and separate a read-only retrieval component from a component allowed to mutate a business system.
For direct Bedrock inference, scope bedrock:InvokeModel and bedrock:InvokeModelWithResponseStream to a selected resource such as arn:aws:bedrock:us-east-1::foundation-model/MODEL_ID, replacing MODEL_ID with the approved model ID, rather than granting Resource: "*". AWS documents that denying bedrock:InvokeModel also blocks Converse and StartAsyncInvoke; bedrock:InvokeModel* covers the invocation action family. Check the complete policy set for broader grants. Cross-Region inference-profile grants require separate treatment; see 1.2.4.
Review both sides of a role boundary: who may assume the role and what the assumed role may do. A tightly scoped permissions policy is insufficient if an unintended caller can obtain the credentials. Conversely, a correctly restricted assumption path does not make broad downstream permissions acceptable.
IAM Access Analyzer provides policy validation and policy generation based on access activity recorded in CloudTrail. Use validation to identify policy defects, then use observed activity to refine candidate permissions. Test the generated policy before production: recorded successful activity is evidence about exercised paths, not proof that rare recovery operations or denied paths are correctly covered.
Conditions can further constrain when a grant applies. Select conditions documented for the target service and action rather than assuming every condition works everywhere. Make the desired denial observable in tests: an unauthorized resource, deployment action, or environment should fail even when the caller has valid credentials.
Key distinctions and trade-offs
Federation versus provisioning: SAML authenticates the workforce through an external provider. SCIM makes users and groups available for assignments. Both are needed in an automatically provisioned workforce integration, but neither replaces the other.
Permission set versus application entitlement: A permission set governs AWS account-role access. A product’s entitlement to a particular customer case remains a business authorization decision. Do not infer it from an employee’s ability to open the AWS console.
User token versus AWS credentials: A Cognito user-pool JWT can authenticate an API request without becoming AWS credentials. An identity pool supplies credentials when direct service access is required.
Human role versus workload role: A deployment operator can need authority that an inference caller should never receive. Separate roles make that distinction enforceable and easier to review, at the cost of maintaining explicit boundaries.
Architecture / decision scenario
An enterprise uses an external identity provider for engineers and sales staff. Engineers need access to AWS accounts; sales staff need a proposal assistant. The assistant retrieves approved material and submits draft proposals through a backend.
You connect the workforce provider to IAM Identity Center with SAML and provision engineering groups with SCIM. Account assignments use separate observer and deployment permission sets. You connect the proposal application’s Cognito user pool to the enterprise SAML provider and preserve a stable NameId mapping.
The browser sends its application token to the backend and receives no AWS credentials because direct service access is unnecessary. The backend uses a workload role limited to its required services. The deployment pipeline uses a separate role. Access Analyzer validation and representative allow-and-deny tests check those policies before release.
A sales user can now sign in without acquiring the engineer’s account role. Whether that user may retrieve a particular proposal or submit it is checked separately under 2.3.7.
Common exam traps
- Treating SAML authentication as user and group provisioning.
- Assigning an account permission set to the agent as its application authorization policy.
- Assuming a Cognito user-pool JWT is a set of AWS access credentials.
- Adding an identity pool when only the backend needs AWS access.
- Using a mutable SAML
NameIdand expecting identity continuity. - Treating an Access Analyzer generated policy as complete without testing it.
What to remember
- Use Identity Center for workforce account and application assignments.
- Separate SAML federation, SCIM provisioning, and permission-set assignment.
- Use Cognito user pools for application tokens and identity pools for direct AWS credentials.
- Give workloads temporary credentials through dedicated IAM roles.
- Validate actions, resources, conditions, and role assumption paths independently.
Knowledge check
Engineers sign in to the AWS access portal through the company identity provider over SAML. When an administrator assigns a permission set, the ml-platform group from that provider cannot be found in IAM Identity Center. What is missing?
A proposal assistant’s browser signs users in through a Cognito user pool and sends the resulting JWT to a backend, which calls Amazon Bedrock and Amazon S3. The browser never calls AWS directly. How should the backend obtain AWS credentials?
Users reach an application through a Cognito user pool federated with a SAML provider that derives NameId from the email address. After a user’s email changes, she can no longer sign in as herself. Which fix prevents this for other users?
NameId from a provider attribute whose value never changesNameId , whatever the pool’s case settings. A mutable value such as email breaks that continuity, so AWS recommends mapping NameId from an attribute that does not change. Updating attributes or matching names does not change which identity Cognito resolves.A team uses IAM Access Analyzer to generate a policy for an agent’s runtime role from 30 days of CloudTrail activity. In that period, the role’s monthly failover to a recovery queue never ran. What should happen before the policy reaches production?