Joel Schuweiler AWS IAM Identity Center (Single Sign On) AWS Communtity Day Midwest 2023

1. AWS IAM Identity Center (Single Sign On)
Joel Schuweiler
aws2023@joel.codes

2. What is SSO?
● Single ID
● Authentication (not authorization)
● No re-entering credentials
● Consists of (saml)
○ Client
○ Identity Provider (Idp)
○ Service Provider (sp)
● Idp signs a token after
authentication
● Service provider verifies the token is
signed and not expired

3. Benefits of AWS SSO
● Simple staffing changes
● Simplify meeting compliance requirements
● Simple to use (no cross account role assumption)
● Integrates nicely with CLI (v2)
● No long lived API credentials

4. Benefits of AWS SSO
● Simple staffing changes
● Simplify meeting compliance requirements
● Simple to use (no cross account role assumption)
● Integrates nicely with CLI (v2)
● No long lived API credentials

5. IDP
AWS SSO or another provider?

6. What is SCIM?
(System for Cross-domain Identity Management)
Initially released in 2011 as a way to share information about
users between providers.
The single most important feature you’ll want in an idp.

7. Okta as your Idp
● Enable IAM Identity Center in AWS
● If you haven’t setup AWS Organizations it will prompt you to do so

8. Okta as your Idp
● Enable IAM Identity Center in AWS
● If you haven’t setup AWS Organizations it will prompt you to do so

9. Okta as your Idp

10. Okta as your Idp

11. Okta as your Idp

12. Okta as your Idp

13. Okta as your Idp
Your base URL must not end in /
Your base URL must not end in /
Your base URL must not end in /
Your base URL must not end in /
Your base URL must not end in /
Your base URL must not end in /
Your base URL must not end in /
Your base URL must not end in /
Your base URL must not end in /
Your base URL must not end in /
Your base URL must not end in /
Your base URL must not end in /
Your base URL must not end in /
Your base URL must not end in /
Your base URL must not end in /
Your base URL must not end in /
No, I don’t care that it’s included when you click the
copy button

14. Okta as your Idp
You included the trailing / that I told you not to <3

15. Okta as your Idp
Assign the okta app to some users

16. Okta as your Idp

17. Configure CLI

18. Renew CLI Credentials

19. What About Authorization?
Permission sets in AWS are the workhorse behind
authorization in AWS SSO
A permission set is a grouping of several key components
● Users
● Groups
● Accounts
● AWS managed policies
● Customer managed policies
● Inline policies
● Permission boundaries

20. Users vs Groups
I highly recommend assigning permissions to groups. If you
assign permissions to specific users you lose the biggest
power of AWS SSO, which is staffing changes involving zero
work from your AWS admins.
If someone needs elevated access over others it does involve
creating a new group for that user, however this is future
proofing in case anyone else needs that access level. That
change can again be made at the idp level without involving
AWS admins doing any work.

21. Accounts
When it comes to choosing which accounts to assign a
permission set to, use your best judgment. Admin level
access will be assigned all accounts. Developers may only
need access to specific accounts, and your billing group
should only need access to your main account.

22. Policies?!
Skip AWS managed policies, they’re limited largely by the fact
you can’t edit them.
With a custom permission set there’s three main sub-types
we want to discuss
1. AWS Managed Policies
2. Customer Managed Policies
3. Inline Policies
Options 1 and 2 both require the policy to exist in all child
accounts. Option 1 can’t be modified. Option 2 can be
modified but you have to make sure your custom policy exists
in all accounts. Option 3 lets you both define a custom policy
and deploy that policy in all accounts.
Option 3 may seem like the clear winner, but option 2 is a
better choice if you provide AWS as a service in an
organization.

23. Web UI

24. Wrap Up
Looks complicated
Easy to implement
Easy to use
Ask for help!
aws2023@joel.codes