0

クライアント/サーバー アプリケーションの場合、主にアプリケーション自体で使用される Web サービスを開発したいと考えています (現時点では、サード パーティによる使用は想定されていません)。

ただし、長期的には、WebService をある種の API として公開することが一般的に望ましいと言えます。したがって、後で簡単に Web サービスを "RESTifing" (ひどい言葉の作成、私は知っています ;-)) できるテクノロジを選択することについて、私はすでにいくつかの考えを入れています。
WCF は、webHttpBinding を提供するだけでなく、LAN および .NET クライアントを利用できるようにする他のバインディングも提供するため、ここにあるようです。

私が今遭遇した問題は、認証に関するものです。WCF が提供するすべての認証手段は、実際のサービスの「外部」で行われるようです。ただし、メソッド（または、ここでポイント 2 の下Loginに示されているように、より「RESTful」なもの）が必要です。

たとえば、次のような Service を書くことを想像します。

[ServiceContract]
public interface IUserService
{
   [ServiceMember]
   [WebInvoke(Method = "POST", WebUri="/Session")]
   public void Login(string username, string password);

   [ServiceMember]
   [WebInvoke(Method = "POST", WebUri="/Users")]
   public void Register(RegisterUserParameter parameter);
}

このサービスを WCF に統合して、サービス プロジェクト内の複数のサブサービスでメソッドが適切に機能するようにするにはどうすればよいですか?

組み込みの WCF 認証を使用する場合、サービスを呼び出す前にユーザー名とパスワードを入力する必要があります。したがって、認証されていないため、 Registeror のいずれかへの呼び出しは失敗します。Login

また、サービス メソッドを使用して現在ログインしているユーザーを WCF に記憶させるにはどうすればよいでしょうか。クライアントの WCF セッション内にセッション Cookie のようなものを保存する可能性はありますか?

それとも、私がしようとしている方法でWCFの下で認証を実現するのは一般的に悪い考えですか?

クライアントアプリケーションでサービスと対話するためのより複雑な方法を犠牲にして、WebAPIを直接選択する必要がありますか?

4

2 に答える 2

0

You can try the following:

  1. Create Login service with WCF login-password authentication. It will use e.g. subclass of UserNamePasswordValidator to validate username-password against DB etc. If validation is successful, return a token (e.g. GUID).

  2. All other service calls will be made by the client together with this token. Token verification can be made centrally, without modifying each service. To do so:

    • Pass your token in the header of your request
    • implement IDispatchMessageInspector, in its AfterReceiveRequest read token from header and validate it. If validation is successful, workflow will go inside your WCF service, if not you throw FaultException

    • attach your MessageInspector to services that need validation:


      ...

于 2012-10-16T11:41:24.830 に答える
0

FormsAuthentication のような外部認証に頼れば、簡単に目的を達成できると思います。

アイデアは、すべてのメソッドをPrincipalPermission属性で保護することです。唯一の例外は、フォーム Cookie を応答に追加することになっているLoginメソッドです。

いくつかの技術的な詳細は、私のブログ投稿の 1 つに記載されています。

http://netpl.blogspot.com/2010/04/aspnet-forms-authentication-sharing-for.html

ここではクライアントとして Silverlight について言及していますが、ソリューションは一般的なものであり、あらゆるクライアント テクノロジに適用されます。また、Loginメソッドはブログ投稿には記載されていませんが、その唯一の目的は、フォーム Cookie を応答に追加することです。

このように、クライアントの制御フローは、最初にLoginメソッドを呼び出し、次に問題の Cookie を使用して、他のすべてのメソッドを呼び出すことになります。

これは Http バインディングでのみ機能するため、考えられる Wcf バインディングに対する一般的な解決策ではないことに注意してください。

于 2012-10-07T20:11:56.013 に答える