7

サーバー (「オンプレミス」) にDynamic CRMインスタンスがあります。これは、離れたマシン (別のドメイン、別の Active Directory) で実行されるいくつかのサイトで使用されます。これらのサイトと CRM インスタンス間の通信は、CRM プロキシ、その近く (CRM の近く) に配置され、要求を処理し、CRM にクエリを実行する WCF サービスを介して行われます。

その WCF サービスはインターネットに面しています。セキュリティで保護された通信チャネルはそれほど必要ではありませんが、認証は必要です。CRM プロキシによって提供されるサービスをランダムなクライアントに使用させることはできません。

したがって、認証サービス（Cookie？）/手動でコーディングされたトークンの受け渡し（各サービス操作のパラメーターとして）/このソリューション-on stackoverflow。

前もって感謝します！

PS: ハンドコーディングされたトークンは「時間に敏感」で、いくつかの秘密鍵で数回ハッシュされます。リクエスト後にトークンが無効化される可能性があるため、中間者はそれほど大きな問題ではないかもしれません。

4

2 に答える 2

11

手作業でコーディングされたトークンの受け渡しは、あまりエレガントではありません。メソッドのシグネチャを汚染し、あちこちでチェックを複製します。

クレデンシャルをサービス クライアントに配布できる場合、またはサービス クライアントがすでにシステムで使用しているクレデンシャルを渡すことができる場合は、メッセージ セキュリティをカスタムのユーザー名とパスワード バリデータとともに使用することをお勧めします。

それを実装する手順は非常に簡単です。実装する必要があるのは次のUserNamePasswordValidatorとおりです。

リンクされた記事からの短い構成の要約:

バインディングでセキュリティ モードを指定します。

<security mode="Message">
    <message clientCredentialType="UserName"/>
</security>

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

<serviceCredentials>
    <userNameAuthentication 
        userNamePasswordValidationMode="Custom" 
        customUserNamePasswordValidatorType="YourFullUserNameValidatorType"/>
</serviceCredentials>

その後、クライアントは資格情報をサービス プロキシに直接設定するだけで済みます。そのため、サービス操作では渡されません。

serviceClient.ClientCredentials.UserName.UserName = "username";
serviceClient.ClientCredentials.UserName.Password = "password";

サービス操作の呼び出しUserNamePasswordValidatorごとにこれらの資格情報を取得し、資格情報ストアに対してそれらを検証する機会があります。

ただし、セキュリティを強化するために、証明書認証を調べることができます。信頼性が高く、CA から証明書を購入する必要はありません。クライアント コンピューターで自分自身を CA としてセットアップすることもできる場合は、問題ありません。これは特に、少数のクライアントしかない場合に適切であり、管理が容易になります。

于 2012-07-05T18:58:21.277 に答える