© 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