Sistema di login serverless, maggiore sicurezza e scalabilità

Premessa

Al Santagostino abbiamo iniziato a sviluppare internamente una nuova piattaforma di cartella clinica, costruita ad-hoc sulle nostre esigenze.

Essendo una piattaforma nuova, vogliamo creare uno starterkit (per la nostra developer platform “Samaritan”) che diventi uno standard per lo sviluppo delle nostre piattaforme.

Abbiamo quindi fatto un R&D legato alla sicurezza e alla gestione di un servizio di login esterno alla piattaforma, che ci permetta:

• scalabilità
• sicurezza
• flessibilità

In questo articolo spiego l’idea tecnica alla base del sistema di login per la nuova cartella clinica che io ed il team di sviluppo abbiamo realizzato.

Tecnologie e servizi utilizzati

Essendo il 90% della nostra infrastruttura su AWS, abbiamo deciso di rimanere con AWS anche per la cartella clinica.

Tecnologie e servizi per la parte di login:

• AWS ALB: per la gestione del network e per l’astrazione della piattaforma (no accesso pubblico)
• AWS Cognito: configurato direttamente sul ALB

L’implementazione

Perché si è scelto AWS Cognito?

I requisiti per il sistema di login erano:

• utilizzo dell’OAuth Google
• sicurezza

Con questi requisiti la scelta di AWS Cognito è stata la più naturale.

Avere un sistema gestito per la login evita una complessità necessaria, ma che per il business non dà quel valore aggiunto legato alla piattaforma finale (la login è un requisito tecnico e poco di business).

Inoltre, la scelta di AWS Cognito permette l’introduzione di un SSO per tutte le piattaforme, usandolo come connettore unito di login.

AWS ALB + Cognito l’accoppiata vincente per la sicurezza?

Mi sono posto la domanda di come rispettare il requisito di sicurezza anche sulla login. Oltre a utilizzare il provider Google, agganciare AWS Cognito direttamente sul Load Balancer permette di non dover esporre la piattaforma all’esterno.

Questo, in termini di sicurezza, è estremamente utile, perché nessuno conosce cosa sta dietro il Load Balancer: tutto è nascosto finché non si effettua un login valido (nemmeno un sistema di sniffing del codice riesce a capire cosa c’è dietro).

Collegare AWS Cognito con la piattaforma

Una difficoltà è stata quella di collegare la sessione della login con la piattaforma per far interpretare al framework sottostante che l’utente era loggato e aveva un determinato ruolo utente.

Di solito ogni framework usa tabelle interne per gestire la login e recuperare ruolo e regole di ACL.

In questa idea invece si è dovuto spezzare questa logica in 2 pezzi:

• AWS Cognito: gestisce DB utenti e l’autorizzazione ad accedere
• Piattaforma: gestisce ruolo e relativa ACL (Access Control List)

WorkFlow Login

Di seguito uno schema che descrive il flusso, attori, azioni per effettuare una login.

WorkFLow Logout

Il Logout dovrà avvenire sia sulla piattaforma sia su Cognito per invalidare il JWT.

Questo sistema si è realizzato sfruttando la callback logout di Cognito.

Il logout avverrà sulla piattaforma e Cognito, ma non sul provider Google cosi da non “buttar fuori” l’utente da altri servizi come GMail.

Conclusione

Questa è una di alcuni R&D e scelte fatte per le nostre piattaforme.

Sulla cartella clinica scriveremo magari altri articoli, per spiegare l’architettura software, le scelte e come i servizi cloud implementati ci abbiano permesso con meno sforzi e complessità un sistema più stabile e sicuro.