Strategia per il Single Sign-On con applicazioni legacy

Question

Mi chiedo quali strategie utilizzano le persone per ridurre l'accesso con le applicazioni legacy e quanto le hanno trovate efficaci?

Disponiamo di un'intranet basata su ASP.Net e possediamo molte delle applicazioni legacy, ma non tutte.Disponiamo anche di BizTalk e stiamo valutando l'utilizzo del suo motore SSO.

Answer 1

Un buon compromesso tra impegno/rilavorazione e la comodità del Single Sign-On è continuare a mantenere un elenco di utenti, privilegi, ruoli ecc. nell'app legacy.Apporta le modifiche necessarie per accedere automaticamente all'utente nella tua applicazione in base al suo account utente (solitamente il suo account Windows o di rete).

Attualmente sto eseguendo un paio di applicazioni che utilizzano questo metodo di accesso e le fa sembrare più integrate anche se non lo sono.

Un altro vantaggio che abbiamo riscontrato è che impedisce alle persone di condividere password con applicazioni legacy.Sono molto meno propensi a distribuire una password di amministratore che consenta ad altri di accedere anche alla propria posta elettronica o ai dettagli del libro paga!

Answer 2

Archiviazione di identità multiple per applicazione?Potrebbe non essere una soluzione Single Sign-On, ma hai provato a cercare qualcosa che sia una soluzione più mirata come MS Identity Lifecycle Manager?Semplificherà la sincronizzazione dell'identità tra le applicazioni ed è anche collegabile, il che significa che puoi collegare il tuo codice per eseguire la sincronizzazione tra sistemi diversi.Pertanto, se modifichi le informazioni sull'identità (ad es.login info) nel portale ILM, è possibile propagarli ai diversi sistemi.Stessa cosa per il provisioning e il deprovisioning dell'identità.Unico punto di ingresso.
Suppongo che tu possa usare biztalk anche per cose simili.

Per quanto riguarda la soluzione Single Sign-On in cui è sufficiente effettuare l'accesso una volta e non è necessario accedere nuovamente a diverse applicazioni.Devo ancora trovarne uno.

Suppongo che se le tue app legacy abbiano un modulo di provider di identità collegabile, sia fattibile, il che significa che puoi personalizzare il sistema di accesso per collegarti alla tua unica fonte di verità dell'identità, qualunque cosa accada.

Answer 3

Abbiamo fatto due cose con gli account legacy.(app legacy basate sul Web)

Per prima cosa abbiamo mappato gli account legacy sui relativi account di accesso al sistema (in esecuzione in una Active Directory di Windows).

Una schermata di accesso frontale è stata quindi applicata sopra le app legacy (basate sul Web), ciò richiederebbe l'accesso ad AD, che quindi invertirebbe la mappatura all'account di accesso delle applicazioni legacy e assegnerebbe i diritti appropriati all'utente, utilizzando la versione legacy modello di sicurezza dei sistemi.L'utente ha ricevuto un token per la sessione che gli ha mantenuto le porte aperte.

Questo ci ha dato il vantaggio di non dover aggiornare le app legacy (ad esempio, ciò che accadrebbe è che l'app x avesse solo numeri per l'ID e l'utente utilizza un accesso a Windows (alfanumerico) e ottenere anche uno pseudo accesso singolo dal punto di vista del cliente.

L'altra opzione che aveva senso era che nella nuova schermata di accesso avrebbe controllato più repository di sicurezza, quindi anche se l'utente non avesse deciso di utilizzare l'accesso a Windows, avrebbe comunque potuto accedere con il nome dell'account legacy.Ovviamente questo ha alcuni effetti collaterali, ma può anche aiutare ad alleviare il dolore della transizione che gli utenti finali a volte avvertono nel passaggio da un sistema all'altro.

Ci sono anche programmi come Accesso singolo di Citrix XenApp che adottano un approccio totalmente diverso alla questione.

Answer 4

Oltre ai punti di Jimmy sull'utilizzo di ILM, questo particolare sistema consente l'integrazione con il servizio AD PCNS (Password Change Notification Service), che può essere utilizzato con ILM (ILM "vede" l'evento di modifica della password e può pubblicarlo su altre applicazioni che lo utilizzano / services) per garantire almeno che quando la password di un utente cambia in un sistema, si rifletta anche negli altri.