Mi è capitato di dover implementare un sistema di SSO per un cliente. I requisiti erano divertenti, perché alle applicazioni (asp classico e aspnet) dovevano poter accedere sia utenti in LAN con autenticazione AD integrata, sia utenti esterni che però accedevano con autenticazione applicativa in uno dei siti della rete, sia utenti provenienti da un portale esterno, senza autenticazione "apparente", ovvero essendosi autenticati sul portale esterno, non dovevano vedere altre richieste di password.
Il tutto è stato risolto, come diceva andrea, con un web service che da un lato produce un token criptato, collegato all'applicazione desiderata, con scadenza temporale, e dall'altro fornisce delle API per permettere alle applicazioni di verificare se un dato token è valido per quell'ora, quell'applicazione e in alcuni casi per quell'utente.
Le applicazioni di entrata (e solo loro) richiedono il token nel momento in cui l'utente vuole accedere ad un'altra applicazione. Questo token è passato nella richiesta di accesso, e l'applicazione target fa entrare l'utente dopo aver controllato la validità del token e i diritti a questo associati.
Per problemi di NAT non si è potuto legare il token all'ip di partenza dell'utente, ma ragionandoci sopra, utilizzando https e password challenge-response e regole sulla provenienza delle chiamate al WS, l'applicazione è ragionevolmente sicura e funziona correttamente.