CloudAcademy
  1. Home
  2. Training Library
  3. Amazon Web Services
  4. Courses
  5. Solution Architect Professional for AWS - Domain Six - Security

Designing IAM management controls

play-arrow
Start course
Overview
DifficultyAdvanced
Duration1h 15m
Students1051

Description

Course Description

In this course, you'll gain a solid understanding of the key concepts for Domain Six of the AWS Solutions Architect Professional certification: Security.

Course Objectives

By the end of this course, you'll have the tools and knowledge you need to successfully accomplish the following requirements for this domain, including:

  • Design information security management systems and compliance controls
  • Design security controls with the AWS shared responsibility model and global infrastructure
  • Design identity and access management controls
  • Design protection of Data at Rest controls
  • Design protection of Data in Flight and Network Perimeter controls

Intended Audience

This course is intended for students seeking to acquire the AWS Solutions Architect Professional certification. It is necessary to have acquired the Associate level of this certification. You should also have at least two years of real-world experience developing AWS architectures.

Prerequisites

As stated previously, you will need to have completed the AWS Solutions Architect Associate certification, and we recommend reviewing the relevant learning path in order to be well-prepared for the material in this one.

This Course Includes

  • Expert-led instruction and exploration of important concepts.
  • Complete coverage of critical Domain Six concepts for the AWS Solutions Architect - Professional certification exam.

What You Will Learn

  • Designing ISMS systems and compliance controls
  • Designing security controls
  • Designing IAM management controls
  • Identity and Access Management
  • Designing protection of Data at Rest controls
  • Designing protection of Data in Flight and Network Perimeter controls

Transcript

Okay, imagine that you are creating a mobile social media app that's gonna use Amazon S3 to store user-posted images and videos, and Amazon Dynamo DB to store user profiles and their posting history. Now we're going to need to make quite a few requests through Amazon S3 and to Amazon Dynamo DB to do this, and each one of those requests will need to be signed with an AWS access key. Now it's not advisable to store all passkeys and credentials in user requests and API requests, so a design option here is to use temporary AWS security credentials using web identity federation. You can do this by setting up a federated identity role inside of IAM. So here we are back in the IAM Console under the Roles subtab. You'll recall there are three types of roles: AWS Services Roles, which we use to grant a user access to her S3 bucket. There's Roles for Cross-Account Access, where we can have one AWS account access another. And there's Roles for Identity Provider Access. With Roles for Identity Provider Access, we can grant access to a web identity provider or create a single sign-on or grant API access to a SAML provider. What's SAML, I hear you ask? Well, SAML stands for Security Assertion Markup Language, and it is essentially an open standard data format for exchanging authentication and authorization data between an identity provider and a service provider. So for our mobile social media app, we would use web identity federation. Web identity federation means you don't need to manage user identities. So users of our app can sign in using a common identity provider, such as Amazon, Facebook, or Google, or any OpenID Connect compatible common identity provider. So how will this web federation work? When the user connects to the app, they receive an authentication token. AWS then swaps that token for temporary security credentials that map to an IAM role that we create. That IAM role will have permissions to use the resources that we want in our AWS account. So using a common identity provider helps you keep your AWS account secure because you don't have to impede and distribute long-term security credentials with your application. Now an option to help simplify all this is using Amazon Cognito. So Amazon Cognito lets you add user sign-up and authentication to your mobile and web apps. Cognito also enables you to authenticate users through social identity providers such as Facebook, Twitter, and Amazon, et cetera, or by using your identity provider of choice and providing temporary security credentials to access your app's AWS resources. Cognito exposes is control and data APIs as web services. You can also use Cognito for mobile development, so Cognito support is built into the optional AWS mobile STK, which is available for iOS, Android, Unity, and Kindle Fire. Cognito is also available in the AWS STK for JavaScript. A customer starts your app on a mobile device. The app asks the user to sign in. The app uses Login with Amazon resources to accept the user's credentials. The app uses Cognito APIs to exchange the Login with Amazon ID token for a Cognito token. The app requests temporary security credentials from AWS STS, passing the Cognito token. The temporary security credentials can be used by the app to access any AWS resources required by the app to operate. The role associated with the temporary security credentials and its assigned policies determines that can be accessed. Now another common use case for identity federation is corporate users, who may want to manage AWS resources, but who don't want to have to create a whole bunch of IAM users or add logging in to the AWS Console as an additional step every time they want to do something on AWS. So their ideal use case is to log in to their corporate directory, and then have a seamless access to the AWS Console. Now we can do this using Single Sign-On on a SAML-compliant provider like Microsoft Active Directory embedded on the corporate network. So let's just walk through how this might work. So first, the enterprise user accesses the identity broker application. Then the identity broker application authenticates the user and gets the corporate identity store. The identity broker application has permissions to access the AWS security token service, or STS, make sure you remember that, to request temporary security credentials. The enterprise users can then get a temporary URL, which gives them access to the AWS Management Console. So our other common use case for SAML login is to access APIs or resources. Now a user in your organization uses a client app to request authentication from your organization's identity provider. The identity provider authenticates the user against your organization's identity store. The IdP constructs a SAML assertion with information about the user and sends the assertion to the client app. The client app calls the AWS STS AssumeRoleWithSAML API, passing the ARN of the SAML provider, the ARN of the role to assume, and the SAML assertion form. The API response to the client app includes temporary security credentials. The client app uses the temporary security credentials to call Amazon S3 APIs. Okay, let's just review the differences between these two methods of identity federation. First, we talked about web identity federation, and that's where we're using Amazon Cognito as an identity broker, which does the majority of the federation tasks for you. Now if you don't use Amazon Cognito for web identity federation, then you need to write code that interacts with the web identity provider login, which is Amazon, Facebook, Google, or any other IODC-compatible ldP, and you need to call the AssumeRoleWithWebIdentity API to trade the authentication token you get from those ldPs with your AWS temporary security credentials. Now the other option, which is SAML 2.0 based federation, which is commonly used for allowing corporate users to log in to the AWS console using a role or for accessing AWS resources via API. Now it enables federated single sign-on, so users can log in to the AWS Management Console or call the AWS APIs without you having to create an IAM user for everyone in your company. Now SAML 2.0-based identity providers in your organization handle many of the details at run time for performing authentication and authorization checking. So the client app calls the AWS STS AssumeRoleWithSAML API, passing the ARN of the SAML provider, the ARN of the role to assume, and the SAML assertion from the ldP. And the two different APIs to remember are, for SAML 2.0, we use AssumeRoleWithSAML API, and for web identity federation, we use AssumeRoleWithWebIdentity API.

About the Author

Students59092
Courses73
Learning paths24

Andrew is an AWS certified professional who is passionate about helping others learn how to use and gain benefit from AWS technologies. Andrew has worked for AWS and for AWS technology partners Ooyala and Adobe.  His favorite Amazon leadership principle is "Customer Obsession" as everything AWS starts with the customer. Passions around work are cycling and surfing, and having a laugh about the lessons learnt trying to launch two daughters and a few start ups.