2

Windows Azure クラウドに移行したい既存の Web アプリケーションは、(post)authenticaterequest イベントのどこかで次の方法でユーザーを認証します。

IPrincipal current = Thread.CurrentPrincipal;
if (current != null && ((IClaimsIdentity)current.Identity).Claims.Count > 0)
{
    IPrincipal result =  AuthManager.CreateGenericPrincipal(current.Identity);
    HttpContext.Current.User = result;
    Thread.CurrentPrincipal = result;
}

CreateGenericPrincipal メソッドは、xml ファイルで claimidentity のロールを検索し、そのロールを使用して新しい GenericPrincipal を作成します。認証が必要なページは実行するだけです

IPrincipal p = Thread.CurrentPrincipal;
p.IsInRole("rolesFromXml");

通常の IIS ホスティングと大きな違いはないため、これは 1 つの Webrole インスタンスで問題なく機能します。しかし、2 つ、3 つ、または 5 つのインスタンスで動作しますか? Azure ロードバランサーは「スティッキー」ではなく、アプリケーションの使用中にユーザーが別のインスタンスに転送される可能性があります。Thread.CurrentPrincipal がまだ道のりであるかどうかはわかりません。

ここではクレームベース ID を使用します。ユーザーが初めてページにアクセスすると、セキュリティ トークン サービスに転送されます。今まで、これは 1 回だけです。複数のインスタンスを使用しているときにそれが数回発生すると面倒です..

ありがとう！

4

2 に答える 2

2

通常、一度だけ転送され、リダイレクト ダンス (パッシブ リダイレクト) が発生し、トークンを取得します。通常、トークンは暗号化された形式で Cookie にキャッシュされます。したがって、後続のリクエストはリダイレクト ダンスを行いません。

ここでの課題は、Cookie が暗号化されているため、Web ファーム内のすべてのサーバーが解読するための暗号化キーを持っている必要があることです。初期状態では、WIF はデフォルトで DPAPI に設定されているため、問題が発生します。このタイプの暗号化は、マシンごとに意図的に異なります。それは雲の中で壊れます。

必要なことは、展開の一部としてサービス証明書をアップロードし、Cookie の暗号化方法を webfarm に適したものに変更することです。魔法のコードは次のとおりです。

private void OnServiceConfigurationCreated(object sender, 
    ServiceConfigurationCreatedEventArgs e)
{
    var sessionTransforms =
        new List<CookieTransform>(
            new CookieTransform[] 
            {
                new DeflateCookieTransform(), 
                new RsaEncryptionCookieTransform(
                  e.ServiceConfiguration.ServiceCertificate),
                new RsaSignatureCookieTransform(
                  e.ServiceConfiguration.ServiceCertificate)  
            });
    var sessionHandler = new 
     SessionSecurityTokenHandler(sessionTransforms.AsReadOnly());
    e.ServiceConfiguration.SecurityTokenHandlers.AddOrReplace(
        sessionHandler);
}

これにより、セキュリティ トークン ハンドラーが、インストールされた証明書から派生したキー マテリアルで RSA 暗号化を使用するように設定されます。

このサンプル アプリケーションには、問題と解決策を示す詳細と情報が記載されています。

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

追加編集:

ASP.NET には、WIF が構成されているパイプラインがあります。認証イベントをフックし、Cookie からトークンを取得して IPrincipal を構築し、後続のコードがそれをコンテキスト内に持つようにします。通常、STS を使用する場合、プリンシパルを自分で構築することはありません。代わりに、プリンシパルを変更する必要がある場合は、WIF のパイプラインにプラグインし、追加のクレームを「ロール」クレーム (実際には URI 名前空間) に挿入します。次に、WIF はこれらのクレームを使用して、ロールなどを含む ClaimsPrincipal を構築し、機能するもの (IsInRole、web.config auth など) を作成します。

可能であれば、ロールをクレームとしてトークンに含めることをお勧めします。これはかなり長い議論ですが、意味のあるコンテキストに対するクレームの「正規化」に関するものです。IP-STS から得られるクレームは独自の用語であり、アプリケーションにとっては何の意味もない可能性があることに注意してください。たとえば、Adatum\Managers グループに属しているという顧客からのクレームを受け取る場合があります。それは私のアプリケーションにとってはまったく意味がないので、私が通常行うことは、そのトークンをアプリが理解できるものに交換し、その過程でクレーム マッピング (つまり、Adatum\Managers --> MyApplicationAdminRole) によってクレームを変換または正規化することです。Windows Azure ACS サービスは、これを行うのに非常に適しています (異なる IP からのクレームを正規化します)。

ここで一般的なパターンを取得するには、これに関するVittorio の本を読むことをお勧めします。

Eugenio のメモ: @dunnry が書いたものに追加します。これはすべて正しいです。Relying Party (Web アプリ) でクレーム セットを拡張するための適切な拡張ポイントは、ClaimsAuthenticationManagerを使用することです。このタイプのドキュメントはこちらです。そのページにはサンプルへのポインタがあります。そのクラスでは、XML ファイルからロールを読み取り、それらを ClaimsIdentity に追加します。アプリの残りの部分は、クレームなどについて心配しません (特に、あなたの場合のようにロールを使用している場合)。Cookie 暗号化の RSA 構成は、ロード バランサーの問題を解決します。

于 2011-10-25T15:06:18.607 に答える
1

私の投稿を見てください、私はちょうど同じことをしました。

http://therubblecoder.wordpress.com/2011/10/25/wif-and-load-balancing-with-mvc-3/

基本的に、クレーム トークンはどのクラスター ノードでも使用できる必要があるため、sessiontokenhandler で証明書を使用すると、特定のノードがインスタンスに固有の方法でトークンを処理するのを防ぐことができます。

config の microsoft.identity 要素には、次のような要素が必要です。

<serviceCertificate>
  <certificateReference x509FindType="FindByThumbprint"    findValue="****THUMBPRINT*****" storeLocation="LocalMachine"  storeName="My" />
</serviceCertificate>

アプリケーション プールもこれにアクセスする必要があります。そうしないと、拇印で証明書を見つけることができません。

上記のコードは、トークンを処理するときにこの証明書を使用します。この設定がないと、null 参照例外が発生します。

于 2011-10-25T14:16:39.570 に答える