{"id":149,"date":"2017-04-07T14:28:30","date_gmt":"2017-04-07T12:28:30","guid":{"rendered":"https:\/\/blog.besharp.it\/?p=149"},"modified":"2022-07-21T15:12:37","modified_gmt":"2022-07-21T13:12:37","slug":"single-sign-on-con-g-suite-sulla-console-di-amazon-web-services","status":"publish","type":"post","link":"https:\/\/blog.besharp.it\/it\/single-sign-on-con-g-suite-sulla-console-di-amazon-web-services\/","title":{"rendered":"Single-sign-on con G Suite sulla console di Amazon Web Services."},"content":{"rendered":"
Chi, tra gli utilizzatori della console di AWS non si \u00e8 mai scontrato con l\u2019annoso problema di gestire molteplici utenti su altrettanti account<\/strong>, dovendo creare diversi IAM user e, per ognuno di essi, password complesse, oltre alla quanto mai fondamentale (ma decisamente scomoda, diciamoci la verit\u00e0) two-factor-authentication<\/strong>?<\/p>\n Proprio riguardo a quest\u2019ultima, dando per scontato che non si voglia utilizzare un token hardware dedicato per ogni singolo IAM user, la scelta ricade quasi obbligatoriamente sul Google Authenticator<\/strong><\/a>, con codici e QR code che proliferano come funghi e che diventa complicato salvaguardare da eventi nefasti legati allo smartphone (furti, smarrimenti, rotture, backup, cambio device\u2026)<\/p>\n AWS in realt\u00e0 offrirebbe un servizio di cross-account access<\/strong><\/a> per la sua management console, che ha per\u00f2 diversi limiti, tra i quali:<\/p>\n La risposta pi\u00f9 consona alla necessit\u00e0 di gestire centralmente utenti e accessi, per AWS cos\u00ec come per la stragrande maggioranza delle applicazioni che necessitano autenticazione multi-utente, si chiama \u00a0Single-sign-on<\/strong>\u00a0(SSO).<\/p>\n Tipicamente, il meccanismo del SSO si basa su un\u00a0Identity Provider<\/strong><\/a> (un repository centralizzato di tutte le identit\u00e0 aziendali con relativi attributi \u2013 username, password, gruppi, ruoli ecc\u2026) e una serie di Service Provider<\/strong> (le applicazioni dove gli utenti si possono loggare con le loro identit\u00e0 aziendali) che vengono federati all’Identity Provider con relazioni di trust<\/em> forte<\/strong>, basate tipicamente sulla condivisione di chiavi, certificati o token<\/strong>. In questo modo gli utenti possono utilizzare un\u2019unica utenza (e quindi una sola password e una singola TFA), gestita in maniera centralizzata, per loggarsi in tutte le applicazioni per le quali sono stati abilitati.<\/p>\n Se i Service Provider possono essere le applicazioni pi\u00f9 disparate (Web, desktop, mobile, accesso remoto, CLI, API ecc\u2026.), gli Identity Provider sono quasi sempre dei server LDAP<\/a> o Microsoft Active Directory<\/a><\/strong>. In particolare MS AD \u00e8 lo standard de facto nella maggior parte delle aziende pi\u00f9 strutturate per la gestione delle identit\u00e0 aziendali, ed \u00e8 infatti supportato di default da tutte le applicazioni che prevedano la possibilit\u00e0 di fare SSO.<\/p>\n Tuttavia non \u00e8 cos\u00ec comune trovare implementata un\u2019infrastruttura MS AD<\/strong> (ma il discorso vale in parte anche per LDAP), in particolar modo nelle realt\u00e0 pi\u00f9 piccole o giovani e agili, per ragioni che spaziano dai costi alla complessit\u00e0 di gestione<\/strong> (specie se si necessita del servizio di AD erogato in alta affidabilit\u00e0), senza trascurare il fatto che MS AD \u00e8 tipico di realt\u00e0 Microsoft-centriche (quasi tutte le grandi aziende legacy) ed \u00e8 quindi meno diffuso dove il parco client \u00e8 pi\u00f9 eterogeneo (Windows+Mac+Linux\u2026).<\/p>\n Una tendenza molto diffusa in realt\u00e0 \u00e8 quella di utilizzare come Identity Provider l\u2019account Google Apps (da poco rinominato in G Suite<\/a>) aziendale, servizio ampiamente diffuso e largamente utilizzato per le funzionalit\u00e0 di posta elettronica e colaboration. In questo modo si pu\u00f2 fare SSO sulle numerosissime applicazioni che gi\u00e0 nativamente supportano la funzione \u201clogin with Google\u201d<\/strong>, ma anche su quelle (come \u00e8 il caso della console di AWS) che supportano lo standard SAML<\/strong><\/a>, standard per il quale da circa un anno G Suite eroga il servizio di Identity Provider.<\/p>\n Vediamo quindi come configurare i nostri account AWS e G Suite per far funzionare il Single-Sign-On con SAML<\/strong>.<\/p>\n Innanzi tutto, nella pagina di amministrazione di G Suite, dobbiamo aggiungere degli attributi custom ai nostri utenti, tramite i quali il nostro Identity Provider (Google) comunicher\u00e0 al Service Provider (AWS) oltre all\u2019identit\u00e0 dell\u2019utente loggato, informazioni aggiuntive che spiegheremo in seguito.<\/p>\n Creiamo una categoria di attributi custom e chiamiamola \u201cAWS SAML\u201d e creiamo gli attributi \u201cIAM Role\u201d e \u201cSessionDuration\u201d. E\u2019 importante che entrambi gli attributi siano privati (ovvero non visualizzabili da tutti gli utenti della vostra organizzazione) e che l\u2019attributo \u201cIAM Role\u201d supporti valori multipli.<\/p>\n Fatto questo andiamo nella sezione \u201cApps\u201d e aggiungiamo una nuova applicazione SAML, partendo dal template pre-configurato per AWS.<\/p>\n Scarichiamo (opzione 2) gli IDP Metadata (di fatto un file .xml che contiene alcuni parametri di configurazione e il certificato X509 su cui si basa la relazione di trust<\/em> tra IdP e SP) e teniamoli da parte per un passaggio successivo. ATTENZIONE!!! Il contenuto di questo file non deve essere diffuso per nessun motivo; sulla sua segretezza si basa la sicurezza di tutta la soluzione!<\/strong><\/p>\n Proseguiamo nella configurazione mappando l\u2019entit\u00e0 SAML \u201cName ID\u201d su \u201cPrimary Email\u201d (ovvero l\u2019utente verr\u00e0 presentato alla console AWS con l\u2019indirizzo mail come identificativo univoco).<\/p>\n Nel passaggio successivo dobbiamo configurare tre mapping aggiuntivi (attenzione che qui la UI di G Suite non \u00e8 molto chiara, in quanto non si leggono bene gli URL nella colonna di sinistra):<\/p>\n \u00c8 molto utile poter personalizzare questo parametro perch\u00e9 di default la sessione dura 1 ora, e, per esperienza di chi lavora parecchio sulla console AWS, \u00e8 un valore molto basso, che comporta numerosi e scomodi logout forzati durante l\u2019operativit\u00e0 quotidiana. ATTENZIONE!!! Questo \u201ctrick\u201d \u00e8 un\u2019esclusiva di beSharp; non \u00e8 documentato sulle guide ufficiali ne\u2019 di Google ne\u2019 di AWS! (nda).<\/strong><\/p>\n A questo punto la configurazione di G Suite \u00e8 terminata e passiamo alla configurazione di AWS.<\/p>\n Andiamo nella sezione IAM<\/a> –> Identity Providers e creiamone uno nuovo, di tipo SAML, che chiamiamo \u201cGoogleApps\u201d; in questo punto dovremo caricare gli IdP metadata che abbiamo scaricato in precedenza (una volta caricato il file in questo punto, suggerisco di cancellarlo dal proprio computer)<\/p>\n Poi creiamo un nuovo IAM role che chiamiamo \u201cGoogleLogin\u201d e come tipo di ruolo selezioniamo \u201cIdentity Provider Access\u201d –> \u201cWebSSO\u201d e lo associamo all\u2019Identity Provider \u201cGoogleApps\u201d che abbiamo appena creato.<\/p>\n Nei passi successivi del wizard associamo una policy allo IAM role per dare i permessi (nel nostro esempio abbiamo dato i permessi di admin \u2013 DON\u2019T TRY THIS AT HOME!!! \ud83d\ude42<\/strong> ) e la configurazione lato AWS \u00e8 terminata.<\/p>\n Adesso torniamo nell\u2019amministrazione di G Suite, per assegnare ai singoli utenti i permessi relativi a quali ruoli possono assumere e su quali account AWS.<\/p>\n Questa \u00e8 la parte meno intuitiva della configurazione: per quanto riguarda i ruoli e gli account accessibili, AWS si aspetta da Google dei valori di questo tipo:<\/p>\n Come vedete si tratta di due ARN<\/a> separati da una virgola. Il primo \u00e8 l\u2019ARN del ruolo che quell\u2019utente pu\u00f2 assumere, il secondo \u00e8 l\u2019ARN dell\u2019identity provider che abbiamo creato all\u2019interno dell\u2019account AWS. (il numero 1234567891012 \u00e8 un segnaposto che va sostituito con il vero account number del vostro account AWS). Questo valore va inserito nel campo custom \u201cIAM role\u201d che abbiamo creato in precedenza. In questo modo possiamo specificare per ogni utente quale ruolo pu\u00f2 assumere e su quale account AWS.<\/p>\n Se vi ricordate bene abbiamo fatto in modo che l\u2019attributo \u201cIAM role\u201d supportasse valori multipli; infatti \u00e8 possibile, per lo stesso utente, specificare pi\u00f9 ruoli all\u2019interno dello stesso account, o anche su account differenti. Baster\u00e0 aggiungere altre tuple del tipo:<\/p>\n e subito dopo il login ci verr\u00e0 chiesto quale ruolo vogliamo assumere su quale account.<\/p>\n Ovviamente, perch\u00e8 tutto funzioni, nel nostro esempio dovremmo ripetere la procedura di federazione SAML (con lo scambio degli IdP metadata) anche per l\u2019account 112233445566<\/p>\n Nel campo custom \u201cSessionDuration\u201d potete specificare, per ogni utente, la durata in secondi della sessione di login. Suggerisco il valore 28800, che corrisponde a 8 ore, ovvero circa a una tipica giornata lavorativa.<\/p>\n A questo punto non ci resta che abilitare la SAML application che abbiamo creato, e tutti gli utenti si troveranno una nuova icona nel loro menu di accesso rapido alle Google Apps.<\/p>\n Facciamo login\u00a0quindi con il nostro account di prova “Mario Rossi” e, cliccando sull\u2019icona corrispondente, verremo magicamente indirizzati verso la console AWS dove, come potete vedere, risultiamo loggati con il nostro account federato, m.rossi@besharp.net.<\/p>\n Soddisfatti? \ud83d\ude42<\/p>\n Nel prossimo articolo vedremo come abbiamo utilizzato, in maniera decisamente creativa, lo stesso approccio basato su G Suite e SSO per utilizzare ai servizi AWS che prevedono l\u2019autenticazione tramite la coppia key\/secret, come la AWS CLI<\/a>, CodeCommit<\/a> e l\u2019accesso alle API da client extra VPC.<\/p>\n Negli\u00a0articoli successivi, invece, approfondiremo l\u2019utilizzo di G Suite come Identity Provider per tutti gli altri servizi che normalmente richiederebbero una federazione con Active Directory o LDAP.<\/p>\n Avete dubbi o domande? Commentate l’articolo, vi risponderemo ASAP! E se volete implementare una soluzione come questa ma vi manca il tempo o la voglia… chiamateci<\/a>!<\/p>\n","protected":false},"excerpt":{"rendered":" Chi, tra gli utilizzatori della console di AWS non si \u00e8 mai scontrato con l\u2019annoso problema di gestire molteplici utenti […]<\/p>\n","protected":false},"author":3,"featured_media":186,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[471],"tags":[271,345,329],"class_list":["post-149","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-security-identity","tag-devops","tag-gsuite","tag-single-sign-on-sso"],"yoast_head":"\n\n
il limite massimo di 5 account AWS gestiti;<\/del> [UPDATE: il limite \u00e8 stato rimosso :)]<\/strong><\/li>\n<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
\n
<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
arn:aws:iam::1234567891012:role\/GoogleLogin,arn:aws:iam::1234567891012:saml-provider\/GoogleApps<\/pre>\n
<\/p>\n
<\/p>\n
arn:aws:iam::112233445566:role\/Ruolo1,arn:aws:iam::112233445566:saml-provider\/GoogleApps\r\narn:aws:iam::112233445566:role\/Ruolo2,arn:aws:iam::112233445566:saml-provider\/GoogleApps<\/pre>\n
<\/p>\n
<\/p>\n
<\/p>\n