WIF 4.5 BootstrapContextセキュリティトークンnull

Question

新しい4.5 WIFものを使用して、Webサイトのユーザーを認証し、MVC WebサイトとWCFサービス間の通信を保護します。

サービス層へのすべての要求に対して同じセキュリティトークンを再利用できるように、ブートストラップコンテキストを保存するようにWebサイトを設定しました。

正常な状態では、すべてのWebサイト要求が認証され、セキュリティトークンがWCFコールを保護するためにコンテキスト経由で利用できるようになっています。

ただし、ウェブサイトのアプリドメインがリセットされた場合（開発中にアプリを作成するなど）、ウェブサイトへのリクエストはすべて認証されますが、SecurityTokenはWCFコールに渡すコンテキストでは使用できなくなります。

プレアプリケーションドメインはセキュリティトークンとSecurityTokenHandlerの値を有し、そしてポストトークン値を有するリセットリセット

SecurityToken 
SecutiryTokenHandler 
Token 
TokenBytes 

：それは4つの有用な特性を有する BootstrapContextデバッグ

。

リセット後にトークンの値を確認すると、生のSAML XMLのように見えるので、おそらく完全なSecutiryTokenを再水和することができますが、これはドキュメントが見つかりません。

SecurityTokenを確実に使用して、トークンXMLを使いこなすのを防ぐために、私ができることはありますか？私はこの動作をcasuesが、私はそれがこのようにする必要がない理由を決定することができませんでした実行パスを見ることができるフレームワークのソースコードで何が起こっているのかを見てdotPeekを使用し

更新

それがどうやって起こるのかを知ることができます。

私はそれを仕事と今私は私が今心配です何トークン

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))); 
} 

を持っていることを確認するために次のコードを使用しようとあきらめた最後に私は、この背後にあるいくつかの推論を逃したです行動と上記の私の修正は、ある時点で爆破するつもりです。

Answer 1

私は同じ問題を偶然見つけました。 トークンがトークンのXML表現を持ち、SecurityTokenがnullであることがわかりました。 これはw3wp.exeを強制終了して再現するのが本当に簡単だと気付きました。

Answer 2

マイクロソフトからClaimsAwareWebFarmサンプルを実装したときに同じ問題が発生しました。このセクションを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> 

ありがとうございました！

Answer 3

私はFedauth Cookieを含むブラウザのCookieを削除することでこの問題を解決しました。もう一度デバッグしたら、すべての必要な値を取得することができました