## Contesto Ho iniziato a costruire Logto perché ho notato che la Gestione delle Identità e degli Accessi (IAM) era diventata sempre più complessa e vasta nel tempo. Il concetto di IAM è abbastanza grande da dare origine a nuovi concetti, come WIAM (Workforce IAM) e CIAM (Customer IAM). Sebbene WIAM e CIAM condividano la stessa base, hanno casi d'uso distinti: WIAM è tipicamente usato per utenti interni, mentre CIAM è usato per clienti esterni. Alcuni esempi: - **WIAM** La tua azienda ha un sistema di identità unificato per i dipendenti, quindi ognuno può usare lo stesso account per accedere alle risorse dell'azienda, come abbonamenti software, servizi di cloud computing, ecc. - **CIAM** La tua libreria online richiede un sistema di identità utente per clienti e venditori. L'esperienza di accesso è una parte critica del processo di onboarding, poiché si trova in cima al funnel di conversione. Logto ha iniziato con il CIAM per vari motivi (avremo un altro articolo che ne parlerà). Durante lo sviluppo, ci siamo resi conto che costruire una comprensione unificata tra il team sarebbe stato utile prima di portare il nostro prodotto al livello successivo. Speriamo che questo ti aiuti anche a comprendere meglio il panorama IAM. Iniziamo! ## Le basi del CIAM Indipendentemente dalle loro differenze, WIAM e CIAM hanno entrambi la stessa base: autenticazione e autorizzazione. Questi due concetti sono al centro delle loro funzionalità. In questo articolo, ci concentreremo sui concetti fondamentali del CIAM e sui problemi che potremmo incontrare durante o dopo il flusso di autenticazione. Discuteremo anche del single sign-on (SSO) e dei relativi scenari. ### Autenticazione e autorizzazione - Autenticazione (AuthN) risponde alla domanda "Quale identità possiedi?" - Autorizzazione (AuthZ) risponde alla domanda "Cosa puoi fare?" > 💡 L'autenticazione è inizialmente definita come "Chi sei tu?". Tuttavia, quando si discutono di identità digitali, è più accurato dimostrare l'autenticazione tramite "prova del possesso dell'identità". (Credito a [Calm-Card-2424](https://www.reddit.com/r/programming/comments/10uycg0/comment/j7eyhrb/)) Se scopri qualcosa che non rientra in nessuna di queste due categorie, è probabilmente non essenziale per il business dell'identità. - **Esempi di autenticazione** - Accesso con password, accesso senza password, accesso sociale, ecc. - Autenticazione Machine-to-Machine - **Esempi di autorizzazione** - Controllo degli Accessi Basato su Ruoli - Controllo degli Accessi Basato su Attributi - **Esempi di eccezioni** - Dati non relativi all'identità - Web hooks ### Identità e Tenant L'identità rappresenta tipicamente un utente o una macchina. Al termine dell'autenticazione, viene rilasciato un Token ID come Identità. In altre parole, l'obiettivo principale dell'autenticazione è ottenere un'Identità. Un Tenant è un gruppo di identità: ```mermaid graph TD Tenant --- A[Identità: Utente 1] Tenant --- B[Identità: Utente 2] Tenant --- C[Identità: Macchina 1] ``` Quando discutiamo di "Multi-tenant", ci riferiamo a più istanze Logto che sono identità isolate l'una dall'altra. In altre parole, più istanze Logto. ```mermaid graph TD T1[Tenant 1] --- A[Identità: Utente 1] T2[Tenant 2] --- B[Identità: Utente 1] T2[Tenant 2] --- C[Identità: Macchina 1] subgraph IS2[Sistema di identità 2] T2 B C end subgraph IS1[Sistema di identità 1] T1 A end ``` Nota che ci sono due sistemi di identità **isolati**, ovvero non puoi usare l'Identità del Tenant 1 nel Tenant 2, anche per lo stesso identificatore (email, telefono, ecc.). È come la tua membership Costco che non è valida da Whole Foods. 🧱 In breve, ci sono “muri fisici” tra i Tenant. La definizione di "Tenant" varia tra i prodotti CIAM. Alcuni fanno riferimento al termine "Organizzazione" in Logto, che sarà introdotto successivamente. ### App e Tenant Proprio come l'Identità, anche un'App appartiene a un Tenant. Cose da ricordare: - Tipicamente non esiste una relazione diretta tra un'App e un'Identità. - Un'Identità può rappresentare un'App, ma non c'è una connessione diretta tra di loro. - Come gli utenti, anche le app sono a livello di Tenant. - Le app sono codice, mentre gli utenti sono umani. - Lo scopo unico delle App è completare l'autenticazione, ovvero ottenere un'Identità. ### Identity Provider (IdP) e Service Provider (SP) La differenza tra questi due fornitori è complicata ma importante. - **Identity Provider** è un servizio che fornisce autenticazione (AuthN) e rilascia identità. Puoi trovare varie spiegazioni sul Service Provider da Google, anche se possono non essere soddisfacenti. Nella mia mente, Service Provider è un concetto relativo: - **Service Provider (o Relying Party in [OIDC](https://openid.net/specs/openid-connect-core-1_0.html))** è un servizio o cliente che avvia l'autenticazione (AuthN) e richiede il risultato ai fornitori di identità. #### Quiz Considera uno scenario tipico di accesso sociale: ```mermaid graph LR A[iOS App] --> |Inizia l'accesso| Logto --> |Reindirizza| GitHub GitHub --> |Restituisci ID GitHub| Logto --> |Restituisci ID Logto| A ``` **❓ Quanti Service Provider e Identity Provider ci sono in questo grafico?**

Risposta

Entrambi ne hanno due. L'iOS App è un service provider per Logto, mentre Logto è un identity provider. Logto è anche un service provider per GitHub, mentre GitHub è un identity provider. Quindi, Logto è un Service Provider e anche un Identity Provider.

## Studio di caso: Una società di soluzioni tecnologiche Sei un CTO di una società di soluzioni tecnologiche, hai oltre 100 partner commerciali e hai consegnato più di 300 progetti. - Ogni progetto è un'app web o un'app mobile con un servizio di backend. - Per ogni partner commerciale, vuoi ristrutturare il sistema utente per fornire SSO attraverso i suoi progetti. **❓ Come può aiutare Logto (o un prodotto CIAM)?**

Risposta

Crea un'istanza Logto per ogni partner commerciale. Ogni partner possiede un Tenant. I progetti sono mappati su "App" in Logto. ```mermaid graph TD T1[Tenant 1] --- A[App 1] T1 --- B[App 2] T1 --- C[App 3] T1 --- U1[Utente 1] T1 --- U2[Utente 2] T2[Tenant 2] --- D[App 1] T2 --- E[App 2] T2 --- U21[Utente 1] T2 --- U22[Utente 2] ``` Logto offre un'esperienza di accesso universale (cioè SSO) all'interno di un Tenant, quindi gli utenti non devono accedere nuovamente quando accedono a un'altra app nello stesso Tenant se hanno già effettuato l'accesso.

## Di cosa parliamo quando parliamo di SSO Abbiamo scoperto che il termine "SSO" spesso causa confusione. Consideriamo il single sign-on (SSO) come un comportamento, non un concetto aziendale. Pertanto, SSO non equivale a "SSO in WIAM". Quando diciamo "è necessario SSO", può riferirsi a uno dei seguenti casi: ### SSO Caso 1 > 👉🏽 In una grande azienda, i dipendenti usano le stesse credenziali per accedere a tutte le risorse con licenza aziendale (ad es. email, IM, servizi cloud). È lo scenario tipico del WIAM. In questo caso, è coinvolto solo un Identity Provider. Non ci interessa per ora. ### SSO Caso 2 > 👉🏽 Gli utenti finali usano le stesse credenziali per accedere a tutti i servizi sviluppati dalla stessa azienda (ad es. GSuite). Logto si concentra attualmente sull'approccio delineato sopra. Più fornitori di identità esterni, come un fornitore di accesso sociale di terze parti, possono esistere indipendentemente e senza connessione. Nonostante ciò, Logto rimane l'unica fonte di verità per le Identità, semplicemente "prendendo in prestito" da altri fornitori. In questo caso, Logto agisce sia come Identity Provider (per le app GSuite) sia come Service Provider (per i fornitori di identità esterni). ### SSO Caso 3 > 👉🏽 Gli utenti finali possono utilizzare solo il specifico Identity Provider all'interno del dominio email corrispondente per completare l'autenticazione. Ad esempio, accedere a Figma con Google Workspace. Questo è il caso d'uso più comune per SSO in CIAM. Vediamolo più da vicino. Se vogliamo accedere a Figma usando la nostra email @silverhand.io, possiamo usare sia il social sign-in sia l'SSO. Le figure seguenti illustrano la differenza tra i due:

In parole: - Dopo il social sign-in, gli utenti sono liberi di impostare una password o cambiare l'indirizzo email in Figma - Dopo l'SSO, gli utenti non possono impostare la password o cambiare alcuna informazione personale compreso l'indirizzo email, poiché le loro Identità sono gestite da Google Workspace In questo caso, Logto è sia un Identity Provider sia un Service Provider. Sembra che l'SSO sia più complesso di un normale processo di sign-in. Quali sono i vantaggi per il proprietario dell'identità? - **Controllo centralizzato:** Mantieni le informazioni sull'identità e i processi di autenticazione in un unico luogo e assicurati che le informazioni dell'utente siano sempre aggiornate. Non c'è bisogno di aggiungere e rimuovere licenze per alteriorganizzazioni per cambiamenti. - **Miglior esperienza utente:** I proprietari di identità che richiedono l'SSO sono solitamente aziende. I loro dipendenti possono usare le stesse credenziali e sessioni condivise per applicazioni aziendali, come Figma, Zoom, Slack, ecc. - **Migliorata sicurezza:** Avrai notato che alcune aziende richiedono metodi di accesso specifici, come codici di verifica dinamici. Usare l'SSO può assicurare che ogni dipendente usi la stessa combinazione di metodi di accesso per accedere a tutte le risorse. > 🤔 Intelligente come te avrà notato che questo è in realtà **SSO Caso 1** dal punto di vista del SaaS. È tempo di discutere della "X" nel grafico SSO. Questo rappresenta il processo di connessione di Figma tra il dominio email e un specifico Identity Provider. Ma, come funziona? ## Mappatura SSO Poiché la richiesta proviene spesso da clienti aziendali, ci riferiamo al processo di "SSO Caso 3" nella sezione precedente come "SSO aziendale" per maggiore chiarezza. Possiamo facilmente ideare una soluzione ingenua: creare una mappatura tra domini email e metodi SSO, poi aggiornare manualmente. L'azione del processo "X" è ora chiara: > 🔍 **Trova il metodo SSO aziendale mappato al dominio email dato** Quindi, se configuri `silverhand.io` come un dominio email valido che si collega a un URL SSO Google Workspace, gli utenti che cercano di accedere con un'email `@silverhand.io` verranno reindirizzati alla pagina di sign-in Google Workspace corrispondente, invece di essere trattati sul posto. Quando hai solo una decina di clienti che necessitano di SSO aziendale, gestire manualmente la mappatura è accettabile. Tuttavia, ci sono più cose da considerare: 1. _Cosa succede se ci sono centinaia o migliaia di clienti SSO aziendali?_ 2. _Qual è la relazione tra "utenti normali" e "utenti SSO aziendali"?_ 3. _I dati devono essere isolati tra i diversi clienti SSO aziendali?_ 4. _C'è bisogno di fornire una dashboard per gli amministratori SSO aziendali per visualizzare gli utenti attivi, i log di audit, ecc.?_ 5. _Come possono essere automaticamente disattivati gli account quando un utente viene rimosso dal Identity Provider SSO aziendale?_ E molto altro. Poiché quasi tutti i SSO aziendali sono basati sui domini email, possiamo rapidamente pensare a una soluzione migliore: - Se l'utente può dimostrare il possesso di quel dominio, può configurare l'SSO aziendale di quel dominio in modo self-service. Questa soluzione risponde alle prime due domande: > _1. Cosa succede se ci sono centinaia o migliaia di clienti SSO aziendali?_ - Possono configurare l'SSO aziendale in modalità self-service. > _2. Qual è la relazione tra "utenti normali" e "utenti SSO aziendali"?_ - Apriamo tutti i possibili metodi di sign-in agli utenti normali eccetto l'SSO aziendale; mentre limitiamo il metodo di sign-in al solo SSO aziendale agli utenti che tentano di accedere con i domini configurati. Per la terza domanda: > _3. I dati devono essere isolati tra i diversi clienti SSO aziendali?_ - Sì e no. È tempo di introdurre l'organizzazione. ## Organizzazione Abbiamo menzionato l'uso dei domini email per riconoscere il specifico metodo SSO aziendale da utilizzare; in altre parole, applicare un trattamento specifico per un lotto specifico di utenti. Tuttavia, le richieste dei clienti sono spesso più di semplici SSO aziendali; ad esempio, le domande 4 e 5 nella sezione precedente. Nel corso degli anni, un modello maturo è stato sviluppato da eccezionali aziende SaaS per affrontare questo tipo di problemi: le Organizzazioni. **Regole delle organizzazioni** 1. Un'organizzazione è un gruppo di identità, tipicamente più piccole di un Tenant. 2. Tutte le organizzazioni sono associate a un Tenant. Potresti vedere altri termini, come "Workspace", “Team” o addirittura "Tenant" nel software. Per identificare se è il concetto di cui stiamo discutendo, verifica se rappresenta “un gruppo di identità”. In questo articolo, utilizzeremo il termine "Organizzazione" per coerenza. 🤹🏽‍♀️ Nella maggior parte dei casi, "un gruppo di identità" equivale a "un gruppo di utenti". Tuttavia, **la stessa Identità può esistere in più Organizzazioni**. In Notion, puoi creare e unirti a più workspace (cioè Organizzazioni) con lo stesso indirizzo email e cambiarli facilmente. Per Slack, sembra essere lo stesso, ma sospettiamo che usi identità diverse dietro le quinte poiché dobbiamo creare un nuovo account per ogni workspace.

![Slack workspaces](https://uploads.strapi.logto.io/1/slack_workspaces_b4f0bcc978.png) _Slack workspaces_ ![Notion workspaces](https://uploads.strapi.logto.io/1/notion_workspaces_5bdc2b7e9b.png) _Notion workspaces_

Notion ha un “Piano Personale” disponibile, che è normalmente un'Organizzazione sotto il cofano, con l'unico utente (te) all'interno. Non conosciamo l'implementazione esatta di Notion, ma questa spiegazione è ragionevole e archiviabile per il nostro modello. Ogni Organizzazione ha anche un identificatore, solitamente indicato come "dominio dell'Organizzazione". Un "dominio dell'Organizzazione" è un identificatore interno usato per distinguere le Organizzazioni. Può differire dal "dominio email", poiché il primo è gestito dal Service Provider, mentre il secondo è solitamente fornito da un Identity Provider esterno. Ad esempio, puoi usare `foo` come dominio dell'Organizzazione in Slack, ma usare `@bar.io` come dominio email per questa Organizzazione. ### Quiz **❓ Un'app può essere associata a un'Organizzazione?**

Risposta

Sì sì. Come abbiamo discusso all'inizio, un'app può avere un'Identità. Puoi elaborare uno scenario di business di questo?

## Domande rimaste > _3. I dati devono essere isolati tra i diversi clienti SSO aziendali?_ - **Sì:** Isolare i dati aziendali, come messaggi e documenti, a livello di Organizzazione. - **No:** Mantenere le Identità indipendenti, in quanto non devono essere associate a un'Organizzazione. - Nota che ci sono tre entità distinte coinvolte qui: Identità, Organizzazioni e configurazioni SSO aziendali; che hanno notevolmente aumentato la complessità. La domanda stessa non è abbastanza specifica. > _4. C'è bisogno di fornire una dashboard per gli amministratori SSO aziendali per visualizzare gli utenti attivi, i log di audit, ecc.?_ > > _5. Come disattivare automaticamente l'account quando l'utente viene rimosso dal Identity Provider SSO aziendale?_ - Queste esigenze sono più orientate al business e possono essere implementate a livello di Organizzazione. Le lasciamo aperte qui. ## Note conclusive Abbiamo introdotto diversi concetti: Autenticazione (AuthN), Autorizzazione (AuthZ), Identità, Tenant, Applicazione, Identity Provider (IdP), Service Provider (SP), Single sign-on (SSO) e SSO aziendale (Organizzazione). Potrebbe volerci del tempo per capirli tutti. Mentre scrivevo questo articolo, ho notato che, curiosamente, i piani più costosi dei servizi online includono spesso funzionalità esclusive relative all'autorizzazione, che non sono affatto menzionate in questo articolo. Potresti già avere alcune domande sull'autorizzazione, come ad esempio: - Come possiamo assegnare permessi a un utente e verificarli? - Quale modello di autorizzazione dovrei usare? - Qual è la migliore pratica per applicare un modello di autorizzazione? 🔥 Fai una pausa e ci vediamo in CIAM 102!