Designing an Efficient SSO Setup for Internal Applications in AWS

Answers - B and C.

Option A is incorrect because already a role-based setup is in place.

Option B is CORRECT because (a) it creates a custom identity broker application for authenticating the users using their existing credentials, (b) it gets temporary access credentials using STS, and (3) it uses federated access for accessing the AWS resources.

Option C is CORRECT because (a) it creates a custom identity broker application for authenticating the users using their existing credentials, and (b) it uses AssumeRole API for accessing the resources using a temporary role.

Option D is INCORRECT as the DecodeAuthorizationMessage API call only decodes additional information about the authorization status of a request from an encoded message returned in response to an AWS request.

More information on AssumeRole and GetFederatedToken:

Assume Role - Returns a set of temporary security credentials (consisting of an access key ID, a secret access key, and a security token) that you can use to access AWS resources that you might not normally have access to.

Typically, you use AssumeRole for cross-account access or federation.

For more information, please visit the below URL-

http://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html

GetFederationToken - Returns a set of temporary security credentials (consisting of an access key ID, a secret access key, and a security token) for a federated user.

A typical use is in a proxy application that gets temporary security credentials on behalf of distributed applications inside a corporate network.

For more information, please visit the below URL-

http://docs.aws.amazon.com/STS/latest/APIReference/API_GetFederationToken.html

The most appropriate option for designing the SSO setup for this scenario would be Option C: Create a custom identity broker application that authenticates employees using the existing system and uses the AssumeRole API call to gain temporary, role-based access to AWS.

Option A, creating an IAM user to share based on employee roles, is not recommended because IAM users require a direct association with AWS accounts and cannot be used to authenticate external users.

Option B, creating a custom identity broker application that uses the GetFederationToken API call, may work but is not the best option as it requires more complex code and additional permissions that may be difficult to manage.

Option D, configuring an AD server and using the DecodeAuthorizationMessage API call, is also not the best option as it involves more setup and configuration, and can be more difficult to maintain.

Option C involves creating a custom identity broker application that authenticates employees using the company's existing authentication system (SAML2.0) and then uses the AssumeRole API call to gain temporary, role-based access to AWS resources. This approach allows for more fine-grained control over access permissions and is easier to maintain and manage.

The custom identity broker application can be designed to integrate with the company's existing SAML2.0-based identity authentication system. When an employee logs in, the custom identity broker application can authenticate the user and use the AssumeRole API call to request temporary AWS credentials that are assigned a role based on the user's SAML2.0 attributes. These temporary credentials can then be used to access AWS resources for a specified duration, after which they expire.

By using the AssumeRole API call, the custom identity broker application can provide users with temporary credentials that are scoped down to a specific set of permissions or resources, reducing the risk of unauthorized access to AWS resources.

Overall, Option C provides a secure, scalable, and manageable solution that meets the requirements of the scenario.