Skip to content
This repository has been archived by the owner on Aug 28, 2024. It is now read-only.

Latest commit

 

History

History
75 lines (46 loc) · 4.68 KB

Using-SSO.md

File metadata and controls

75 lines (46 loc) · 4.68 KB
Raw

Using SSO

Warning: Comments here are IMHO

Start using Single Sign-On (SSO) in your AWS Accounts is hard to achieve, you must need to read a lot of documentation and of course, you need to know how to use the AWS SSO service.

For me, technical things are just things that are going to work sooner or later or as soon you understand how to use these. But non-technical things are just things that most of the time you will improve according to your time implementing technical things and this could we call "experience".

So, said that, let me help you with my "experience" using SSO.

Recommendations

Before start

  • Do a planning of how many services you will need to integrate with your Identity Provider using SSO, and how many users and Groups you will need to create.
  • Use Groups and their Members to create Users in your SSO integration, avoid the integration directly with Users.
  • Establish a Naming Convention for your SSO Groups.
  • Use prefixes for your SSO Groups name.

A little bit more

  • Google Workspace Groups and AWS Single Sign-On are free of charge, so take advantage of this
  • Filter the data in the source is always better than in the process
  • WYSIWYG is better than opaque or shadowed process, I mean, if you have 1 group called My Group with 2 members, [email protected] and [email protected] in the Google Workspace, everybody is expecting to see the same in AWS SSO side regardless of what this program does
  • A process that scales independently of the source is better than a process that needs too many changes during its escalation

Example

Given Google Workspace Groups with these conditions:

Group Name Group Email Members
AWS Administrators [email protected] [a,b,c,d]@mydomain.com
AWS DevOps [email protected] [f,g,h]@mydomain.com
AWS Developers [email protected] [k,j,z,a,g]@mydomain.com
... ... ...

your idpscim [AWS Lambda function|container image|cli] could use --gws-groups-filter 'name=AWS* email:aws-*'

This is easy and it is in compliance with the previous recommendations, but I think the most important ones are:

You can increase or decrease the number of groups and their members in Google Workspace and never need to change the parameters of the idpscim [AWS Lambda function|container image|cli]

TL;DR

NOTES:

Planning

Groups and members

Use Naming Conventions

The most important part of implementing SSO is the planning of the things you need to do before that, but for me the most important one is Groups name and Naming convention,

Why?

Because one you sync the groups and users the first time with AWS SSO and assign to them the Permission sets you should not change the Groups and Users main attributes, with in case of this program are:

Entity Main Attribute
Groups Name
Users Email

Of course, you can change the Groups and Users main attributes but after that you will lose the Permission sets assigned to them, so you should not change these.

Again, Why?

Imagine you have 40 Groups and 1,000 Users and some of these Groups has 50 Users and you have assigned some Permission sets to this Group, so if you change the Name of this Group in your Identity Provider, our case Google Workspace Directory Service, 50 users of your company will be lost their permissions to your AWS Accounts in just one moment, and this could be hard to fix is you don't have implemented any IaC practice to match the Groups and Users with the Permission sets assigned to them.

So, to avoid this scenario you should: Plan your Groups Naming Convention First

Use Name Prefixes