Domanda:
Qual è la differenza tra Accesso federato e Single Sign-On?
c card
2012-04-16 10:12:56 UTC
view on stackexchange narkive permalink

Qual è la differenza tra i metodi di autenticazione Accesso federato e Single Sign On?

Sette risposte:
Mark Beadles
2012-04-17 00:27:28 UTC
view on stackexchange narkive permalink

Single Sign-on (SSO) consente agli utenti di accedere a più servizi con un unico accesso.

Il termine è in realtà un piccolo ambiguo. A volte si usa per indicare che (1) l'utente deve fornire le credenziali solo una volta per sessione, quindi ottiene l'accesso a più servizi senza dover eseguire nuovamente l'accesso durante quella sessione. Ma a volte è usato per significare (2) semplicemente che le stesse credenziali vengono utilizzate per più servizi; l'utente potrebbe dover accedere più volte, ma sono sempre le stesse credenziali. Quindi attenzione, tutti gli SSO non sono gli stessi in questo senso. Molte persone (me compreso) considerano solo il primo caso SSO "vero".

Federated Identity (FID) si riferisce a dove l'utente memorizza le proprie credenziali. In alternativa, FID può essere visto come un modo per connettere insieme i sistemi di gestione delle identità. In FID, le credenziali di un utente vengono sempre archiviate con l'organizzazione "home" (il "provider di identità"). Quando l'utente accede a un servizio, invece di fornire le credenziali al fornitore di servizi, il fornitore di servizi si fida del fornitore di identità per convalidare le credenziali. Quindi l'utente non fornisce mai le credenziali direttamente a nessuno tranne che al provider di identità.

FID e SSO sono diversi, ma molto spesso vengono usati insieme. La maggior parte dei sistemi FID fornisce una sorta di SSO. E molti sistemi SSO sono implementati sotto il cofano come FID. Ma non devono essere fatti in questo modo; Anche FID e SSO possono essere completamente separati.

Grazie. Questo ha molto più senso per me ora (credo), ma solo dopo la tua interpretazione, poiché la pagina di wikipedia della FID non stava risolvendo la differenza per me. Quindi, BrowserID è SSO e l'accesso a stackoverflow con un account Google è FID?
Sarebbe giusto pensare ai servizi di Google (Gmail, Drive, YouTube, ecc.) Come un esempio canonico di SSO e un pulsante "Accedi con Facebook" su un sito web casuale come un esempio canonico di FID?
È così che lo interpreterei.Accesso Google e Accesso Facebook sono servizi di identità federati che forniscono l'autenticazione senza rivelare le informazioni di accesso al servizio a cui si accede.
Lucas Kauffman
2012-04-16 10:49:42 UTC
view on stackexchange narkive permalink

SSO consente a una singola credenziale di autenticazione - ID utente e password, smart card, token password monouso o dispositivo biometrico - di accedere a più o diversi sistemi all'interno di una singola organizzazione. Un sistema di gestione delle identità federato fornisce un unico accesso a più sistemi in diverse aziende.

fonte

unnikuttan
2015-10-27 23:59:30 UTC
view on stackexchange narkive permalink

Web SSO, può essere definito come "è necessario inserire le proprie credenziali una volta e se si trovano nello stesso provider di cookie, non è necessario reinserire il nome utente e la password se si trovano anche nello stesso provider di cookie" ad esempio: Gmail- -> google

SSO federato può essere definito come "ti potrebbe essere chiesto di utilizzare un'applicazione che si trova sotto un'impresa / rete diversa o ad esempio un'altra organizzazione, in questo caso abbiamo bisogno di una federazione, dove se tu desidera utilizzare il servizio di un prodotto web di un'altra azienda, ad es. servizio ora, quindi fungerà da fornitore di identità [IDP] e sarà il fornitore di servizi [SP] "

Ya Hai
2016-01-12 18:49:12 UTC
view on stackexchange narkive permalink

La federazione è un principio mentre SSO è solo un caso d'uso. SSO può significare cose diverse per persone diverse, ma il significato comune è "utilizzare la stessa credenziale per accedere una volta per sessione, che è ampiamente utilizzata in molte aziende a livello locale". Il principio della federazione viene a risolvere il problema di molte imprese indipendenti che vogliono consentire ai propri utenti di accedere per utilizzare tutti i loro servizi, in un'altra parola registrando oltre confine. Da questa esigenza nasce quello che oggi viene chiamato Federated SSO che è un tipo di single sign on.

bbsimonbb
2016-03-17 14:29:56 UTC
view on stackexchange narkive permalink

Il Single Sign-On non dovrebbe aver bisogno di spiegazioni! È una qualità di un sistema IT. Effettui l'accesso una volta e per tutta la durata della sessione, le decisioni di autorizzazione possono essere prese senza che tu debba autenticarti nuovamente.

Tutta la sottigliezza arriva quando desideri allargare il perimetro delle risorse coperte dal Single Sign-On. Sulle macchine locali e sui domini intranet le battaglie sono state vinte molto tempo fa che ci siamo dimenticati, ma il Single Sign-On doveva essere implementato nei sistemi operativi e nei controller di dominio.

La battaglia odierna è fornire il Single Sign-On a tutti i siti Web del mondo e l'ID federato è uno dei due modelli di architettura utilizzati per risolvere questo problema. L'altro, più semplice e prevalente, è l'id delegato. La differenza è spiegata qui Se, come server di autorizzazione, sei felice di accettare un token di identità sapendo solo che è, ad esempio, un token OpenId, senza preoccuparti di chi lo ha generato, allora sei facendo ID federato.

Johnlennon
2019-02-11 10:40:07 UTC
view on stackexchange narkive permalink

Single Sign On (SSO): il Single Sign On è una caratteristica di un meccanismo di autenticazione che si riferisce all'identità dell'utente utilizzata per fornire l'accesso a più provider di servizi.

SSO consente un unico processo di autenticazione ( gestito da un singolo provider di identità o altro meccanismo di autenticazione) da utilizzare su più sistemi all'interno di una singola organizzazione o tra più organizzazioni.

Federated SSO: Federated Identity Management è un disciplina di IAM, ma in genere gli stessi team sono coinvolti nel supporto. La federazione è un tipo di SSO in cui gli attori si estendono su più organizzazioni e domini di sicurezza.

La federazione è la relazione di fiducia che esiste tra queste organizzazioni; riguarda la posizione in cui le credenziali dell'utente vengono effettivamente archiviate e il modo in cui terze parti affidabili possono autenticarsi in base a tali credenziali senza vederle effettivamente.

La relazione di federazione può essere realizzata tramite uno dei diversi protocolli tra cui (ma, non limitato a):

  • SAML1.1

  • SAML2

  • WS-Federation

  • OAuth2

  • OpenID Connect

  • WS- Fiducia

  • Vari protocolli proprietari

Puoi anche controllare l ' elenco di implementazioni single sign on

Devi rivelare la tua relazione con il collegamento fornito.
guest2013
2013-10-31 18:30:06 UTC
view on stackexchange narkive permalink

FID ricerca in più parti che si affidano allo stesso sistema di gestione dell'identità, ad esempio puoi accedere a Flicar dal tuo account Yahoo; qui Flicar dipende da Yahoo e si fida di esso per autorizzarti. In FID deve esserci una terza parte (provider di identità) accanto all'utente e al fornitore di servizi.

SSO sta cercando come accedere a multi servizi tramite accesso singolo. ad esempio se accedi al tuo account hotmail sarai in grado di accedere al servizio SkyDrive senza bisogno di accedere di nuovo.

Non ho un esempio ma penso che tu possa farlo accedi tramite SSO a molti servizi utilizzando FID oppure puoi accedere tramite SSO senza utilizzare FID.

Sebbene sia mal formulato, questo non è significativamente diverso dalla risposta meglio descritta da Mark.L'unico problema che vedo è che implica che gli accessi federati siano con servizi pubblici, ma possono anche avvenire attraverso server non privati / aziendali, ecc. Anche l'SSO può essere implementato con FID.Non merita di più, ma non dovrebbe essere un -1.


Questa domanda e risposta è stata tradotta automaticamente dalla lingua inglese. Il contenuto originale è disponibile su stackexchange, che ringraziamo per la licenza cc by-sa 3.0 con cui è distribuito.
Loading...