Configuring Identity Services for AWS Management Console Access

Answer: D.

Option A is incorrect because an AWS Managed Microsoft AD is an independent directory service hosted in AWS.

However, as per the expectation, we need to use the local IdP service for authentication.

Option B is incorrect because using OIDC is useful when a mobile app or web application requires access to AWS resources.

However, it is not used for AWS Management Console access.

Option C is incorrect because AWS Simple AD is a directory service provided by AWS.

User accounts in Simple AD can also be used to access AWS Enterprise IT applications such as Amazon WorkSpaces, Amazon WorkDocs, and Amazon WorkMail, and manage AWS resources via the AWS Management Console.

However, as per the expectation, we need to use the local IdP service for authentication.

Option D is CORRECT because AWS supports the identity federation with SAML.

You use an IAM identity provider when you want to establish trust between a SAML-compatible IdP such as Shibboleth or Active Directory Federation Services and AWS so that users in your organization can access AWS resources.

Reference:

https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_create_saml.html

Sure, I can provide a detailed explanation of the answers to the question you've asked.

The question is asking about how to configure identity services for an organization that wants to migrate its on-premises infrastructure and applications to AWS while continuing to use its local identity provider for authentication. The developers and QA engineers need to log in to the AWS Management Console without having to remember another password for AWS access.

Let's discuss each answer option in detail to understand the solution approach:

A. Create an AWS Managed Microsoft AD and configure a trust relationship between AWS Managed Microsoft AD and the existing local IdP. Configure users and groups with access to resources in AWS, using single sign-on (SSO).

This option suggests creating an AWS Managed Microsoft AD and establishing a trust relationship between the existing local identity provider and the AWS Managed Microsoft AD. This approach will enable users to access AWS resources through single sign-on (SSO) by configuring users and groups with access to resources in AWS.

In this approach, the AWS Managed Microsoft AD acts as a federation gateway, and the local identity provider acts as the identity source. Users can log in to the AWS Management Console using their existing credentials without requiring additional passwords.

B. Establish the trust between a local OIDC-compatible IdP and your AWS account. Users sign in using the local OIDC IdP, get an authentication token, and then log in to the AWS Management Console with the token.

This option proposes establishing trust between a local OpenID Connect (OIDC)-compatible identity provider and AWS. When a user signs in to the local OIDC IdP, they receive an authentication token, which they can then use to log in to the AWS Management Console.

This approach provides users with a single sign-on experience without requiring additional passwords.

C. Create a Simple AD in AWS, which is powered by a Samba 4 Active Directory Compatible Server. Enable federated access to the AWS Management Console via the AWS single sign-on endpoint.

This option suggests creating a Simple AD in AWS, which is powered by a Samba 4 Active Directory Compatible Server. The Simple AD will act as the federation gateway, and users can access AWS resources through single sign-on (SSO).

To enable federated access to the AWS Management Console, this approach utilizes the AWS single sign-on endpoint. Users can log in to the AWS Management Console using their existing credentials, without requiring additional passwords.

D. Create an IAM SAML 2.0 identity provider and create an AWS role that permits your organization's IdP to request temporary security credentials for access to AWS and configure the relying party trust between your IdP and AWS.

This option proposes creating an IAM Security Assertion Markup Language (SAML) 2.0 identity provider and configuring a relying party trust between the organization's identity provider and AWS.

Using this approach, the organization's identity provider can request temporary security credentials for accessing AWS resources. Users can log in to the AWS Management Console using their existing credentials without requiring additional passwords.

So, in conclusion, each answer option proposes a different solution approach for configuring identity services in AWS for an organization that wants to migrate its on-premises infrastructure and applications while continuing to use its local identity provider for authentication. The best option would depend on the organization's specific requirements, but all options provide a single sign-on experience for users without requiring additional passwords.