2012-10-03 19 views
5

私はいくつかのWCFサービスを呼び出すasp.net Webアプリケーションを持っています。 Webアプリケーションはwww.mydomain.comにあり、サービスはservices.mydomain.comにあります。それらは同じサーバーからホストされます。明示的に資格情報を設定せずにWCF Windows認証が機能する方法

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

と、これらの新しい安全なエンドポイントを使用するようにクライアントのWebアプリケーションを構成し:

私は、トランスポートセキュリティ(HTTPS)およびWindows authenicationを使用するサービスへのセキュアなエンドポイント(bassicHttpBindings)を追加しました。次のステップでは、Windows認証に合格するためにクライアントの資格情報を設定するために、Webアプリケーションにいくつかのコードを記述することを期待していました。私の驚いたことに、クライアントの資格情報を設定せずにサービスコールが成功しています。私はそれがWebアプリケーションが実行されているアカウントを送信する必要がありますが、確認する方法を知らないと仮定しています。他のシナリオでは、私は暗黙のデフォルトを持たないクライアントの資格情報を見たと思いました。どのように認証が成功している

  1. だから私は2つの質問がありますか?それは、ブラウザのユーザーの資格情報、資格情報の下で実行されているアプリを実行するユーザーを送信しますか?

  2. 認証プロセスをデバッグ/ログ/トレースするにはどうすればよいですか?セキュリティを検証できるように、少なくとも認証されているユーザー名を確認したいと思います。あなたは、サーバーとクライアント側でそれを持っているとして、あなたの現在の構成で
+0

ウィンドウ認証には[Kerberos]が使用されます(http://support.microsoft.com/kb/217098)IIRC。私はそれが現在のアイデンティティを使用していると信じていますが、もしそれが設定可能かどうか、またはすべての細部の仕組みがどうなっているのかはわかりません。 –

答えて

3
  1. は、クライアントは、それがもとで実行されているcreditialsを送信しています。資格情報の種類がWindowsに設定されているため、セキュリティネゴシエーションがドメインにある場合はKerberosで、ワークグループ環境の場合はNTLMでチェックされます。 (More information can be found here.
  2. 認証プロセスをデバッグするには、WCFに監査機能を有効にする必要があります。 Instructions for adding auditing are here

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

    とサービスに動作を追加:

はここ監査MSDNのページから重要な部分だ

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

監査を有効にすると、すべての認可活動を見ることができます(成功した場合と失敗する場合があります)。これにより、あなたのセキュリティがあなたが望むように設定されていることを検証することができます。

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

+0

優れた答え。偽装にも触れてくれてありがとう。 myClientBase.ClientCredentialsが既定で、System.Net.CredentialCache.DefaultNetworkCredentialsに設定されている、またはDefaultNetworkCredentialsになっていると思っています。おそらく私は自分自身で監査を使用してそれを発見するでしょう。 – xr280xr

+0

私の推測では、あなたのWebアプリケーションが(IISでホストしていると仮定して)実行しているアプリケーションプールIDの資格情報に設定されているということです。Webサイトが既に偽装用に設定されていて、WCF呼び出しがそれを継承している場合(ただし疑いはありません)、可能性があります。監査は確かに知る唯一の方法ですが、私はそれがアプリケーションプールのアイデンティティだと推測しています。 –

+0

Webアプリサイトは、ローカルIUSR_ *アカウントを使用して匿名アクセスを許可するように設定されています。それは、アプリケーションプールアカウントとは異なる認証のためにそのアカウントを使用しています。 – xr280xr

関連する問題