4

HTTPS 経由で ASP.NET Web API コントローラーとして実装されたエンドポイントにアクセスするクライアントがクライアント証明書を提供する場合、その証明書は から入手できますRequest.GetClientCertificate。ただし、.NET 4.5 のセキュリティ モデルと統合されたクレーム ベース モデルの形式で提供される情報を取得することは可能でしょうか?

私がこれを行いたい主な理由は、同じサービスにアクセスするためにさまざまな方法で認証できるようにするために、さまざまなクライアントが必要であるためです。したがって、証明書などの詳細から抽象化することをお勧めします。コントローラーが、現在のユーザーのクレームの出所を気にすることなく、現在のユーザーのクレームに基づいて決定できるようにしたいと考えています。

X509CertificateClaimSet自然な流れのように見えるタイプがあることは知っています：

  1. TLS/SSL 経由で渡されたクライアント証明書は、X509CertificateClaimSetある種のトークン マッピング プロセスを介して表されます (ACS に使用できるフェデレーション プロバイダーによって生成された受信 Cookie が、SessionSecurityTokenHandler
  2. クレーム変換モジュール (要素から派生しClaimsAuthenticationManager、構成された<claimsAuthenticationManager>もの) は、証明書から取得したクレーム セットを検査し、それをトークン固有ではないアプリケーション固有のクレームに変換します。
  3. ハンドラーは、アプリケーション固有のクレームを探します。

X509SecurityTokenHandlerこれを行う必要があるように聞こえるもあります。ただし、私が知る限り、これは送信されるメッセージ内で証明書ベースの認証が処理されるシナリオ向けに設計されています。トランスポート レベル、つまり TLS/SSL ハンドシェイクの一部として。

これを行うために独自のモジュールを作成する必要があるかどうか疑問に思っています。理論的には、AuthenticateRequestイベントを処理し、証明書の要求を調べ、X509CertificateClaimSet存在する場合は証明書から を構築するだけの場合のようです。しかし...その後は？自分で作成してClaimsPrincipal既存のユーザーを置き換えるだけですか? または、発見したクレームをセットに追加する「正しい」方法はありますか? (クライアント証明書は、必ずしもクレームの唯一のソースではありません。私のアプリケーションは、ACS との統合に由来するクレームを既に使用しています。クレームの考えられるすべてのソースが正しくマージされることを保証する標準メカニズムはありますか?)

( SAM SessionAuthenticationModule) は、現在クレーム プリンシパルを提供している ID モデル コンポーネントであり、以前コンテキストにあったものと現在のスレッドのユーザーを置き換えるだけのようです。しかし、それは拡張性を提供するように見えます - その をオーバーライドすると、プリンシパルを構成するオブジェクトValidateSessionTokenのセットが返されます。ClaimsIdentityしたがって、理論的には、それをオーバーライドして、その時点で追加のクレームを追加することができます。

しかし、それが正しい道かどうかはわかりません。私が知る限り、SAM はClaimsAuthenticationManagerクレーム変換を行った後にこれを行います。それとも、クレーム トランスフォーメーションは、ここで使用するのに不適切なモデルですか?

4

2 に答える 2

6

ここを見てください: クライアント証明書の認証とクレームの生成は の一部ですThinktecture.IndetityModel。

于 2013-02-15T21:15:36.030 に答える
1

If I were you, I would externalize the authentication - let some other services provide the authentication and just return SAML tokens with required claims.

This way, in your application you don't really think of certificates, you just expect some concrete claims from federated identity providers.

Then, you implement one of your identity providers to actually accept certificates but the outgoing SAML hides this implementation detail and translates the certificate to a claim set useful to your application.

于 2013-02-15T19:10:03.240 に答える