When working in a multi-account AWS environment, or when external or internal security and compliance requirements necessitate the constraining of user identity information to a geography where there isn’t an AWS Region or the use of MFA tokens based on standards other than RFC6238, it is recommended to federate user identity details to a customer-maintained identity provider (IdP). We demonstrate the integration of a customer-based IdP with AWS IAM using a SAML trust relationship at Group level, and discuss multi-account access stretegy and how federation fits into it.

1. IAM Federation
Dave Walker
Specialist Solutions Architect,
Security and Compliance

2. What to expect from the session
• What?
• Why?
• How?
• Demo!

3. What?
• Use your own Identity Provider ("IdP") to authenticate your users
and to AWS

4. Why?

5. Federation rationale
Before:
After:
Result:

6. Federation rationale
Before:
After:
Result:
Unique credentials
Users

7. Federation rationale
Before:
After:
Result:
Unique credentials
Single sign-on
Users

8. Federation rationale
Before:
After:
Result:
Unique credentials
Single sign-on
Long-lived keys
Users Security

9. Federation rationale
Before:
After:
Result:
Unique credentials
Single sign-on
Long-lived keys
Short-term tokens
Users Security

10. Federation rationale
Before:
After:
Result:
Unique credentials
Single sign-on
Long-lived keys
Short-term tokens
One-off
Users Security Compliance

11. Federation rationale
Before:
After:
Result:
Unique credentials
Single sign-on
Long-lived keys
Short-term tokens
One-off
Naturally aligned
Users Security Compliance

12. Federation rationale
Before:
After:
Result:
Unique credentials
Single sign-on
Long-lived keys
Short-term tokens
One-off
Naturally aligned
Users Security Compliance

13. Further Reasons to use IAM Federation...
• The only sure-fire way of keeping movers / leavers / joiners in
sync between your on-premises directory services and AWS
• A means of integrating authentication policies and
mechanisms that IAM doesn't currently support:
• MFA tokens other than RFC6238 TOTP
• multi-person / quorum rules (but see Organizations)
• "n strikes and you're locked out" (but please don't use this one)
• Remove PII from IAM
• useful in the face of some data sovereignty considerations
• see eg https://aws.amazon.com/blogs/aws/in-country-storage-of-
personal-data/

14. How?

15. How?
• SAML 2.0 Trust Relationship, IdP to IAM
• Custom Identity Brokerage:
• For when you need full policy configurability, or to go beyond AWS
• Commercial offerings in AWS Marketplace
• Okta
• Auth0
• IDentia
• Others
• PingFederate
• ForgeRock
• SAML Gateways:
• Open-source
• Shibboleth
• Commercial
• ADFS etc

16. • Pro: Granular and contextual policies
• Pro: Complete control
• Con: Development effort
• Con: Complex evaluations
• Choose a custom identity broker if
you prefer to increase federation
involvement for the ultimate control.
SAML
• Pro: Low barrier to entry
• Pro: Federation beyond AWS
• Con: Number of roles, groups
• Con: Add’l automation to scale
• Choose SAML if you want a
balanced federation approach.
Comparison: SAML vs. Custom identity broker
Custom identity broker

17. SAML to AWS Management Console
console
federation IDP
2)SAMLSSO
Assertion
X.509 certificate
Bound to PrincipalArn
federation SP
Attribute Description
SAML subject name Required for SAML
RoleArn role for user entitlements
PrincipalArn role of IDP in AWS
RoleSessionName Enables user-specific
auditing and access policies
Directory

18. SAML to AWS (API)
federation IDP
1) authentication
Assertion
2) authn, attributes
3) assertion
federation SP
STS
RoleArn
PrincipalArn
ST credentials
ST credentials
Directory

19. Making your Mappings
• LDAP Group <-> IAM Group
• (Can do LDAP Group <-> IAM Role, which is easier, but doesn't scale so
well with many accounts)
• Removes PII as ou=,dc= in LDAP DN contains none
• Permissions:
• give Users none
• give Groups permission to assume a Role
• Roles get all the "useful" permissions
• Group Names:
• Recommended schema: AWS-<account ID>-<Role name>
• eg cn=AWS-012345678901-Audit,ou=groups,dc=example,dc=com
• (Usernames stay as eg uid=alice,ou=accounts,dc=example,dc=com)

20. AWS Account: Resources
AWS IAM
role
AWS Account: Log aggregation and anonymisation
On-premise
AWS
Lambda
role
bucketbucket
AWS Account:
Anonymised
Logs
AWS
Lambda
role
bucket
AWS Account: Bill
Aggregation and
Anonymisation
bucket
AWS Account:
Anonymised
Bills
AWS IAM
IdP server
AWS Account:
Audit
(Internal)
AWS IAM
AWS Account: Resources
AWS Account:
Audit
(External)
AWS Account:
Regulator
AWS IAM AWSKMS
AWS
Organizations
LDAP
AWS Account: Shared
Svcs
AWS
CloudHSM
bucket
AWS Account: Backups
Amazon
Athena
Amazon
QuickSight
Amazon
Redshift*
AWS
Service Catalog
bucket
AWS Account:
Forensic Repo
AWS Account:
Forensic
Working
bucket
AWS Account:
Working Repo
Read-only, read-all flow
API and IAM call flow
Logging traffic flow
Billing traffic flow
Cryptographic key use
Organization member
account
Organization non-member
account
Backup traffic flow
AWS Account: IAM
Federation
API Endpoints

21. Handling MFA
• IAM doesn't know your IdP's MFA policy
• so has no intrinsic knowledge of whether your users have employed an MFA
token or not
• transitive trust
• Configure your IdP so MFA users are mapped into Groups
different to MFA non-users
• Or require that all users use MFA, all the time

22. Demo!

23. http://federationworkshopreinvent2016.s3-website-us-east-
1.amazonaws.com/labguides/shibbolethhour1/labguide-shibbolethhour1.html

24. Dave Walker
davwal@amazon.com
Your feedback
is important to us!