2012-11-22 13 views
24

Sto utilizzando la nuova versione di WIF 4.5 per autenticare gli utenti del sito Web e proteggere la comunicazione tra il sito Web MVC ei servizi WCF.WIF 4.5 Token di sicurezza BootstrapContext null

Ho il sito configurato per salvare il contesto di bootstrap in modo da poter riutilizzare lo stesso token di sicurezza per tutte le richieste al livello di servizio.

In condizioni normali tutto funziona correttamente con ogni richiesta di sito Web autenticata e il SecurityToken reso disponibile tramite il contesto per proteggere le chiamate WCF.

Se il dominio delle app dei siti Web viene reimpostato (ad esempio, la creazione dell'app durante lo sviluppo) qualsiasi richiesta al sito Web verrà comunque autenticata ma SecurityToken non è più disponibile nel contesto per passare alle chiamate WCF.

Debug del BootstrapContext ha 4 proprietà utili:

SecurityToken 
SecutiryTokenHandler 
Token 
TokenBytes 

dominio pre-app ripristinare SecurityToken e SecurityTokenHandler hanno valori, e post token reimpostazione ha un valore.

Eyeballing del valore per Token dopo il reset sembra che questo sia l'XML SAML non elaborato, quindi posso presumibilmente reidratare un SecutiryToken completo da esso, ma questo sembra un comportamento strano di cui non riesco a trovare alcuna documentazione.

Qualche idea su cosa potrei fare per garantire che SecurityToken sia sempre disponibile per salvarmi con l'XML token?

Aggiornamento

Utilizzando dotPeek a guardare a ciò che sta succedendo nel codice sorgente framework ho potuto vedere il percorso di esecuzione che casues questo comportamento, ma non ho potuto stabilire alcuna ragione per cui aveva bisogno di essere in questo modo e come potrebbe essere stato aggiunto.

Alla fine ho rinunciato a lavorare fuori e ora utilizzare il seguente pezzo di codice per garantire che ho un gettone

if (context.SecurityToken != null) 
{ 
    token = context.SecurityToken; 
} 
else if (context.Token.IsNotEmpty()) 
{ 
    var handlers = FederatedAuthentication.FederationConfiguration.IdentityConfiguration.SecurityTokenHandlers; 
    token = handlers.ReadToken(new XmlTextReader(new StringReader(context.Token))); 
} 

ciò che sono ora preoccupa è che ho perso un po 'di ragionamento dietro questo comportamento e la mia correzione di cui sopra sta per saltare in aria ad un certo punto.

+0

OWIN non stesso WIF? – Kiquenet

risposta

4

Mi sono imbattuto nello stesso problema. Vedo il token avere la rappresentazione xml del token e il SecurityToken nullo. Ho anche notato che questo è veramente facile da riprodurre uccidendo w3wp.exe.

+0

+1 per uccidere i passaggi di riproduzione di w3wp.exe – Josh

0

Ho avuto lo stesso problema quando ho implementato l'esempio ClaimsAwareWebFarm da microsoft. Il problema sorge quando si aggiunge questa sezione per web.config:

<caches> 
    <sessionSecurityTokenCache type="CacheLibrary.SharedSessionSecurityTokenCache, CacheLibrary"> 
     <!--cacheServiceAddress points to the centralized session security token cache service running in the web farm.--> 
     <cacheServiceAddress url="http://localhost/SecurityTokenCacheService/SessionSecurityTokenCacheService.svc" /> 
    </sessionSecurityTokenCache> 
    </caches> 

Grazie Matt per questa soluzione!

1

Ho risolto il problema eliminando il cookie del browser incluso il cookie Fedauth. Una volta eseguito il debug di nuovo, sono stato in grado di ottenere tutti i valori necessari