Semplifica l'integrazione dell'autenticazione SAML per gli sviluppatori
Scopri cos'è SAML, come implementare l'SSO e i passaggi rapidi per integrare l'autenticazione SAML come Identity Provider (IdP) o Service Provider (SP).
Single Sign-On (SSO) è fondamentale per le app moderne, e SAML permette un'autenticazione sicura e intuitiva tra i sistemi di identità aziendali. Questa guida semplifica SAML per sviluppatori e designer con passaggi chiari ed esempi pratici per aiutarti a implementarlo in modo efficiente.
Cosa sono l'autenticazione SAML e le app SAML?
Security Assertion Markup Language (SAML) è uno standard basato su XML utilizzato per scambiare dati di autenticazione e autorizzazione tra due attori chiave: l'Identity Provider (IdP) e il Service Provider (SP). È una soluzione comune per il Single Sign-On (SSO) nelle organizzazioni, rendendo la vita più facile agli utenti enterprise permettendo loro di accedere una sola volta e accedere a più applicazioni.
L'Identity Provider (IdP) gestisce e verifica le credenziali dell'utente, come nomi utente e password. Quando un utente tenta di accedere a un servizio protetto, l'IdP conferma la sua identità e invia questa conferma al servizio.
- Esempio: Immagina di lavorare per una grande azienda che utilizza Microsoft Azure AD per la gestione degli account dei dipendenti. Quando vuoi accedere a Salesforce, Azure AD funge da IdP. Verifica le tue credenziali e informa Salesforce che sei autorizzato a usarlo.
Il Service Provider (SP) è l'applicazione o servizio a cui gli utenti stanno effettivamente cercando di accedere. Dipende dall'IdP per gestire la parte più complessa dell'autenticazione.
- Esempio: Proseguendo nello scenario sopra, Salesforce è il SP. Si affida a Microsoft Azure AD (l'IdP) per confermare la tua identità. Una volta che Azure AD garantisce per te, Salesforce ti consente l'accesso.
Quando si parla di una “app SAML”, di solito si fa riferimento al SP.
Utilizzando il protocollo SAML, puoi configurare il tuo servizio come IdP per supportare le integrazioni tra applicazioni (come Azure Ad / Google Workspace); oppure come SP (come Salesforce / Slack) per supportare l'SSO per gli utenti.
Una SAML Assertion è il cuore del protocollo SAML. È una sorta di “nota digitale” creata dall'IdP e inviata a uno SP che dice: “Ho confermato l'identità di questo utente.” Ora vedremo come funziona il processo sia per l'IdP che per il SP.
Quando si agisce come Identity Provider SAML
Quando il tuo servizio funziona come IdP, abiliti l'autenticazione SAML su più applicazioni. Questo consente agli utenti di accedere a diversi servizi tramite un'unica identità aziendale.
Ecco un tipico flusso di lavoro SSO SAML per un IdP:
- L'utente tenta di accedere a un'applicazione (SP), come Salesforce.
- L'applicazione reindirizza l'utente al tuo IdP per l'autenticazione.
- L'utente inserisce le proprie credenziali nella pagina di accesso del tuo IdP.
- L'IdP verifica le credenziali.
- Se le credenziali sono corrette, l'IdP invia una SAML assertion al SP.
- Il SP elabora la assertion, ne conferma la validità e concede l'accesso all'utente.
Quando si agisce come Service Provider SAML
Se il tuo servizio è il SP, integrerai diversi Identity Provider per offrire ai tuoi utenti la possibilità di SSO. Questo consente agli utenti aziendali di diverse organizzazioni o tenant di accedere in modo sicuro ed efficiente alla tua applicazione.
Ecco un flusso di lavoro per un SSO iniziato dal SP:
- L'utente prova ad accedere alla tua applicazione.
- La tua applicazione genera una richiesta SAML e reindirizza l'utente alla pagina di accesso dell'IdP.
- L'utente esegue l'accesso presso l'IdP (o salta questo passaggio se ha già effettuato l'accesso).
- L'IdP verifica l'identità dell'utente e, una volta confermata, inserisce i dettagli dell'utente in una SAML assertion.
- L'IdP invia la assertion alla tua applicazione.
- Il tuo servizio verifica la assertion. Se è valida, l'utente ottiene l'accesso alla tua applicazione.
Parametri chiave nell'SSO SAML
Per una integrazione SSO SAML di successo, sia IdP che SP devono condividere parametri specifici. Ecco quali sono gli elementi essenziali:
Parametri provenienti dall'IdP
- IdP Entity ID: Un identificatore univoco per l'IdP nelle comunicazioni SAML, come una targhetta digitale.
- SSO URL: L'endpoint di accesso (URL) dove il SP reindirizza gli utenti per l'autenticazione.
- Certificato X.509: Una chiave pubblica utilizzata per firmare la SAML assertion, garantendo la sicurezza. Questo è il “sigillo” che certifica l'autenticità.
Suggerimento: se il tuo IdP offre una SAML Metadata URL, tutto diventa più semplice. Questo URL contiene tutte le informazioni necessarie (come certificati, SSO URL e IdP Entity ID) in un unico posto. Riduce il rischio di errori dovuti al copia-incolla manuale ed elimina la necessità di aggiornare manualmente i file dei certificati.
Parametri provenienti dal SP
- SP Entity ID: L'identificatore univoco del SP, simile a quello dell'IdP.
- Assertion Consumer Service (ACS) URL: L'endpoint del SP dove il SP si aspetta di ricevere la SAML assertion dall'IdP.
- RelayState (opzionale): Usato per passare dati durante il processo SAML, come l'URL che l'utente stava originariamente cercando di visitare.
Mapping degli attributi SAML e crittografia
- Formato NameID: Define il formato dell'identificativo utente (ad esempio, indirizzo email o nome utente).
- Attributi SAML: Sono dettagli aggiuntivi sull'utente, come ruoli, email o reparto, che l'IdP invia al SP.
- Esempio: se la SAML assertion firmata dall'IdP include
email
([email protected]),role
(admin) edepartment
(engineering). Il SP può usarerole
per assegnare privilegi da admin oppuredepartment
per raggruppare l'utente nel team corretto. Per ottenere questi dati essenziali, sia l'IdP che il SP devono decidere come mappare gli attributi. Ad esempio, l'IdP potrebbe definire "department" come team, mentre il SP si aspetta group. Un mapping corretto assicura una comunicazione fluida.
- Esempio: se la SAML assertion firmata dall'IdP include
- Assertions crittografate (opzionale): Per proteggere i dati sensibili di autenticazione, le assertion SAML possono essere crittografate.
- Ruolo dell'IdP: Cripta la assertion usando la chiave pubblica del SP.
- Ruolo del SP: Decripta la assertion con la propria chiave privata per leggere i dati dell'utente.
A questo punto, dovresti avere tutte le informazioni necessarie per impostare una connessione SAML. Per integrare Salesforce (Service Provider) con Azure AD (Identity Provider), segui questi passaggi:
- Ottieni da Azure AD l'IdP Entity ID, l'SSO URL e il certificato e configura questi parametri su Salesforce.
- Fornisci a Azure AD l'SP Entity ID e l'ACS URL di Salesforce.
Logto rende semplice l'integrazione SAML
Logto può agire sia come IdP che come SP per supportare l'SSO SAML sulle tue applicazioni.
Utilizzare Logto come SAML IdP
Logto permette ad altre applicazioni di affidarsi ad esso per l'autenticazione federata dell'identità e supporta la multi-factor authentication (MFA) per una maggiore sicurezza.
- Crea una Logto App Vai su Logto Console > Applications e crea una nuova app SAML.
- Configura i parametri SAML Configura l'app con la Assertion Consumer Service URL e lo SP Entity ID del Service Provider (SP).
- Fornisci la metadata URL Logto fornisce una IdP Metadata URL che i SP possono usare per recuperare automaticamente informazioni essenziali, come SSO URL e certificati.
- Configurazione avanzata (opzionale)
- Puoi creare più nuovi certificati con fingerprint e impostare date di scadenza, ma solo un certificato può essere attivo alla volta.
- Modifica il formato Name ID per adattarlo alle tue esigenze aziendali.
- Abilita la crittografia delle SAML assertion copiando e incollando il certificato x509 del tuo service provider per criptare le assertion.
- Mappa gli attributi (opzionale) Personalizza facilmente il modo in cui gli attributi utente vengono condivisi con i Service Provider (SP).
Per una guida dettagliata, visita la documentazione ufficiale qui: SAML App
Utilizzare Logto come SAML SP
Logto si integra inoltre con qualsiasi IdP enterprise tramite protocolli SAML o OIDC. Che tu stia abilitando SSO iniziato dal SP per le tue pagine di accesso unificate o configurando SSO iniziato da IdP, il processo è semplice.
- Crea un connettore enterprise Vai su Logto Console > Enterprise SSO e crea un nuovo Enterprise Connector. Seleziona SAML come protocollo standard.
- Configura i parametri SAML Fornisci la metadata URL o il file XML metadata dal tuo IdP. Se la metadata non è disponibile, passa alla configurazione manuale inserendo l'IdP Entity ID, l'SSO URL e caricando il certificato di firma.
- Condividi la ACS URL e lo SP Entity ID Fornisci all'IdP l'ACS URL e lo SP Entity ID di Logto per completare la configurazione dell'integrazione.
- Mappa gli attributi (opzionale) Configura i mapping dei dati utente, come email o nomi, per garantire che le informazioni vengano passate correttamente tra IdP e Logto.
- Aggiungi domini email aziendali Nella scheda “SSO Experience” del connettore enterprise, aggiungi uno o più domini email. Questo garantisce che solo gli utenti con i domini specificati possano autenticarsi tramite SSO.
- Abilita SSO iniziato da IdP (opzionale) Abilita SSO iniziato da IdP solo se richiesto dai tuoi clienti aziendali. Questa funzionalità consente agli utenti di accedere alle tue applicazioni direttamente dalla dashboard dell'IdP.
Per una guida dettagliata, consulta la documentazione ufficiale qui: Enterprise SSO documentation.
Riflessioni finali
SAML offre un metodo standardizzato e sicuro per l'SSO, rendendo più semplice l'autenticazione. Logto semplifica il processo sia che tu lo imposti come IdP che come SP. Grazie alla sua interfaccia intuitiva e al supporto sia per la versione cloud che open-source, Logto elimina la complessità dell'integrazione SAML. Configurando pochi parametri, puoi connettere i tuoi servizi a qualsiasi IdP o SP SAML e concentrarti sulla creazione di esperienze di qualità per i tuoi utenti.