CloudAcademy
  1. Home
  2. Training Library
  3. Amazon Web Services
  4. Courses
  5. Certified Developer for AWS- Deployment and Security

Identity Federation

play-arrow
Start course
Overview
DifficultyIntermediate
Duration1h 59m
Students1335

Description

In this course we learn to

Recognize and implement secure procedures for optimum cloud deployment and maintenance.
Demonstrate ability to implement the right architecture for development, testing, and staging environments. 

Shared Security model
Compliance and best practices
Identity and Access Management (IAM)
Protecting data at Rest / In Transit
Identity Federation
Threat Mitigation
Amazon CloudFront Security

Deployment Services

Demonstrate ability to implement the right architecture for development, testing, and staging environments.
Understand the core AWS services, uses, and basic architecture best practices
Amazon CodeDeploy
Amazon CodePipeLine
Amazon CodeCommit

If you have thoughts or suggestions for this course, please contact Cloud Academy at support@cloudacademy.com.

Transcript

Imagine that you are creating a mobile social media app that's going to use Amazon S3 to store user-posted images and videos and Amazon DynamoDB to store user profiles and their posting history. Now we're going to need to make quite a few requests to Amazon S3 and to Amazon DynamoDB to do this and each one of those requests will need to be signed with AWS Access Key. Now, it's not advisable to store or pass keys 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.

Here we are back in the IAM Console, under the Roles sub-tab. You'll recall there are three types of Roles. AWS Services Roles, which we use to grant our 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 Mark Up Language. And it is essentially an open-standed data format for exchanging authentication and authorization data between an identity provider and a service provider.

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 other open ID 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 embed and distribute long-term security credentials with your application.

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 its 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 SDK, which is available for iOS, Android, Unity and Kindle Fire. Cognito is also available in the AWS SDK for JavaScript.

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 into the AWS console as an additional step every time they want to do something on AWS. So their ideal use case is to log into 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 their corporate network.

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

About the Author

Students50823
Courses76
Learning paths28

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.