2010-08-24 12 views

risposta

7

Presumo ti riferisci [il recente rilasciato] ADFS v2?

Sì, ADFS v2 supporta WS-Trust (e WS-Federation) e SAML2 passivo e WIF supporta solo WS-Trust (e WS-Federation) e non SAML2 (né passivo né attivo).

WS-Federation utilizza WS-Trust per eseguire la federazione passiva [basata su browser] ed è in molti modi simile al passivo SAML2 e in molti modi diverso. Una differenza significativa tra WS-Federation e SAML2 passiva è che WS-Federation v1.1 (la nuova versione supportata da ADFS v2) supporta il rilevamento automatico dei metadati. Devi solo fornire un endpoint di metadati (un URL) in WS-Federation, mentre in SAML devi scambiare i documenti dei metadati con un metodo scelto (chiavetta usb, posta elettronica, ecc.).

Non conosco alcuna vulnerabilità di sicurezza effettiva in entrambi i protocolli, ma l'approccio allo scambio di metadati può essere discusso per sempre. L'approccio WS-Federation rende molte cose molto più semplici, come il rollover dei certificati, gli aggiornamenti automatici, il provisioning automatico "gratuito" dei nuovi membri in una federazione, ecc. Tuttavia, la procedura di scambio "manuale" in SAML2 può almeno in teoria essere reso più sicuro.

Per quanto riguarda il motivo per cui il supporto SAML non è incluso in WIF, posso solo speculare. Una supposizione decente potrebbe essere che qualcuno vuole siti che utilizzano WIF di federarsi con ADFS, e non direttamente con qualche altro [terzo] IdP :-)

+0

La crittografia di base è la stessa tra SAML/WS-Fed? Confronto tra SAML2 e WS-Fed meglio di SAML2 in WS-Trust? Che è più un confronto tra mele e mele? – LamonteCristo

+0

Dato che ADFS supporta anche SAMLP, è più probabile che il team WIF non abbia avuto il tempo di aggiungere (e testare) quella funzionalità. WIF ha i punti di estensibilità per aggiungere altri protocolli/formati di token. Anche Microsoft non ha risorse infinite :-) –

+0

@ makerofthings7 Il profilo passivo SAML2 può essere paragonato a WS-Fed, dove il SAML2 attivo può essere paragonato a WS-Trust (almeno ad un livello alto). Per quanto riguarda la crittografia, dipende dalla configurazione del protocollo. In generale, supportano gli stessi algoritmi e, in termini pratici, la piattaforma (.Net, Java, ecc.) Sarà normalmente il fattore limitante, in quanto spesso non supportano tutte le opzioni consentite dalle specifiche. Tuttavia, i protocolli "richiedono" la crittografia in quanto tale, sebbene la crittografia sia una buona idea in alcune situazioni (ad esempio per i token di prova o se la privacy è un problema). –

3

Da The SSO Academy, molto semplice differenza,

Molte persone sono confusi sulle differenze tra SAML, OpenID e OAuth, ma in realtà è molto semplice. Sebbene ci sia una sovrapposizione di , ecco un modo molto semplice di distinguere tra lo tre.

OpenID – single sign-on for consumers 
SAML – single sign-on for enterprise users 
OAuth – API authorization between applications 
3

Una risposta aggiornata e corretta per 2015

  • OpenID-Connect (o OIDC) - il nuovo Single Sign-On protocollo
    • OpenID versione 3, non indietro compatibili ,
    • Costruito sulla tecnologia OAuth
    • Utilizza JWT (per i token, così come le altre tecnologie Web JSON e definizioni)
  • WS-Federation (o WS-Fed) - il vecchio Single Sign-On protocollo
    • Utilizza SAML per la sua gettoni

Definizioni:

  • JWT - definizione JSON per i token di sicurezza (a OAuth e OIDC)
    • Pronunciate come la parola "iota".
  • SAML - schema XML e le definizioni per i token di protezione (in WS-Fed)

OAuth

  • OAuth - è l'insieme delle specifiche per la delega dell'autorizzazione dall'applicazione richiedente (il client) a un servizio di autorizzazione.
    • L'utilizzo autorizzato è dato in una "ambito"
    • Il ambito è costituito da un insieme di sicurezza "affermazioni" e aveva bisogno "risorse"
    • Gli scopi autorizzati vengono restituiti in un JWT Token di risorse
    • I token possono essere restituiti in diversi modi.I più comuni sono:
      • token restituito direttamente: In flusso implicita - utilizzato per il browser basati su applicazioni (JavaScript)
      • token restituito in due fasi, dopo aver ricevuto un "Codice d'accesso" - utilizzato per il server chiamate basate su REST o web API.
    • In alcuni casi all'utente umano viene mostrata un'interfaccia utente per accettare di autorizzare tutte o alcune delle "risorse" richieste.
    • I token possono contenere le informazioni effettive oppure essere un riferimento a un server contenente le informazioni.

OIDC (Open ID Connect)

  • viene avviata richiedendo portata Giuramento con una rivendicazione di tipo OpenID-Connect
  • Il OP - fornitore OIDC è un server OAuth conforme al protocollo OIDC
  • Un Identity Token viene restituito dal OP - il provider OIDC.
    • token di identità contengono informazioni (sinistri) sull'utente
    • In alcuni casi l'utente umano sarà mostrato un'interfaccia utente per autorizzare alcune o tutte le informazioni e le risorse richieste.

Vedi Travis Spenscer's OAuth and OIDC article - sua una lettura facile.

Se non ci sono correzioni a ciò, contrassegnarlo come risposta. Grazie.