OlafConijn
commented
4 years ago HI @saferrer,
the full example can be found here: https://github.com/org-formation/org-formation-cli/tree/master/examples/sso
I think SSO in this context is kinda confusing. It could mean either one of 2 things: 1) Using the AWS SSO Service to log into AWS. This is a method that relies on some manual setup in the AWS Console. I looked at automated this, but this didnt seem possible (not by supported api's).
2) Using an external SSO Provider to log in to AWS. This Is the method i/we use over at the company i work and is fully managed as code. The example also uses this approach.
Both approaches have a lot in common. they are also both build on top of the same concepts in IAM (IdentityProvider, Role).
The external SSO provider solution does mean you will have to deal with another solution provider. Think of JumpCloud, Okta, Auth0 and loads more i would assume...
The way it works:
- The SSO provider handles the login page and is connected to a directory with users.
- The users can, after logon, select the role and target account they would like to log into
- The trust between SSO Provider and AWS is made using an Identity Provider
- The permissions your user has after logging in (or: assuming a role) are declared in a regular IAM Role.
Step 1 and 2 are managed by your SSO provider. In our case a completely different department. Because we don't want to have to change the SSO Provider configuration every time we add a new account our users can use SSO to log into a special Users AWS Account. I can think of multiple reasons ('best practices') to do this so it doesn't entirely depend on having this managed by someone else. You can see this in the organization file.
if you look at the tasks file you see this is mostly regular CloudFormation and some cross account bindings.
- The SsoIdentityProvider task is used to create the Identity Provider in the Users account.
- The SsoCustomPolicies task is used to create custom managed polcies that you can refer to from within your IAM roles. This is not strictly necessary.
- The SsoNotificationTopic task is used to create an SNS topic that receive a message if specific roles are assumed. We use this to notify on high privileged roles. This is not strictly necessary.
The remaining two tasks are 2 roles: 1) SsoAuditorRole that will not notify using the SsoNotificationTopic. 2) SsoAdministratorRole that will notify using the SsoNotificationTopic.
so far so good?
The templates for the Idp, custom policies and sns topic are fairly straight forward. The template for the roles sso-generic-role.yml is somewhat more interesting... This template creates 2 roles TargetRole and SsoRole.
SsoRole will be deployed to the UsersAccount and can be assumed using the Identity Provider. TargetRole will be deployed to multiple accounts (using TargetAccountBinding). The SsoRole will allow to assume any these roles in the various accounts.
TargetRole will contain the permissions you would like to give to your users.
In the bottom of the file there is a metrics filter and alarm that can be used to send the notifications over SNS. pretty neat trick but not essential.
did that help? or only add to the confusion 😂 un saludo
Olaf
eduardomourar
Hi @OlafConijn! I just had a look at the commit associated with this issue and I am finding quite difficult to follow the example. In my company, we have a master account with AWS organisations enable and AWS SSO as well to manage users and access to the different AWS accounts. How is org-formation helping with this? One thing that we wanted to have "as code" was the permission-sets in SSO (so we don't rely on manual changes). Is this possible?
Thanks for the help!