SSO con CAS o OAuth?

Mi chiedo se dovrei usare il protocollo CAS o OAuth + un provider di autenticazione per il single sign-on.

Scenario di esempio:

1. Un utente tenta di accedere a una risorsa protetta, ma non è autenticato.
2. L'applicazione reindirizza l'utente al server SSO.
3. Se viene autenticato, l'utente ottiene un token dal server SSO.
4. L'SSO reindirizza all'applicazione originale.
5. L'applicazione originale controlla il token sul server SSO.
6. Se il token è ok, l'accesso sarà consentito e l'applicazione conosce l'id utente.
7. L'utente esegue un logout e viene disconnesso da tutte le applicazioni connesse contemporaneamente (single logout).

Per quanto ho capito, è esattamente per questo che è stato inventato CAS. I client CAS devono implementare il protocollo CAS per utilizzare il servizio di autenticazione. Ora mi chiedo di usare CAS o OAuth sul sito client (consumatore). OAuth è un sostituto per quella parte di CAS? OAuth come nuovo standard di fatto dovrebbe essere preferito? Esiste una sostituzione facile da usare (non Sun OpenSSO!) Per la parte di autenticazione di CAS che supporta diversi metodi come nome utente / password, OpenID, certificati TLS ...?

Contesto:

• Applicazioni diverse dovrebbero fare affidamento sull'autenticazione del server SSO e dovrebbero utilizzare qualcosa di simile a una sessione.
• Le applicazioni possono essere applicazioni Web GUI o serivces (REST).
• Il server SSO deve fornire un ID utente, necessario per ottenere ulteriori informazioni sull'utente come ruoli, e-mail e così via da un archivio informazioni utente centrale.
• La disconnessione singola dovrebbe essere possibile.
• La maggior parte dei client sono scritti in Java o PHP.

Ho appena scoperto WRAP , che potrebbe diventare il successore di OAuth. È un nuovo protocollo specificato da Microsoft, Google e Yahoo.

appendice

Ho imparato che OAuth non è stato progettato per l'autenticazione, anche se potrebbe essere utilizzato per implementare SSO, ma solo insieme a un servizio SSO come OpenID.

OpenID mi sembra il "nuovo CAS". CAS ha alcune funzionalità mancate da OpenID (come il single logout), ma non dovrebbe essere difficile aggiungere le parti mancanti in un particolare scenario. Penso che OpenID abbia un'ampia accettazione ed è meglio integrare OpenID nelle applicazioni o nei server delle applicazioni. So che CAS supporta anche OpenID, ma penso che CAS sia superfluo con OpenID.

OpenID non è un "successore" o un "sostituto" di CAS, sono diversi, nell'intento e nell'implementazione.

CAS centralizza autenticazione. Usalo se vuoi che tutte le tue applicazioni (probabilmente interne) chiedano agli utenti di accedere a un singolo server (tutte le applicazioni sono configurate per puntare a un singolo server CAS).

OpenID decentralizza autenticazione. Usalo se vuoi che la tua applicazione accetti l'accesso degli utenti a qualunque servizio di autenticazione desideri (l'utente fornisce l'indirizzo del server OpenID - in effetti, il 'nome utente' è l'URL del server).

Nessuna delle precedenti autorizzazioni di gestione (senza estensioni e / o personalizzazioni).

OAuth gestisce l'autorizzazione, ma non sostituisce la tradizionale "tabella USER_ROLES" (accesso utente). Gestisce l'autorizzazione per terze parti.

Ad esempio, vuoi che la tua applicazione si integri con Twitter: un utente potrebbe consentirgli di twittare automaticamente quando aggiorna i propri dati o pubblica nuovi contenuti. Vuoi accedere ad alcuni servizi o risorse di terze parti per conto di un utente, senza ottenere la sua password (che ovviamente non è sicura per l'utente). L'applicazione richiede l'accesso a Twitter, l' utente lo autorizza (tramite Twitter) e quindi l'app può avere accesso.

Quindi, OAuth non riguarda Single Sign-On (né un sostituto del protocollo CAS). Non si tratta di controllare ciò a cui l'utente può accedere. Si tratta di lasciare che l' utente di controllare come il loro risorse possono accedere alle terze parti. Due casi d'uso molto diversi.

Per il contesto che hai descritto, CAS è probabilmente la scelta giusta.

[Aggiornato]

Detto questo, puoi implementare SSO con OAuth, se consideri l'identità dell'utente come una risorsa protetta. Questo è ciò che fanno 'Registrati con GitHub' e simili, fondamentalmente. Probabilmente non l'intento originale del protocollo, ma può essere fatto. Se controlli il server OAuth e limiti le app per autenticarti solo con esso, questo è SSO.

Non esiste un modo standard per forzare il logout (CAS ha questa funzione).

Tendo a pensarlo in questo modo:

Utilizzare CAS se si controlla / si possiede il sistema di autenticazione utente e è necessario supportare un set eterogeneo di server e app che richiedono l'autenticazione centralizzata.

Usa OAuth se desideri supportare l'autenticazione utente da sistemi che non possiedi / supportano (ad esempio Google, Facebook, ecc.).

OpenID è un protocollo di autenticazione, OAuth e OAuth WRAP sono protocolli di autorizzazione. Possono essere combinati con l' estensione OpenID ibrida .

Preferirei fortemente vedere le persone svilupparsi al di sopra di standard che hanno molto slancio (più supporto disponibile, più facile coinvolgere terze parti), anche se non si adattano perfettamente all'applicazione a portata di mano. In questo caso, OAuth ha lo slancio, non CAS. Dovresti essere in grado di fare tutto o almeno quasi tutto ciò che devi fare con OAuth. In un secondo momento in futuro, OAuth WRAP dovrebbe semplificare ulteriormente le cose (rende alcuni compromessi utili usando un token al portatore e spingendo la crittografia verso il livello del protocollo), ma è ancora agli inizi e, nel frattempo, OAuth probabilmente farà bene il lavoro.

In definitiva, se scegli di utilizzare OpenID e OAuth, ci sono più librerie per più lingue disponibili per te e per chiunque abbia bisogno di integrarsi con il sistema. Hai anche molti più occhi che guardano i protocolli, assicurandoti che siano davvero sicuri come dovrebbero.

Per me, la vera differenza tra SSO e OAuth è la concessione, non l'autenticazione perché un server che implementa OAuth ha ovviamente autenticazione (devi accedere a google, openId o facebook affinché OAuth possa avvenire con l'app client)

In SSO, un utente esperto / amministratore di sistema concede in anticipo all'utente finale l'accesso a un'applicazione sull'app SSO In OAuth, l'utente finale concede l'accesso dell'applicazione ai suoi "dati" sull'app "OAuth"

Non vedo perché il protocollo OAuth non possa essere usato come parte di un server SSO. Basta estrarre la schermata di concessione dal flusso e lasciare che il server OAuth cerchi la concessione dal db di supporto.

Vecchio post, ma questo potrebbe essere utile:

CAS 3.5 supporterà oAuth come client e server. Vedi: https://wiki.jasig.org/display/CASUM/OAuth