5

複数の WCF サービスを呼び出す asp.net Web アプリケーションがあります。Web アプリは www.mydomain.com にあり、サービスは services.mydomain.com にあります。それらは同じサーバーからホストされています。

トランスポート セキュリティ (https) と Windows 認証を使用するサービスに、セキュリティで保護されたエンドポイント (bassicHttpBindings) を追加しました。

<binding name="WindowsSecuredBinding">
  <security mode="Transport">
    <transport clientCredentialType="Windows" />
  </security>
</binding>

これらの新しい安全なエンドポイントを使用するようにクライアント Web アプリを構成しました。次のステップでは、Web アプリにコードを記述して、Windows 認証に合格するためにクライアントの資格情報を設定することを期待していました。驚いたことに、クライアント資格情報を設定せずにサービス呼び出しが成功しています。Web アプリが実行されているアカウントを送信しているに違いないと思いますが、それを確認する方法がわかりません。他のシナリオでは、クライアント資格情報に暗黙的なデフォルトがないことがわかったと思います。

だから私は2つの質問があります：

  1. 認証はどのように成功していますか? アプリを実行するユーザー、ブラウザー ユーザーの資格情報、資格情報なしで送信しますか?
  2. 認証プロセスをデバッグ/ログ/トレースするにはどうすればよいですか? セキュリティを検証できるように、少なくとも認証されているユーザー名を確認したいと思います。
4

1 に答える 1

3
  1. サーバー側とクライアント側にある現在の構成では、クライアントは実行中のクレジットを送信しています。資格情報の種類が Windows に設定されているため、ドメインにいる場合はセキュリティ ネゴシエーションで Kerberos がチェックインされ、ワー​​クグループ環境の場合は NTLM にチェックインされます。(詳細については、こちらを参照してください。 )
  2. 認証プロセスをデバッグするために、WCF には有効にできる監査機能があります。監査を追加する手順については、こちらを参照してください。

MSDN の監査ページの重要な部分は次のとおりです。

<behaviors>
 <behavior name="myAuditBehavior">
  <serviceSecurityAudit auditLogLocation="Application"
    suppressAuditFailure="false" 
    serviceAuthorizationAuditLevel="None" 
    messageAuthenticationAuditLevel="SuccessOrFailure" />
 </behavior>
</behaviors>

サービスに動作を追加します。

<service type="[Your service type here]" behaviorConfiguration="myAuditBehavior">

監査を有効にすると、すべての認証アクティビティ (そのように構成した場合は成功と失敗) を確認できます。これにより、セキュリティが希望どおりに設定されていることを確認できます。

ASP.NET Web アプリを使用しているユーザーの資格情報を渡す機能 (これは偽装と呼ばれます) が必要な場合は、msdn のドキュメントがこのページ「WCF による委任と偽装」にあります。

于 2012-10-03T17:20:50.287 に答える