2011-01-26 30 views
4

私はIISでホストされているWCFサービスを持っています。サービスでは、私は約20の方法を持っています。私はこれらのメソッドのいくつかをユーザー名/パスワードで保護したいと思います。私はサービスを呼び出しているクライアントを制御していないので、クライアントに証明書をインストールすることはできません。当社のサービスは、ログイン情報を含むすべてのユーザープロファイル情報を保持するプラットフォームとして機能します。クライアント証明書のないWCFメッセージ/メソッドセキュリティ

私は、クライアントがWCFサービスの認証(ユーザー名、パスワード)メソッドに一度認証し、認証トークンを取得して、後続の呼び出しに渡すことを望みたいと思うと思います。 (Asp.netメンバーシップのプロバイダのように、フォームの認証セッションを使用しています)。可能であれば、クライアントがすべてのメソッド呼び出しのためにユーザー名/パスワードを渡す必要はありません。これは正しいパターンですか?標準WCF機能を使用してこの機能を動作させるより良い方法はありますか?誰かがこれを動作させる正しい方法を示すためのサンプル設定/コードを持っていますか?

答えて

4

WCFは、操作ごとの認証をボックス単位で提供しません。セキュリティで保護された操作とセキュリティ保護されていない操作が必要な場合は、最も簡単な方法は、2つのサービス契約に分割し、それぞれ異なるセキュリティ設定で公開することです。

承認トークンの考え方はWCFで既に実装されていますが、シナリオではwsHttpBinding、UserNameクライアントの資格情報、SecurityContextとサービス証明書を使用する必要があります。

<system.serviceModel> 
    <behaviors> 
     <serviceBehaviors> 
     <behavior name="securedService"> 
      <serviceCredentials> 
      <serviceCertificate x509FindType="FindBySubjectName" findValue="ServerCert" 
           storeLocation="LocalMachine" storeName="My"/> 
      </serviceCredentials> 
     </behavior> 
     </serviceBehaviors> 
    </behaviors> 
    <bindings> 
     <wsHttpBinding> 
     <binding name="Secured"> 
      <security mode="Message"> 
      <message clientCredentialType="UserName" establishSecurityContext="true" /> 
      </security> 
     </binding> 
     </wsHttpBinding> 
    </bindings> 
    <services> 
     <service name="MessageSecurity.Service" behaviorConfiguration="securedService"> 
     <endpoint address="" binding="wsHttpBinding" bindingConfiguration="Secured" 
        contract="MessageSecurity.IService"> 
     </endpoint> 
     </service> 
    </services> 
    </system.serviceModel> 

SecurityContextは、WS-SecureConversationに基づいた相互運用可能な機能です。これは、サービスプロキシインスタンスからの最初の呼び出しでのみユーザー名とパスワードを渡す必要があります(WCFでは、これは完全に透過的です。クライアントプロキシインスタンスはセキュリティコンテキストを維持します)。次のコールは、最初のコールで発行されたセキュリティトークンのみを使用します。 SecurityContextは、デフォルトでwsHttpBindingでオンになっています。

この設定でも、メッセージを暗号化して署名します。フルパワーのWS-Securityです。他の方法はあなた次第です。自分で完全に実装する必要があります。

あなたはクライアントを制御できないと述べました。証明書を使用できないということではありません。証明書を使用する場合は、お客様のサービスに電話したい場合は、証明書を取得するのはクライアントの責任です。それは、クライアントに対する証明書への信頼についての制御とは無関係です。パブリックWebサービスでは、信頼できる証明機関から証明書を購入することを意味します。

さらに、サービス証明書をインストールせずに取得することもできます。最初の可能性は、証明書をエンドポイントIDとして使用することです。そのような場合には、符号化された証明書は、WSDLの一部です:

あなたが設定されたサービス証明書を使用してwsHttpBindingエンドポイントを指定し、そのIDを設定しない場合、これは自動的に行われ
<wsdl:service name="Service"> 
    <wsdl:port name="WSHttpBinding_IService" binding="tns:WSHttpBinding_IService"> 
    <soap12:address location="http://localhost:1432/Service.svc" /> 
    <wsa10:EndpointReference> 
     <wsa10:Address>http://localhost:1432/Service.svc</wsa10:Address> 
     <Identity xmlns="http://schemas.xmlsoap.org/ws/2006/02/addressingidentity"> 
     <KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#"> 
      <X509Data> 
      <X509Certificate>MIICmzCCAYegAwI....<X509Certificate> 
      </X509Data> 
     </KeyInfo> 
     </Identity> 
    </wsa10:EndpointReference> 
    </wsdl:port> 
</wsdl:service> 

。このメソッドの欠点は、証明書の有効期限です。期限切れの証明書を変更する場合は、すべてのクライアントを更新する必要があります。

第2の可能性は、サービスの資格情報ネゴシエーションを有効にするには、次のとおりです。

<bindings> 
    <wsHttpBinding> 
    <binding name="Secured"> 
     <security mode="Message"> 
     <message clientCredentialType="UserName" negotiateServiceCredential="true"/> 
     </security> 
    </binding> 
    </wsHttpBinding> 
</bindings> 

ネゴシエーションはデフォルトでオンになっています。安全な通信が始まる前に、TLSNegoプロトコルを使用してサービスクレデンシャル(証明書)を交換します。この方法の欠点は、TLSNegoがすべてのプラットフォームでサポートされていないことです。

+1

'netTCPBinding'でこれを行うことはできますか? – Sreekumar

1

FYI:組み込みのWCFカスタムユーザー/パスサブシステムを使用する場合、WCF 4.0はAllow Insecure Transport propertyを導入しました。これにより、証明書なしでWCFセキュリティサブシステムを使用することができます。これは、WCFはそれが考えられないにもかかわらずメッセージングを保護すると考えられる状況(SSLがアプライアンスレベルではなくWebサーバレベル、またはIPフィルタリングが使用されている場合)。

関連する問題