View a markdown version of this page

Authentication and authorization - AWS Prescriptive Guidance

Authentication and authorization

AWS Identity and Access Management (IAM) provides fine-grained access control across the entire AWS platform. You can use IAM to specify who can access which services and resources, and under which conditions. IAM policies let you manage permissions to your workforce and systems to ensure least privilege permissions. Least privilege is an AWS Well-Architected best practice for building securely in the cloud.

The following sections explain how you can use IAM and Amazon Cognito in your authentication, authorization, and user management tasks.

Using IAM in development environments

To streamline development and testing activities, users can get their own credentials in the form of an access key ID and secret access key for sandbox and development environments. You can store your access key ID and secret access key in the credentials file in your user profile. Your .NET Framework applications use this profile to locally develop and test the applications that access AWS services.

Best practices for managing user credentials 

  • Do not share the credentials with anyone.

  • Assign the minimum required permissions (least privilege) to developers.

  • Use this approach only for development purposes in lower environments such as sandbox or development.

  • Rotate keys periodically.         

  • Audit credentials frequently.  

  • Enable multi-factor authentication (MFA).

Prerequisites for using IAM in your development environment

Configuring credentials by using the AWS CLI

You can use the AWS CLI to configure your profile with your AWS access key ID and secret access key credentials. At the command prompt, run the following commands. Replace the sample values with your personal details.

aws configure AWS Access Key ID [None]: xxxxxxxxxxxxxxxx AWS Secret Access Key [None]: xxxxxxxxxxxxxxxxxxxxxxxxx Default region name [None]: <specify region name> Default output format [None]: json

Accessing development environments

The best practice for accessing development environments is to manage users in a centralized account and enable MFA. These users can assume IAM roles to access other AWS accounts. When you run .NET Framework applications by using a profile that specifies an IAM role, Visual Studio uses the source profile's credentials to call AWS Security Token Service (AWS STS) and request temporary credentials for the specified role. The user in the source profile must have permissions to call sts:assume-role for the role in the specified profile. The role must have a trust relationship that allows the user in the source profile to use the role. The process of retrieving and then using temporary credentials for a role is often called assuming the role. For information about using an IAM role to access other AWS development or sandbox accounts, see the AWS CLI documentation. You can then use the AWS development or sandbox accounts to develop and test .NET Framework solutions from Visual Studio or by using .NET command-line interface (CLI) commands.

Using IAM in production environments

For production environments it is best practice to use IAM roles instead of access keys. The IAM role generates and rotates the temporary keys. Applications that run on AWS are authenticated and authorized to use AWS resources securely and seamlessly.

Example use case

Consider a scenario where your application calls an AWS Lambda function and that function accesses the Amazon DynamoDB table to perform create, read, update, delete (CRUD) operations and to add logs to Amazon CloudWatch. The following diagram illustrates this example. The Lambda function requires permissions to access the DynamoDB table and CloudWatch Logs. To grant these permissions, add an execution role when you create the Lambda function.

 

Resources

Using Amazon Cognito

Amazon Cognito provides authentication, authorization, and user management for your web and mobile apps. Users sign in directly with sign-in credentials or through a third party, such as Facebook, Amazon, Google, or Apple.

The two main components of Amazon Cognito are user pools and identity pools. User pools are user directories that provide sign-up and sign-in options for your application users. Identity pools enable you to grant your users access to other AWS services. You can use identity pools and user pools separately or together. For more information, see Common Amazon Cognito scenarios in the Amazon Cognito documentation.

Example use case

The following diagram shows an example of implementing Amazon Cognito with a serverless ASP.NET Core web app, Amazon API Gateway, and AWS Lambda. This architecture is implemented by using the following configuration:          

  • An Amazon Cognito user pool is configured to authenticate, store, and manage users.

  • An ASP.NET Core web app is hosted in Lambda and fronted by API Gateway.

  • A client-side script authenticates the users against Amazon Cognito. The script receives a JSON Web Token (JWT) from Amazon Cognito (1) and passes it as an HTTP Authorization header to the web API methods for authorization. The JWT is then passed to API Gateway for authorization (2).

 

 

Resources