# Authentication and authorization
<a name="authentication"></a>

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](https://docs.aws.amazon.com/wellarchitected/latest/framework/sec-design.html) is an AWS Well-Architected Framework 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.

**Topics**
+ [Using IAM in development environments](iam-development.md)
+ [Using IAM in production environments](iam-production.md)
+ [Using Amazon Cognito](cognito.md)

# Using IAM in development environments
<a name="iam-development"></a>

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
<a name="iam-development-bp"></a>
+ 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
<a name="iam-development-prereq"></a>
+ An active AWS account
+ [Microsoft Visual Studio](https://visualstudio.microsoft.com/downloads/), installed
+ AWS Command Line Interface (AWS CLI) version 2, installed and configured to access your AWS account (see [instructions](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html))
+ AWS Toolkit for Visual Studio, configured (see [instructions](https://docs.aws.amazon.com/toolkit-for-visual-studio/latest/user-guide/setup.html))

## Configuring credentials by using the AWS CLI
<a name="iam-development-cred"></a>

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
<a name="iam-development-access"></a>

The best practice for accessing development environments is to manage users in a centralized account and enable MFA. 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](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-role.html). 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
<a name="iam-production"></a>

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
<a name="iam-production-example"></a>

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.

![\[Using IAM roles for authentication in .NET Framework application development\]](http://docs.aws.amazon.com/prescriptive-guidance/latest/modernization-net-applications-security/images/net-security.png)


## Resources
<a name="iam-production-resources"></a>
+ [How to create an IAM policy to grant AWS Lambda access to an Amazon DynamoDB table](https://aws.amazon.com/blogs/security/how-to-create-an-aws-iam-policy-to-grant-aws-lambda-access-to-an-amazon-dynamodb-table/) (AWS Security blog)
+ [Security best practices in IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html) (IAM documentation)
+ [AWS Lambda execution role](https://docs.aws.amazon.com/lambda/latest/dg/lambda-intro-execution-role.html) (Lambda documentation)

# Using Amazon Cognito
<a name="cognito"></a>

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](https://docs.aws.amazon.com/cognito/latest/developerguide/cognito-scenarios.html) in the Amazon Cognito documentation.

## Example use case
<a name="cognito-ex"></a>

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).

![\[Using Amazon Cognito and API Gateway for secure .NET Framework application development\]](http://docs.aws.amazon.com/prescriptive-guidance/latest/modernization-net-applications-security/images/net-security-cognito.png)


## Resources
<a name="cognito-resources"></a>
+ [Common Amazon Cognito scenarios](https://docs.aws.amazon.com/cognito/latest/developerguide/cognito-scenarios.html) (Amazon Cognito documentation)
+ [Authenticating Serverless ASP.NET Core Web APP Using Amazon Cognito](https://www.youtube.com/watch?v=M6qTrI7kmZk) (video)