3

コア API を収容する WCF サービスに取り組んでいます。

この API を使用する 2 つのクライアントに取り組んでいます。そのうちの 1 つは、Active Directory に対して認証され、API と同じドメインに存在する可能性が最も高い WPF デスクトップ アプリです。もう 1 つは、セキュリティのために ASP.Net メンバーシップを使用する可能性が高く、WCF サービスと同じドメインに存在する ASP.Net Web アプリケーションです。計画では、WCF サービスが NetTcp を使用し、Windows サービス内でホストされる予定です。

可能であれば、WCF サービスを呼び出し元のユーザーとして実行したいと考えています。これは、ユーザーがドメイン ユーザーであるデスクトップ アプリの場合はかなり簡単なはずです。Web アプリの場合、サービス呼び出しを実行するためのユーザーを作成する必要があると思います。

この種のセキュリティへの二重のアプローチを単一の WCF サービスで実行することは可能ですか、それとも独自のセキュリティ モデルでそれぞれ 2 つのサービスを作成する必要がありますか?

また、これを達成するためのベストプラクティス/パターンについて誰かが考えているなら、それは素晴らしいことです.

ありがとう

4

2 に答える 2

4

次の方法で同じ問題を解決しました。

  1. 使用ごとに 2 つの net.tcp バインディングを作成しました。

      <security mode="TransportWithMessageCredential">
    <transport clientCredentialType="" />
    <message clientCredentialType="UserName" />
  </security>

</binding>
<binding name="WindowsBinding" >

  <security mode="TransportWithMessageCredential">
    <transport clientCredentialType="Windows" />
  </security>

</binding>

  2. 次に、すべてのサービスに 2 つのエンドポイントを追加しました

    <service name="SimplePluginService" behaviorConfiguration="CommonBehavior">

   <endpoint binding="netTcpBinding" bindingConfiguration="UserNameBinding" name="SimplePluginServiceUserName" contract="ISimplePluginService">
       <identity>
            <dns value="WCfServer" />
       </identity>
   </endpoint>

   <endpoint binding="netTcpBinding" bindingConfiguration="WindowsBinding" name="SimplePluginServiceWindows" contract="ISimplePluginService">
       <identity>
            <dns value="WCfServer" />
       </identity>
    </endpoint>

</service>

  3. 次に、ChannelFactory (ConnectionManager - ユーザーのクレジットに関する情報を含むクラス) を作成するときに、適切なエンドポイントを選択しました。

    private readonly Dictionary<Type, Object> channelFactoryDictionary = new Dictionary<Type, Object>();

private ChannelFactory<T> GetChannelFactory<T>() where T : class
{
    if (channelFactoryDictionary.Keys.Contains(typeof(T)))
    {
        return channelFactoryDictionary[typeof(T)] as ChannelFactory<T>;
    }
    else
    {
        string endpointName=typeof(T).ToString();
        if (ConnectionManager.IsWindowsAuth) endpointName+="Windows";
        else  endpointName+="UserName";

        ChannelFactory<T> channelFactory = new ChannelFactory<T>(endpointName);

        if (!ConnectionManager.IsWindowsAuth){
             channelFactory.Credentials.UserName.UserName = ConnectionManager.Password;
             channelFactory.Credentials.UserName.Password = ConnectionManager.Password;
        }

        channelFactoryDictionary.Add(typeof(T), channelFactory);
        return channelFactory;
    }
}
于 2012-07-20T06:39:01.340 に答える
0

ここでは、いくつかの異なる問題を混同しています。まず、ホスティング (Windows サービス) とトランスポート (ここでは netTcp として指定) は、ASP.NET メンバーシップに依存したい場合を除き、認証/承認の選択とはほとんど関係がないと主張します。サービスをホストする IIS。

なりすましは、デスクトップまたは慎重にキュレーションされた LDAP 環境でのアクセス制御に対する適切なアプローチであることは間違いありません。ただし、私のサービスが成長するにつれて、そのビジネス要件が、Active Directory で表される (または表される可能性のある) ポリシーから逸脱していることがよくあります。これが発生すると、Windows の偽装を希望どおりに機能させ続けるために、サービスでより多くのサポートが必要になります。これは多くの場合、WCF の拡張性を扱うことを意味します。

長年の経験から言えば、WCF セキュリティ拡張ポイントを操作することは、かろうじて麻酔をかけた根管とほぼ同じくらい苦痛です。とは言っても、辛い作業が終わったらかなりの威力です。

一般的に、痛みが少ないほど良いことがわかりました。クレームベースのセキュリティや CAS 属性などを使用して、コード内でアクセス制限を明示的にモデル化することで、なりすましのセキュリティ上の利点を得ることができます。このアプローチを採用することで、カスタムIPrincipal実装クラスは偽装の必要性をなくすことができ、それによって WCF 配管が非常にわかりにくくなります。

それはあなたが探していた答えではありませんが、それにもかかわらず、これらは私の 2 セントの価値があります。

于 2012-07-26T00:09:24.527 に答える