A company is refactoring applications to use AWS. The company identifies an internal web application that needs to make Amazon S3 API calls in a specific AWS account.
The company wants to use its existing identity provider (IdP) auth.company.com for authentication. The IdP supports only OpenID Connect (OIDC). A DevOps engineer needs to secure the web application's access to the AWS account.
Which combination of steps will meet these requirements? (Choose three.)
To secure the web application's access to the AWS account using OpenID Connect (OIDC), the following steps are necessary: First, create an IAM IdP using the provider URL, audience, and signature from the existing IdP to establish trust between AWS and the IdP. Next, create an IAM role with a policy that allows the necessary S3 actions and configure the role's trust policy to allow the OIDC IdP to assume the role, using the appropriate audience context key, which in this case is auth.company.com:aud. Finally, configure the web application to use the AssumeRoleWithWebIdentity API operation to retrieve temporary credentials and use those credentials to make the S3 API calls. This process leverages the existing IdP for authentication and ensures secure access to AWS resources through temporary credentials.
https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-idp_oidc.html
BDE: A: we need to create an IDP. We dont need a AWS Single Sign-On B: correct C: we need to authen. sts.amazon.com:aud does not for authen D: auth.company.com:aud is for authen E: This used for authen AssumeRoleWithWebIdentity F: This is not used for authen
BDE is my answer
"Use OpenID Connect (OIDC) federated identity providers instead of creating" IAM users." "With an" IdP "you can manage" "user identities outside of AWS and give these external user identities permissions to access AWS resources in your account." B: (YES) "IAM OIDC identity Providers" "This is useful when creating a mobile app or web application that requires access to AWS resources, but you don't want to create custom sign-in code or manage your own user identities." D: (YES) "For OIDC providers, use the fully qualified URL of the OIDC IdP with the aud context key" e.g.: "Condition": {"StringEquals": {"server.example.com:aud": "appid_from_oidc_idp"}}" E: (YES) "AssumeRoleWithWebIdentity" "Federation through a web-based" IDP "returns a set of temporary security credentials for federated users" "authenticated" "with a public identity provider." "This operation is useful for" "client-based web applications that require access to AWS."
BDE for me
DE is correct not sure between A & B A. Configure AWS IAM Identity Center (AWS Single Sign-On). Configure an IdP. Upload the IdP metadata from the existing IdP. Pros: Integrates with AWS SSO and allows for IdP metadata upload. Cons: AWS SSO is generally used for managing multiple AWS accounts and SSO for multiple AWS services, might be overkill for a single account and application. B. Create an IAM IdP by using the provider URL, audience, and signature from the existing IP. Pros: Creates a custom IAM IdP using the existing IdP's details. Cons: Manual configuration of IAM IdP might be error-prone and not the best practice for OIDC integration.
C & D: Creating an IAM role with specific S3 permissions and configuring the trust policy based on the appropriate audience (sts.amazon.com:aud or auth.company.com:aud) allows secure role assumption by the OIDC IdP on behalf of authenticated users. E: Using AssumeRoleWithWebIdentity fetches temporary credentials with restricted privileges, enhancing security compared to long-lived credentials.
Options A, B, and F are not suitable for this scenario: A: AWS SSO is currently not available for public AWS accounts and wouldn't address the specific OIDC integration requirement. B: While creating an IAM IdP is possible, it's generally less secure than leveraging the existing, trusted IdP with OIDC support. F: GetFederationToken is often used with SAML-based federation and wouldn't work directly with OIDC.
https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-idp_oidc.html