SAML vs accesso federato con OAuth
Risposte:
Risolvono diversi problemi.
SAML è un insieme di standard che sono stati definiti per condividere informazioni su chi è un utente, quali sono i suoi attributi e per darti un modo per concedere / negare l'accesso a qualcosa o persino richiedere l'autenticazione.
OAuth riguarda più la delega dell'accesso a qualcosa. In pratica stai permettendo a qualcuno di "agire" come te. È più comunemente usato per concedere l'accesso alle API che possono fare qualcosa per tuo conto.
Sono due cose completamente diverse.
Alcuni esempi che potrebbero aiutare.
OAuth pensa a un twitter. Diciamo che stai usando Google Buzz e Twitter e vuoi scrivere un'app per essere in grado di mantenere sincronizzati i due. Fondamentalmente puoi stabilire la fiducia tra la tua app e Twitter. La prima volta che colleghi l'app a Twitter, esegui il classico prompt per accedere a Twitter, quindi si apre la finestra di conferma che chiede "Desideri concedere l'accesso a« nome della tua app »?" una volta che fai clic su "sì", la fiducia è stata stabilita e ora la tua app può agire come te su Twitter. Può leggere i tuoi post e crearne di nuovi.
SAML - Per SAML pensa a un qualche tipo di "accordo" tra due sistemi di appartenenza non correlati. Nel nostro caso possiamo utilizzare US Airways e Hertz. Non esiste un set condiviso di credenziali che possa portarti da un sito all'altro, ma supponiamo che Hertz voglia offrire un "affare" a US Airways. (Certo, so che questo è un esempio estremo, ma abbi pazienza). Dopo aver acquistato un volo, offriranno un'auto a noleggio gratuita ai membri del presidente. US Airways e Hertz stabiliscono una qualche forma di fiducia e un modo per identificare l'utente. Nel nostro caso il nostro "ID federato" sarebbe l'indirizzo e-mail e sarebbe un insieme di fiducia unidirezionale Hertz confida che il fornitore di identità di US Airways fornirà un token accurato e sicuro. Dopo aver prenotato il volo, il fornitore di identità di US Airways genererebbe un token e popolerebbe il modo in cui ha autenticato l'utente, così come gli "attributi" sulla persona nel nostro caso l'attributo più importante sarebbe il suo livello di stato in US Airways. Una volta che il token è stato popolato, lo passa tramite un qualche tipo di riferimento o codificato in un URL e una volta arrivati a Hertz, guarda il token, lo convalida e ora può consentire il noleggio gratuito dell'auto.
Il problema con questo esempio SAML è che è solo un caso d'uso specializzato su molti. SAML è uno standard e ci sono quasi troppi modi per implementarlo.
In alternativa, se non ti interessa l'autorizzazione, potresti quasi sostenere che affermi l'autenticazione tramite SAML e OpenID .
Dai un'occhiata a questa semplice spiegazione riassunta qui:
Molte persone sono confuse riguardo alle differenze tra SAML, OpenID e OAuth, ma in realtà è molto semplice. Sebbene vi siano alcune sovrapposizioni, ecco un modo molto semplice per distinguere tra i tre.
OpenID: Single Sign-On per i consumatori
SAML: Single Sign-On per utenti aziendali
OAuth: autorizzazione API tra applicazioni
Per le persone a proprio agio con i modelli di design OO, penso che ci sia un bel corollario ai modelli di wrapper . Pensa ai modelli Facade , Decorator e Proxy . Fondamentalmente sono tutti uguali, sono solo involucri ... La differenza è l' intenzione di ogni modello .
Allo stesso modo, SAML, OAuth e OpenID facilitano intenzioni diverse tramite un meccanismo sottostante comune , che è il reindirizzamento a un provider di servizi / autorità di identità per alcune interazioni private, seguito dal reindirizzamento all'app di terze parti di origine.
Guardandoti intorno in rete troverai delle sovrapposizioni tra le funzionalità dei protocolli. L'autenticazione tramite OAuth è perfettamente ragionevole. SSO su OAuth potrebbe non avere molto senso, poiché SAML e OpenID sono specificamente orientati all'identità federata.
Alla domanda stessa, in un contesto aziendale SAML sembra più appropriato di OAuth per SSO . Scommetto che se guardi le app di terze parti che vorresti integrare con le tue identità aziendali, scoprirai che sono già progettate per integrarsi con SAML / LDAP / Radius ecc. IMO OAuth è più appropriato per l'interazione Internet tra applicazioni o forse applicazioni che comprendono un'architettura orientata ai servizi in un ambiente aziendale di grandi dimensioni.
Le regole di autorizzazione possono essere specificate in un ambiente aziendale anche in altri modi. LDAP è uno strumento comune per questo. Organizzare gli utenti in gruppi e associare i privilegi dell'applicazione contro l'appartenenza al gruppo è un approccio diffuso. Proprio così, LDAP può essere utilizzato anche per l'autenticazione. Active Directory è un ottimo esempio, anche se preferisco OpenLDAP.
Trovato un buon articolo qui
SAML (Security Assertion Markup Language) è un insieme di standard per ottenere Single Sign On (SSO), Federation e Identity Management.
Esempio : un utente (principale) si autentica con un sito Web di prenotazione voli, AirFlyer (fornitore di identità) che ha SSO configurato tramite SAML con un sito Web di prenotazione navetta, Shuttler (fornitore di servizi). Una volta autenticato su Flyer, l'utente può prenotare navette su Shuttler senza richiedere l'autenticazione
OAuth (Open Authorization) è uno standard per l'autorizzazione delle risorse. Non si occupa dell'autenticazione.
Esempio : un'app mobile per la condivisione di foto (consumatore OAuth) che consente agli utenti di importare foto dal proprio account Instagram (provider OAuth) che invia un token di accesso temporaneo o una chiave all'app di condivisione foto che scade dopo alcune ore.
SAML ha una varietà di "profili" tra cui scegliere per consentire ad altri utenti di "accedere" al tuo sito. SAML-P o SAML passivo è molto comune e abbastanza semplice da configurare. WS-Trust è simile e anch'esso consente la federazione tra i siti web.
OAuth è progettato per l'autorizzazione. Puoi leggere di più qui:
SAMLserve per l'autenticazione, utilizzato principalmente nello scenario Single Sign-On . OAuthserve per l'autorizzazione delle rappresentazioni delle risorse.
JSON Web Token (JWT) è un'alternativa ai token XML SAML. JWT può essere utilizzato con OAuth
Un buon riferimento è SAML e OAuth: quale dovrei usare?
I termini federazione in realtà significano identità di connessione tra i sistemi. È correlato all'SSO ma non sono esattamente la stessa cosa. Ho trovato questo post sul blog davvero utile in termini di ciò che realmente significa federazione.