saml-2.0 Tutorial
Iniziare con saml-2.0
Ricerca…
Osservazioni
SAML2.0 è uno standard aperto utilizzato per il trasferimento di dati di autenticazione e autorizzazione tra provider di servizi e provider di identità.
L'utilizzo più comune è SSO basato sul Web, in cui SAML è ciò che ha consentito a un utente di accedere a un'applicazione con credenziali da un altro sistema, senza che sia necessario che i due sistemi si connettano l'un l'altro direttamente durante l'autenticazione.
Il flusso di autenticazione SAML2.0
SAML specifica tre ruoli chiave:
Il provider di identità (IdP)
La parte che fornisce e mantiene l'identità degli utenti. Questo può essere un servizio di directory come ADFS o una soluzione di database personalizzata.
Il fornitore di servizi (SP)
Il fornitore di servizi è il servizio effettivo a cui l'utente tenta di accedere. Questo può essere un sito Web, un'applicazione o qualsiasi servizio a cui un utente deve essere richiesto per accedere.
Il principale / l'utente
L'utente effettivo che avvia la richiesta o tenta di accedere a una risorsa dal fornitore di servizi (SP).
Il caso di utilizzo principale di SAML è SSO basato sul Web , in cui il processo SAML viene gestito da un set di reindirizzamenti all'interno del browser dell'utente, in cui l'utente funge da vettore token tra IdP e SP.
Esistono due flussi per SSO basato sul Web che utilizzano SAML:
Identity Provider (IdP) avviato
L'utente accede all'IdP e viene quindi inoltrato all'SP di scelta. Ad esempio, un utente accede a una intranet aziendale e viene presentato con tutte le applicazioni disponibili.
Provider di servizi (SP) avviato
L'utente prova ad accedere a un'applicazione, ma viene inoltrato all'IdP per eseguire l'autentica autenticazione. Ad esempio, un utente tenta di accedere a un'applicazione SaaS remota, ma viene inoltrato a un IdP aziendale in modo che l'utente possa accedere con le proprie credenziali aziendali all'applicazione remota.
Il flusso avviato da SP viene visualizzato in modo significativo dal flusso di lavoro seguente:
Fonte: Wikipedia
- Un utente tenta di accedere a una risorsa su una specifica applicazione o pagina web
- Un utente specifica (s) che tenta di accedere utilizzando un IdP esterno. L'SP genererà un'asserzione SAML e la trasmetterà (di solito attraverso le variabili POST o GET) mentre ti inoltrerà all'IdP
- L'utente si autenticherà contro l'IdP
- L'asserzione e il token firmati sono generati dall'IdP
- L'asserzione e il token firmati vengono inoltrati (sempre usando le variabili POST o GET) allo SP e, in caso di esito positivo, viene avviata una sessione su SP
- e inoltre l'utente è in grado di richiedere ulteriori risorse dal SP mentre ha una sessione attiva con il SP (cioè attraverso i cookie) in modo che non debba autenticarsi con l'IdP su ogni richiesta.
Strumenti di debug SAML
Con tutte le richieste e le asserzioni che vanno avanti e indietro, può essere complicato eseguire il debug dei problemi con le affermazioni e le asserzioni SAML.
Poiché all'interno di SAML un principio fondamentale non richiede una connessione diretta tra IdP e SP, il browser dell'utente funge da vettore di messaggi tra i due. Per questo motivo tutte le comunicazioni, anche se crittografate, passano attraverso il tuo browser.
Utilizzando vari strumenti di debug è possibile visualizzare la comunicazione e le richieste esatte e inoltrate tra IdP e SP.
Per iniziare, ecco un paio di strumenti per vari browser che dovrebbero iniziare:
Cromo
Firefox
Utilizzando ad esempio SAML Tracer è possibile visualizzare asserzioni e richieste SAML decodificate in tempo reale durante il test e il debug