2012-02-14 7 views
5

Sto tentando di impostare l'autenticazione dei moduli su più server e sottodomini. Ho le chiavi della macchina statici allestiti per ogni applicazione in questo modo:Impostazione dell'autenticazione di moduli permanenti su più server e sottodomini

<system.web> 
    <machineKey validationKey="574...7A7" 
       decryptionKey="2C3...A0D" 
       validation="HMACSHA256" 
       decryption="AES" /> 
</system.web> 

... e la mia autenticazione basata su form è configurato lo stesso per ogni applicazione:

<forms loginUrl="/login" timeout="2880" defaultUrl="/" path="/" name=".SHAREDAUTH" domain="domain.com" protection="All" /> 

Ho anche provato anteponendo il mio dominio con un periodo che ho visto suggerire, ma non ha funzionato.

Questo funziona perfettamente sul mio computer locale con siti separati impostati in IIS per ogni sottodominio. Funziona bene anche sul nostro server di sviluppo, dove tutti i siti risiedono ancora su una singola macchina. Quando si esegue il deployment nel nostro ambiente di gestione temporanea, tuttavia, l'autenticazione tra domini smette di funzionare. In quell'ambiente, ho il sito primario (dove avviene il login) in esecuzione su un singolo server, e il sito secondario (dove la mia autenticazione dovrebbe persistere) in esecuzione su due server con bilanciamento del carico. Tutti funzionano con IIS 7 su Windows 7 (locale) o Server 2008 R2 (dev e staging).

ho verificato che le chiavi della macchina sono uguali codificando una stringa sul sito primario con MachineKey.Encode e decodificare il risultato sul server secondario con MachineKey.Decode. ho anche verificato che il cookie .SHAREDAUTH si passa alla seconda applicazione nella richiesta , sia controllando le intestazioni delle richieste come riportato da Firefox e Chrome, sia agganciando il debugger a Application_BeginRequest e Application_AuthenticateRequest. Posso vedere il cookie durante l'esecuzione di Application_BeginRequest, ma è sparito quando viene chiamato Application_AuthenticateRequest. Da quello che posso raccogliere, ciò sembra significare che la deserializzazione del ticket di autenticazione è fallita, ma non riesco a capire perché ciò potrebbe accadere nell'ambiente multi-server, ma non nell'ambiente server singolo, a parte le diverse chiavi della macchina , che ho già confermato non era il caso.

Ho anche una configurazione personalizzata MembershipProvider e RoleProvider, e quelli funzionano bene indipendentemente su ciascun sito.

Cosa mi manca?

+0

prega non prefisso i tuoi titoli con "ASP.Net C# -" e così via. Ecco a cosa servono i tag. –

+0

Per coloro che hanno lo stesso problema, faccio i suggerimenti in questo post: http://stackoverflow.com/questions/8361323/net-2-0-web-app-authentication-failing-the-ticket-supplied- era-non validi saluti – user1482638

risposta

3

Quindi, dopo un lungo slog ho scoperto MS security bulletin MS11-100, che corregge una vulnerabilità di elevazione dei privilegi nell'autenticazione dei moduli. Sfortunatamente, la patch non è retrocompatibile. È stato applicato ai nostri server con bilanciamento del carico, ma non al server che ospita l'applicazione che ha creato il log-in iniziale, il che significava che i server bilanciati non potevano deserializzare il ticket di autenticazione scritto dal server dell'app.

Per the MS deployment guidance article, se vi trovate in questa situazione, è possibile aggiungere

<add key="aspnet:UseLegacyFormsAuthenticationTicketCompatibility" value="true" /> 

alla sezione appSettings nel web.config per applicazioni su macchine con la patch installati (o alla configurazione a livello di computer). O, meglio ancora, assicurarsi che si sta ospitando società di gestione si applica la patch per tutti i server allo stesso tempo ...

0

Per me funziona l'aggiunta di questa chiavi nelle appSettings:

<add key="aspnet:UseLegacyEncryption" value="true" /> 
    <add key="aspnet:UseLegacyFormsAuthenticationTicketCompatibility" value="true" />