Delegating Access to your AWS Environment (SEC303) | AWS re:Invent 2013

© 2013 Amazon.com, Inc. and its affiliates. All rights reserved. May not be copied, modified, or distributed in whole or in part without the express consent of Amazon.com, Inc.

Delegating Access to your AWS Environment

Jeff Wierer, Identity and Access Management (IAM)

November 14, 2013

Goals for this talk

Understand the technology

• Sessions and the AWS

Security Token Service

(STS)

• Roles and assumed-role

sessions

• Federated sessions

• And more…

Use cases we’ll cover

• Cross-Account API Access

• AWS API Federation

• AWS Management Console

Federation

• Web Identity Federation

Let’s start with a short demo

AWS Management Console SSO Demo Setup (Sample - http://aws.amazon.com/code/4001165270590826)

Active Directory

Log into the console without a user name and

password!

Single Sign-On AWS Management Console

Demo

Wait… what just happened?

1. Logged into my Windows desktop

2. Hit an intranet website

3. Chose the “role” I wanted to play in AWS

4. Auto-magically signed in to the console

Delegation basics: Sessions & the AWS Security Token Service

Sessions 101

• Allow delegating temporary access to your AWS account

• Are generated by the AWS Security Token Service

• Include temporary security credentials that are used to

make API calls to AWS services

Requesting a Session

Session

Access Key Id

Secret Access Key

Expiration

Session Token

Start by requesting a session from AWS STS

What’s in a Session? Session

Access Key Id

Secret Access Key

Expiration

Session Token

Temporary

Security

Credentials

Multiple Ways to Get Sessions

• Self-sessions (GetSessionToken) • Federated sessions (GetFederationToken) • Assumed-role sessions

• assumeRole • assumeRoleWithWebIdentity • assumeRoleWithSAML

Session

Access Key Id

Secret Access Key

Expiration

Session Token

Sessions Expire

Expiration varies based on token type [Min/Max/Default] • Self (Account) [15 min / 60 min / 60 min] • Self (IAM User) [15 min / 36 hrs / 12 hrs] • Federated [15 min / 36 hrs / 12 hrs] • Assumed-role [15 min / 60 min / 60 min]

Use caching to improve your application performance

Session

Access Key Id

Secret Access Key

Expiration

Session Token

Role-based Delegation: Using assumed-role sessions

What’s an IAM Role?

• Entity that defines a set of permissions for making AWS

service requests

• Not associated with a specific user or group

• Roles must be “assumed” by trusted entities

Using AWS Service Roles

• Allow AWS services (e.g., Amazon EC2, AWS Data

Pipeline, AWS OpsWorks) to act on behalf of your account

• Create a role, apply an access policy, launch service with it

• Services can now access resources/API defined by the

access policy

• With used with EC2, credentials are automatically:

– Made available to the metadata cache*

– Rotated multiple times a day

– AWS SDK transparently uses these credentials within your apps!

*http://169.254.169.254/latest/meta-data/iam/security-credentials/s3access

Returns the temporary credentials for the instance

Roles for EC2 Demo Create a role and launch an EC2 instance:

Benefits of Using Roles

• Eliminates use of long-term credentials

• Automatic credential rotation

• Less coding – AWS SDK does all the work

• Simple to delegate access to AWS

Services to perform work on your behalf

Use Case: Cross-Account API Access

• Access resources across AWS accounts

• Why do you need it?

– Management visibility across all your AWS accounts

– Developer access to resources across AWS accounts

– Enables using third-party management solutions

Using IAM Roles for Cross-Account API Access

• Extended “Service Roles” concept

– Set a trust policy granting access

– Set an access policy as before

• Delegate access to other trusted entities

– AWS services (such as EC2)

– IAM users/roles within your account

– IAM users/roles under a different

account

• IAM users in one account can now

access resources in another account

{ "Statement": [ { "Effect": "Allow", "Action": “sts:AssumeRole", "Resource": "arn:aws:iam::111122223333:role/MyRole" } ] }

How to define who can assume the role using the console

Entity can assume MyRole under account 111122223333

IAM Team Account Acct ID: 111122223333

s3-role

{ "Statement": [ { "Effect": "Allow", "Action": “s3:*", "Resource": "*" } ] }

My AWS Account Acct ID: 123456789012

Authenticate with Jeff’s

access keys

Get temp security credentials

by “assuming” s3-role

Call S3 APIs using temporary

security credentials

{ "Statement": [{ "Effect": "Allow", "Action": “sts:AssumeRole", "Resource": "arn:aws:iam::111122223333:role/s3-role" } ] }

{ "Statement": [{ "Effect":"Allow", "Principal":{"AWS":"arn:aws:iam::123456789012:root"}, "Action":"sts:AssumeRole" } ] }

Cross-Account API Access – How Does It Work?

Policy assigned to s3-role defining who (trusted entities) can assume the role Policy assigned to Jeff granting him permission to assume s3-role in account B

Jeff (IAM User)

Permissions assigned to s3-role

STS

Cross-Account Demo Building a Cross-Account Amazon S3 Browser

Assumed-Role Session – Code Sample public static Credentials getAssumeRoleSession(String AccessKey, String SecretKey )

{

Credentials sessionCredentials;

AmazonSecurityTokenServiceClient client = new AmazonSecurityTokenServiceClient(

Accesskey, GetSecretkey,

new AmazonSecurityTokenServiceConfig());

// Store the attributes and request a new AssumeRole session (temporary security credentials)

AssumeRoleRequest request = new AssumeRoleRequest

{

DurationSeconds = 3600,

RoleArn = "arn:aws:iam::111122223333:role/s3-role",

RoleSessionName = "S3BucketBrowser"

};

AssumeRoleResponse startSessionResponse = client.AssumeRole(request);

if (startSessionResponse != null) // Check for valid security credentials or null

{

AssumeRoleResult startSessionResult = startSessionResponse.AssumeRoleResult;

sessionCredentials = startSessionResult.Credentials;

return sessionCredentials;

}

else

{

throw new Exception("S3 Browser :: Error in retrieving temporary security creds, received NULL");

}

}

Cross-Account API Access Delegation Benefits

• Use one set of credentials

• No more sharing long-term credentials

• Revoke access to the role anytime you want!

Federation: Access AWS with your existing corporate identity

Federation Overview

• Access AWS with your existing corporate identity

• Why use federation? – SSO to the AWS Management Console

– Build apps that transparently access AWS resources and APIs

– Eliminate “yet another password” to manage

Use Case: API Federation (Sample - http://aws.amazon.com/code/1288653099190193)

• Identity provider – Windows Active Directory

– Privileges based on AD group membership

– AD groups include policies

• Relying party is AWS API (S3*)

• Uses federated session via GetFederationToken

API

AWS API Federation Walkthrough

Customer (Identity Provider) AWS Cloud (Relying Party)

AWS Resources

User

Application

Active

Directory

Federation Proxy

4 Get Federation

Token Request

3

2

S3 Bucket

with Objects

Amazon

DynamoDB

Amazon

EC2

Request

Session 1

Receive

Session 6

5 Get Federation Token

Response

• Access Key

• Secret Key

• Session Token

APP

Federation

Proxy

• Uses a set of IAM user credentials to

make a GetFederationTokenRequest()

• IAM user permissions need to be the

union of all federated user permissions

• Proxy needs to securely store these

privileged credentials

Call AWS APIs 7

API Federation Demos Federation sample + CloudBerry AD bridge

• Assumed-role sessions can also be used for federation

• Provides a different option for storing AWS permissions

• Allows for “separation of duties” in managing AWS

permissions

• Corp admin manages groups, users, and intranet permissions

• AWS admin creates roles & maintains policies on those roles

Using IAM Roles for Federation

Use Case: Console Federation (Sample - http://aws.amazon.com/code/4001165270590826)

• Identity provider – Windows Active Directory

– Privileges based on AD group membership

– AD groups match the names of IAM roles

• Relying party is AWS Management Console

• Uses assumed-role session via AssumeRole

Basics of a Role-Based Federation Proxy

Acct ID: 111122223333

s3-role

{ "Statement": [{ "Effect": "Allow", "Action": "s3:*", "Resource": "*" } ] }

Authenticate with

access keys

Get temporary

security credentials

login using temporary security

credentials

{ "Statement": [{ "Effect": "Allow", "Action": ["iam:ListRoles","sts:AssumeRole"], "Resource": "arn:aws:iam::1111222233334444:role/*" } ] }

{"Statement": [{ "Effect": "Allow", "Principal": {"AWS": "arn:aws:iam::111122223333:root"}, "Action": "sts:AssumeRole", "Condition": { "StringEquals": {"sts:externalId": "SOME-AD-SID"}} } ] }

Trust policy set to s3role defining who can assume the role Access policy assigned to Proxy (IAM user) granting access to

ListRoles and AssumeRoles for all roles

Proxy Server

IAM User

Access policy set to s3-role

STS

AWS Management

Console

Console Federation Walkthrough (assumeRole)

Customer (IdP) AWS Cloud (Relying Party)

AWS

Management

Console

Browser

interface

Corporate

directory

Federation

proxy

1 Browse to URL

3

2

Redirect to

Console 10

Generate URL 9

4 List RolesRequest

8 Assume Role Response

Temp Credentials • Access Key

• Secret Key

• Session Token

7 AssumeRole Request

Create combo

box

6

Federation

proxy

• Uses a set of IAM user credentials to

make AssumeRoleRequest()

• IAM user permissions only need to be

able to call ListRoles & assume role

• Proxy needs to securely store these

credentials

5 List RolesResponse

SSO Federation using SAML 2.0

• STS supports Security Assertion Markup Language

• Use existing identity management software to access AWS Resources

• AWS Management Console SSO – IdP Initiated Web SSO via SAML 2.0 using the HTTP-POST binding

(Web SSO profile)

– New sign-in URL that greatly simplifies SSO

https://signin.aws.amazon.com/saml<SAML AuthN response>

• API federation using new assumeRoleWithSAML API

New

Console Federation using SAML

Enterprise (Identity Provider) AWS (Service Provider)

AWS Sign-in

Browser

interface

Corporate

identity store

Identity provider

1 User

browses to

Identity provider

2 Receives

AuthN response

5 Redirect client

AWS Management

Console

3

Post to Sign-In

Passing AuthN Response

4

SAML Federation Demos Single Sign-On to AWS Management Console

API Federation

Partner Offerings for Federation / SSO

http://www.xceedium.com/xsuite/xsuite-for-amazon-web-services

http://www.okta.com/aws/

http://www.symplified.com/solutions/single-sign-on-sso

https://www.pingidentity.com/products/pingfederate/

http://www.cloudberrylab.com/ad-bridge.aspx

Federation Benefits

• Leverage your existing corporate identities

• Use the user name/password you already know

• Enforce corporate policies/governance

• When employees leave, you only need to delete

their corporate account

Use Case: Web Identity Federation

• Want to create cloud-backed mobile apps – Leaderboards

– Image/File Sharing

– Saved state/user settings for cross-device access

• Challenges – Users may, or may not, be authenticated

– Assume users don’t have AWS accounts

– Developers need to securely delegate limited access to their AWS resources

• Enables granting access to AWS resources without embedding credentials in app

Web Identity Federation: Detailed Walkthrough

AWS Cloud

US

-EA

ST

-1

EU

-WE

ST

-1

AP

-SO

UT

HE

AS

T-1

AWS Services

Amazon

DynamoDB S3

Authenticate

User 1

6

7

IAM

EC2

Instances

Token

Verification 4

Web identity

Provider

3

5 Check

Policy

Id Token

2

Mobile App

Web Identity Federation Benefits

• Create mobile/web-based apps that easily integrate major web identity providers with AWS

• Eliminates the need to – Directly embed AWS access key IDs and secret access keys

– Utilize proxy servers to access AWS services

• Introduces assumeRoleWithWebIdentity API – Create an IAM role per application

– Use a policy that replace a variable using metadata from an id/access token

– Pass the token with the request to assume the role

• Support: Login with Amazon, Facebook, & Google

• Learn more at session SEC401

A few final words

Are There Any Limitations to using Sessions?

Federated Assumed-Role*

Security Token Service

(for assumeRole)

AWS Identity and Access Management (IAM)

AWS Elastic Beanstalk

Amazon Elastic MapReduce

All other services Accurate as of 11/14/2013. See http://aws.amazon.com/iam for most up to date list

Summary: Use Cases

• Use one set of credentials

• No more sharing long-term credentials

• Revoke access to the role anytime you want!

Cross-Account API Access

• Leverage your existing corporate identities

• Use the user name/password you already know

• Enforce corporate policies/governance

• When employees leave, you only need to delete their corporate account

AWS API / Management Console Federation

• Simplify granting access to resources for your mobile apps

• Built-in support for Login with Amazon, Facebook, & Google identities

Web Identity Federation

Additional resources

• IAM detail page: http://aws.amazon.com/iam

• AWS forum: https://forums.aws.amazon.com/forum.jspa?forumID=76

• Documentation: http://aws.amazon.com/documentation/iam/

• AWS Security Blog: http://blogs.aws.amazon.com/security

• Twitter: @AWSIdentity

All IAM related sessions at re:Invent

ID Title Time, Room

CPN205 Securing Your Amazon EC2 Environment with AWS IAM

Roles and Resource-Based Permissions

Wed 11/13 11am, Delfino 4003

SEC201 Access Control for the Cloud: AWS Identity and Access

Management (IAM)

Wed 11/13 1.30pm, Marcello 4406

SEC301 TOP 10 IAM Best Practices Wed 11/13 3pm, Marcello 4503

SEC302 Mastering Access Control Policies Wed 11/13 4.15pm, Venetian A

SEC303 Delegating Access to Your AWS Environment Thu 11/14 11am, Venetian A

Come talk security with AWS Thu 11/14 4pm, Toscana 3605

Please give us your feedback on this

presentation

As a thank you, we will select prize

winners daily for completed surveys!

SEC303