{"id":497,"date":"2017-04-07T14:28:30","date_gmt":"2017-04-07T12:28:30","guid":{"rendered":"https:\/\/blog.besharp.it\/497\/"},"modified":"2021-03-29T16:24:41","modified_gmt":"2021-03-29T14:24:41","slug":"single-sign-on-with-g-suite-on-the-amazon-web-services-console","status":"publish","type":"post","link":"https:\/\/blog.besharp.it\/single-sign-on-with-g-suite-on-the-amazon-web-services-console\/","title":{"rendered":"Single-sign-on with G Suite on the Amazon Web Services console"},"content":{"rendered":"
Which AWS console user has never run into the age-old problem of\u00a0managing multiple users on multiple accounts<\/strong>, having to create different IAM users\u200a\u2014\u200awith complex passwords for each of them\u200a\u2014\u200aon top of the highly fundamental (but, let\u2019s be honest, decidedly inconvenient)\u00a0two-factor-authentication<\/strong>?<\/p>\n And on the topic of two-factor-authentication, assuming that you don\u2019t want to use a dedicated hardware token for every single IAM user, the choice is almost totally limited to\u00a0Google Authenticator<\/strong><\/a>, with codes and QR codes that proliferate like mushrooms and that become difficult to safeguard from adverse smartphone-related events (theft, loss, breakage, backup, changing device\u2026).<\/p>\n AWS actually offers\u00a0a cross-account access service<\/strong><\/a>\u00a0for its management console, which, however, has several limitations, including:<\/p>\n The most appropriate response to the need to centrally manage users and login details, for AWS as well as for the vast majority of applications that need multi-user authentication, is called\u00a0Single-sign-on<\/strong>\u00a0(SSO).<\/p>\n Typically, the SSO mechanism is based on an\u00a0Identity Provider<\/strong><\/a>\u00a0(a centralised repository of all corporate identities with their attributes\u200a\u2014\u200ausername, password, groups, roles, etc\u2026) and a series of Service Providers (applications where users can log in with their corporate identities) that are federated to the Identity Provider with strong\u00a0trust<\/em>\u00a0relationships that are typically based on shared keys, certificates or tokens. This allows users to use a single user profile (and therefore a single password and a single TFA), which is centrally managed, to log into all the applications that have been enabled for them.<\/p>\n Although Service Providers can be the most disparate of applications (Web, desktop, mobile, remote access, CLI, API etc\u2026), Identity Providers are almost always\u00a0LDAP<\/strong><\/a>\u00a0or\u00a0<\/strong>Microsoft Active Directory servers<\/strong><\/a>. Specifically, MS AD is the de facto standard in most highly-structured companies for corporate identity management, and it is therefore supported by default by all applications that require the option of using SSO.<\/p>\n However, it is not that common to find an MS AD infrastructure implemented (but this also applies partly to LDAP), especially in smaller, younger or more agile businesses, for reasons ranging from cost to complexity of management (especially if they are in need of a highly reliably provided AD service), without ignoring the fact that MS AD is typical of Microsoft-centric companies (almost all the large legacy companies) and is therefore less prevalent where the client base is more varied (Windows+Mac+Linux\u2026).<\/p>\n A very widespread trend in businesses is to use the company Google Apps account (recently renamed to\u00a0G Suite<\/a>)\u200a\u2014\u200aa widely-used service mostly used for its email and collaboration functions\u200a\u2014\u200aas an Identity Provider. By doing so, you can use SSO on a multitude of applications that already natively support the \u201clogin with Google\u201d function, but also on those (as is the case with the AWS console) that support the\u00a0SAML standard<\/a>, which G Suite has been providing the service of Identity Provider for for around a year.<\/p>\n So let\u2019s see how to\u00a0configure our AWS and G Suite accounts to make Single-Sign-On work with SAML.<\/strong><\/p>\n First of all, in the G Suite administration page, we have to add custom attributes to our users, through which our Identity Provider (Google) will communicate the identity of the user logged in, as well as additional information that we will explain later, to the Service Provider (AWS).<\/p>\n Now create a custom attribute class and call it \u201cAWS SAML\u201d and then create the attributes \u201cIAM Role\u201d and \u201cSessionDuration\u201d. It is important for both attributes to be private (that is, not viewable by all users in your organisation) and for the attribute \u201cIAM Role\u201d to support multiple values.<\/p>\n\n
the maximum limit of 5 manageable AWS accounts;<\/del> [UPDATE: this limit has been removed :)]<\/strong><\/li>\n<\/div>\n<\/div>\n<\/figure>\n
<\/div>\n<\/div>\n<\/figure>\n