ASP.NET MVC 2 e autenticazione tramite WIF (Windows Identity Foundation)

Question

Sono disponibili esempi decenti di quanto segue:

Guardare attraverso l'SDK WIF, sono disponibili esempi di utilizzo di WIF insieme ad ASP.NET utilizzando WSFederationAuthenticationModule (FAM) per reindirizzare a un sito ASP.NET pelle sottile oltre a un Security Token Service (STS) che l'utente utilizza per autenticarsi (fornendo un nome utente e una password).

Se comprendo correttamente WIF e l'accesso basato sulle attestazioni, vorrei che la mia applicazione fornisse una propria schermata di accesso in cui gli utenti forniscono nome utente e password e consentono di delegare a un servizio token di sicurezza per l'autenticazione, inviando i dettagli di accesso a un endpoint tramite uno standard di sicurezza (WS-*) e in attesa della restituzione di un token SAML.Idealmente, il SessionAuthenticationModule funzionerebbe secondo gli esempi utilizzati FAM insieme a SessionAuthenticationModule cioè.essere responsabile della ricostruzione del IClaimsPrincipal dal cookie suddiviso in blocchi di sicurezza della sessione e reindirizzamento alla pagina di accesso dell'applicazione quando la sessione di sicurezza scade.

È ciò che descrivo possibile utilizzando FAM E SessionAuthenticationModule con le impostazioni web.config appropriate o devo pensare di scrivere un file HttpModule me stesso per gestire questa cosa?In alternativa, il reindirizzamento a un servizio token di sicurezza del sito Web sottile in cui gli utenti accedono è un approccio de facto in uno scenario di richiedente passivo?

Answer 1

Un esempio di WIF + MVC è disponibile in questo capitolo della "Claims Guida Identità":

http://msdn.microsoft.com/en-us/library /ff359105.aspx

Vi suggerisco di leggere i primi due capitoli di capire tutti i principi di fondo. Questo post del blog copre le specifiche di MVC + WIF:

http://blogs.msdn.com/b/eugeniop/archive/2010/04/03/wif-and-mvc-how-it-works.aspx

Controllo l'esperienza di accesso è perfettamente bene. Si dovrebbe solo distribuire i propri STS (nel dominio, con il look & feel, ecc). Le tue applicazioni sarebbero semplicemente fare affidamento su di esso per AuthN (è per questo che un'applicazione è di solito chiamato "relying party").

Il vantaggio dell'architettura è che AuthN è delegato 1 componente (STS) e non sparsi in molte applicazioni. Ma l'altro (enorme) vantaggio è che è possibile abilitare scenari più sofisticati molto facilmente. Per esempio è possibile ora la federazione con provider di identità di altro ente.

Speranza che aiuta Eugenio

@RisingStar:

Il token (contenente rivendicazioni) può essere opzionalmente criptato (altrimenti sarà crittografata). Ecco perché SSL è sempre raccomandato per le interazioni tra il browser e lo STS.

Si noti che anche se sono in chiaro, la manomissione non è possibile perché il token viene firmato digitalmente.

Answer 2

È una domanda interessante quella che hai posto.So che, per qualsiasi motivo, Microsoft ha pubblicato questo framework "Windows Identity Foundation" senza molta documentazione.Lo so perché mi è stato assegnato il compito di capire come utilizzarlo con un nuovo progetto e integrarlo con l'infrastruttura esistente.Sono mesi che cerco sul web buone informazioni.

Ho adottato un punto di vista leggermente diverso per risolvere il problema che descrivi.

Ho preso un'applicazione di accesso esistente e vi ho integrato il sistema idraulico WIF di Microsoft.Con questo intendo che ho un'applicazione in cui un utente accede.L'applicazione di accesso invia le credenziali fornite dall'utente a un altro server che restituisce l'identità dell'utente (o indica un errore di accesso).

Osservando alcuni esempi di Microsoft, vedo che fanno quanto segue:Costruisci a SignInRequestMessage da una querystring (generata da un'applicazione del componente), costruisci un servizio token di sicurezza da una classe personalizzata e infine chiama FederatedSecurityTokenServiceOperations.ProcessSignInresponse con l'attuale httpcontext.response.Sfortunatamente, non posso spiegarlo bene qui;hai davvero bisogno di guardare gli esempi di codice.

Parte del mio codice è molto simile al codice di esempio.Il punto in cui sarai interessato a implementare gran parte della tua logica è in GetOutputClaimsIdentity.Questa è la funzione che costruisce l'identità delle attestazioni che descrive l'utente che ha effettuato l'accesso.

Ora, ecco cosa penso che tu sia veramente interessato a sapere.Questo è ciò che Microsoft non ti dice nella loro documentazione, per quanto ne so.

Una volta effettuato l'accesso, l'utente viene reindirizzato all'applicazione del componente.Indipendentemente dal funzionamento dell'applicazione di accesso, le classi WIF invieranno una risposta al browser dell'utente che contiene un input HTML "nascosto" contenente il certificato di firma del token e le attestazioni dell'utente.(Le affermazioni saranno in chiaro).Alla fine di questa risposta c'è un reindirizzamento al sito Web del componente utilizzatore.Conosco questa azione solo perché l'ho catturata con "Fiddler"

Una volta tornati al sito Web del componente, le classi WIF gestiranno la risposta (prima che venga eseguito qualsiasi codice).Il certificato verrà convalidato.Per impostazione predefinita, se hai configurato il sito Web del componente con FedUtil.exe (facendo clic su "Aggiungi riferimento STS nell'applicazione del componente da Visual Studio), la classe di Microsoft verificherà l'identificazione personale del certificato.

Infine, il framework WIF imposta i cookie nel browser dell'utente (secondo la mia esperienza, i nomi dei cookie iniziano con "FedAuth") che contengono le affermazioni dell'utente.I cookie non sono leggibili dall'uomo.

Una volta che ciò accade, puoi facoltativamente eseguire operazioni sulle attestazioni dell'utente all'interno del sito Web della componente utilizzando il file ClaimsAuthenticationClass.Qui è dove il tuo codice sta correndo di nuovo.

So che è diverso da quello che descrivi, ma ho questa configurazione funzionante.Spero che aiuti!

p.s.Consulta le altre domande che ho posto su Windows Identity Foundation.

AGGIORNAMENTO:Per rispondere alla domanda nel commento qui sotto:

Una cosa che ho tralasciato è che il reindirizzamento all'applicazione di accesso STS avviene tramite un reindirizzamento con una stringa di query contenente l'URL dell'applicazione a cui l'utente sta accedendo.Questo reindirizzamento avviene automaticamente la prima volta che un utente tenta di accedere a una pagina che richiede l'autenticazione.In alternativa, credo che potresti eseguire il reindirizzamento manualmente con il file WSFederationAuthentication modulo.

Non ho mai provato a farlo, ma se desideri utilizzare una pagina di accesso all'interno dell'applicazione stessa, credo che il framework dovrebbe consentirti di utilizzare quanto segue:

1) Incapsula il tuo codice STS all'interno di una libreria.2) Fai riferimento alla libreria dalla tua applicazione.3) Crea una pagina di accesso all'interno della tua applicazione.Assicurati che tale pagina non richieda l'autenticazione.4) Impostare la proprietà dell'emittente del wsFederation elemento all'interno di Microsoft.IdentityModel sezione del tuo web.config alla pagina di accesso.

Answer 3

Che cosa si vuole fare è un signin attiva. WIF include WSTrustChannel (fabbrica) che consente di comunicare direttamente con il STS e ottenere un token di sicurezza. Se si desidera che il form di login di lavorare in questo modo, è possibile seguire l'esempio "WSTrustChannel" dal WIF 4,0 SDK. Una volta ottenuto il token, il codice seguente prenderà quella pedina e chiamare il gestore WIF per creare una sessione di token e impostare il cookie appropriata:

public void EstablishAuthSession(GenericXmlSecurityToken genericToken)
{
    var handlers = FederatedAuthentication.ServiceConfiguration.SecurityTokenHandlers;            
    var token = handlers.ReadToken(new XmlTextReader(
                                        new StringReader(genericToken.TokenXml.OuterXml)));

    var identity = handlers.ValidateToken(token).First();
    // create session token
    var sessionToken = new SessionSecurityToken(
        ClaimsPrincipal.CreateFromIdentity(identity));
    FederatedAuthentication.SessionAuthenticationModule.WriteSessionTokenToCookie(sessionToken);
}

Una volta fatto questo, il tuo sito dovrebbe comportarsi lo stesso come se fosse avvenuta firma passivo.

Answer 4

È possibile utilizzare il controllo FederatedPassiveSignIn.

Answer 5

Impostazione del cookie in questo modo: FederatedAuthentication.SessionAuthenticationModule.WriteSessionTokenToCookie (sessionToken); lavoro doens't per SSO ad altri domini.

Per biscotto deve essere impostato dai STS non alla RP.