4

WCFは非常に拡張性が高く、すぐに使用できる機能がたくさんありますが、いくつかのトピックに苦労し続けており、ドキュメントを読むほど混乱します。

コミュニティからいくつかの回答を得たいと思います。仮定や質問に対するフィードバックは大歓迎です。

記録のために：本当に単一の答えを受け入れるために、私はこの投稿を複数の質問に分割する必要がありますが、それはさらに混乱につながるでしょう。このドキュメントのいくつかの質問に一度に答えることができる実際のWCFエキスパートがオンラインにいると確信しているので、IISを使用してクライアント証明書認証を正しい方法でセットアップするための実際の取引として単一の答えを受け入れることができます。

状況とパートナーのリクエストをスケッチしましょう。

1：パートナーの要件とクライアント証明書を使用するための質問。

パートナーXはバックエンドでAPIを呼び出す必要があり、Clientcertificate認証を使用するという明確な要件があります。彼らはclientcertificateを作成し、公開鍵のみを使用して証明書を提供しました。これは、秘密鍵を実際に秘密にして独自のシステムに保持するのは論理的なものにすぎないためです。証明書はローカルコンピューターアカウントにインポートされ、証明書パスを見るとこれは有効です。すべての中間認証局、そして最終的にはルート認証局が信頼されます。

2：WCFサーバー側の構成

次のように設定されたserviceBehaviorがあります。

<behavior name="ClientCertificateBehavior">
    <serviceMetadata httpsGetEnabled="true" />
        <serviceCredentials>
        <serviceCertificate findValue="<serialnumber here>" x509FindType="FindBySerialNumber" />
        <clientCertificate>
          <authentication certificateValidationMode="PeerTrust" />
        </clientCertificate>
    </serviceCredentials>
</behavior>

ここで最初の間違いを犯したと思います。ChainTrustを使用して、証明書パスを使用して証明書を実際に検証する必要があります。どう思いますか？

サービスは次のように構成されます。

<service behaviorConfiguration="ClientCertificateBehavior" name="<Full service namespace and servicename>">
    <endpoint binding="basicHttpBinding" bindingConfiguration="Soap11CertificateBasicHttpBinding"
        contract="<The interface>"></endpoint>
</service>

バインディングは次のようになります。

（パートナーの仕様に従って）SOAP1.1を強制するのはbasicHttpBindingです。

<binding name="Soap11CertificateBasicHttpBinding">
  <security mode="Transport">
    <transport clientCredentialType="Certificate" />
  </security>
</binding>

3：IISおよびIIS構成でのWCFサービスのホスティング

WCFサービスはIIS7でホストしています。SSLを要求し、クライアント証明書を受け入れるように、サービスが存在するフォルダーを構成しました。認証に関する匿名認証が有効になります。

パートナーからの通信が機能し、すべてが正常であると確信していましたが、IIS設定を「require」クライアント証明書に切り替えると、突然、サービスを正常に呼び出すことができなくなったことがわかります。

次のことが正しく行われていないと仮定するのは正しいですか？

  • serviceBehaviorのserviceCerticateは実際には必要ありません。これは、クライアントが使用する設定です。または、クライアントによって送信されている証明書と一致するように、サービスエンドポイントにこの証明書情報を提供する必要がありますか？

  • clientcertificate認証がIISで実際に機能するには、証明書をユーザーにマップする必要があります。このユーザーには、サービスを含むフォルダーへのアクセス許可を付与する必要があり、すべての認証メカニズム（匿名、ウィンドウなど）を無効にする必要があります。このようにして、IISは実際のハンドシェイクを処理し、サービス通信を検証します。それとも、証明書をユーザーにマッピングするための追加のセキュリティの問題ですか？

    • IISで「承認」を設定することにより、クライアントとサーバー間の実際の証明書検証をバイパスします。

    • 「匿名」や「ウィンドウ」などのすべての認証メカニズムは、サービスを保持するフォルダーのIISで無効にする必要があります。

4

1 に答える 1

2

シナリオでは、WCFで証明書を構成する必要はなく、IISが証明書を処理します。<serviceCredentials>次の理由により、ブロック全体をクリアできます。

<serviceCertificate>of<serviceCredentials>は、使用しないメッセージセキュリティモードを使用してクライアントに対してサービスを認証するために使用されるX.509証明書を指定し、ofは、サービスからクライアントへのメッセージに署名および暗号化するために使用されるX.509証明書<clientCertificate>を<serviceCredentials>定義します。二重通信パターンで。

クライアント証明書をユーザーアカウントにマップする方法については、こちらをご覧ください。

于 2013-01-21T12:33:06.930 に答える