Modelli Single Sign-On per un ambiente misto

1

Non sono del tutto sicuro se questo è il sito giusto per questo, ma lo farò un tentativo.

Fondamentalmente, sto esaminando diversi modi di creare un servizio Single Sign-On per un ambiente aziendale esistente. All'interno di questo ambiente, c'è di tutto, dai vecchi sistemi legacy ai nuovi servizi web, tutti in esecuzione su piattaforme diverse.

Non cerco realmente soluzioni specifiche, tanto quanto approcci / strategie di alto livello. Ho trovato una ottima annotazione qui , ma è del 1997, quindi non è esattamente aggiornato. Se si conosce una carta simile, ma più recente, si prega di inviare un link ad essa. In caso contrario, sarei eternamente grato se tu fossi in grado di contribuire con informazioni su modelli più moderni che non sono stati ancora sviluppati. Se hai implementato un tale sistema in un ambiente simile, sarei molto interessato a sapere come lo hai realizzato e perché hai scelto quella strategia specifica.

Se questa domanda si adatta meglio su un altro sito, si prega di lasciare un commento e lo posterò lì invece.

Grazie!

    
posta Tommy Brunn 08.01.2012 - 16:51
fonte

2 risposte

2

Se si tenta di implementare un sistema SSO è necessario distinguere due soluzioni fondamentali fondamentali:

  1. SSO lato server : in questo approccio ogni applicazione server deve utilizzare un sistema di autenticazione centrale come un LDAP o deve fidarsi di qualche tipo di ticket come in Kerberos o SAML o l'autenticazione deve essere eseguita con qualche tipo di certificato .
  2. SSO lato client : in questo approccio devi utilizzare una sorta di software client che automatizza il processo di autenticazione.

Il vantaggio di SSO lato server è che può essere implementato in modo tale da garantire una maggiore sicurezza, come una semplice autenticazione tramite password. Ma ogni server deve essere in grado di unirsi al sistema SSO. In alcuni casi questo è tecnologicamente complicato (SAML per le interfacce utente grafiche diverse dai browser Web) e per le applicazioni legacy potrebbe essere un blocco dello spettacolo.

In queste situazioni devi usare l'SSO lato client dove un certo tipo di software gestisce l'autenticazione inviando credenziali di login e password ai campi di input dell'applicazione legacy. Questo approccio ha una vulnerabilità di phishing, perché è difficile per il client fidarsi del server, perché una finestra di accesso può essere identificata solo da un qualche tipo di titolo della finestra che può essere facilmente violato su ogni sistema di finestre.

Regola empirica: l'SSO in reti eterogenee è complicato e molto costoso.

    
risposta data 09.01.2012 - 11:50
fonte
2

Provare a migrare applicazioni legacy su un sistema SSO è molto difficile. Anche solo la creazione di nuove applicazioni standard per SSO può essere quasi impossibile.

Un'opzione più realizzabile (che apre la strada a una vera implementazione SSO, e quindi dovrebbe almeno essere considerata un prerequisito) è l'uso di un sistema di autenticazione / account consolidato: i tuoi utenti dovrebbero avere un singolo ID utente e un password singola per accedere a più servizi.

LDAP è la scelta più ovvia per questo. Questo non vuol dire che non sarà un lavoro duro - anche a partire da qualcosa come GoSA o MS-Active Directory dovrai comunque creare un modello utente consolidato e probabilmente dovrai adattare lo schema predefinito in una certa misura.

    
risposta data 09.01.2012 - 13:59
fonte

Leggi altre domande sui tag