24

WCF で RESTful サービスを可能にする構成ファイルを作成しようとしていますが、ユーザー名/パスワード認証のためにメンバーシップ プロバイダーを「利用」する機能が必要です。

以下は、basicHttp バインディングまたは WS セキュリティなしの wsHttp を使用した現在の構成の一部ですが、REST ベースのサービスではこれがどのように変化しますか?

    <bindings>
        <wsHttpBinding>
            <binding name="wsHttp">
                <security mode="TransportWithMessageCredential">
                    <transport/>
                    <message clientCredentialType="UserName" negotiateServiceCredential="false" establishSecurityContext="false"/>
                </security>
            </binding>
        </wsHttpBinding>
        <basicHttpBinding>
            <binding name="basicHttp">
                <security mode="TransportWithMessageCredential">
                    <transport/>
                    <message clientCredentialType="UserName"/>
                </security>
            </binding>
        </basicHttpBinding>
    </bindings>
    <behaviors>
        <serviceBehaviors>
            <behavior name="NorthwindBehavior">
                <serviceMetadata httpGetEnabled="true"/>
                <serviceAuthorization principalPermissionMode="UseAspNetRoles"/>
                <serviceCredentials>
                    <userNameAuthentication userNamePasswordValidationMode="MembershipProvider"/>
                </serviceCredentials>
            </behavior>
        </serviceBehaviors>
    </behaviors>
4

7 に答える 7

3

ASP.net メンバーシップ プロバイダーを使用した WCF REST サービスの保護に関するポッドキャストを次に示します。

http://channel9.msdn.com/posts/rojacobs/endpointtv-Securing-RESTful-services-with-ASPNET-Membership/

于 2008-10-04T14:30:07.917 に答える
2

WCF を介した複雑な REST シナリオは悪い考えであるという Darrel に同意します。それはただきれいではありません。

ただし、Dominick Baier は、彼の最小権限ブログで、これに関するいくつかの優れた投稿を行っています。

WCF で FormsAuthenticationTicket サポートにフォールバックする WSSE 認証サポートを確認したい場合は、BlogService のソース コードを確認してください。

于 2008-09-29T15:23:51.950 に答える
1

コミュニティが WCF での REST に反対する意見を持っているかどうかに関係なく(私は個人的に意見が分かれています)、 Microsoft はそれを一掃しました

于 2008-11-30T19:06:45.853 に答える
1

2012 年 1 月 23 日更新

この質問を書いて以来、REST のような Web サービスを実際に保護するためのより優れたアプローチを見てきました。最初に聞いたときは複雑に聞こえましたが、アイデアはシンプルで、Web サービスとその他の安全な通信の両方で Web 全体に適用されます。

公開鍵/秘密鍵を使用する必要があります。

1.) エンドポイントの各ユーザー (顧客) は、REST Web サービスに登録する必要があります。

  • a.) 誰とも共有してはならない秘密鍵をこのユーザーに渡します
  • b.) 必要に応じてプレーン テキストで送信できる公開鍵も生成します (これはクライアントの識別にも使用されます)。

2.) ユーザーからの各リクエストは、リクエストに署名するためにハッシュを生成する必要があります

  • a.) これの一例は次のようになります: 秘密鍵 + タイムスタンプ + エンコードされたペイロード (たとえば、単純なユーザー情報を更新するのに十分小さい場合)
  • b.) これら 3 つ (または決定したもの) を取得し、一方向ハッシュを生成します (たとえば、hmac を使用)
  • c.) ネットワーク経由で送信されるリクエストに、公開鍵 (このリクエストを誰が送信しようとしているかをサーバー側が認識できるようにするため)、秘密鍵で生成されたハッシュ、およびタイムスタンプを含めます。

3.) サーバー エンドポイント (REST メソッド) は、クライアントで使用されるのと同じ入力を使用してハッシュを生成する必要があります。この手順により、クライアントとサーバーの両方が、リクエストと共に渡された公開鍵と一致する秘密鍵を知っていることが証明されます。(これは、他の誰も秘密鍵を知ることができないため、リクエストを送信したユーザーが正当であることを意味します)

  • a.) リクエスト中に渡される公開鍵によって、顧客の秘密鍵を検索します。

  • b.) 他のパラメーター (タイムスタンプとエンコードされたペイロード) を前の手順で見つけた秘密鍵と共に取得し、同じアルゴリズムを使用して一方向ハッシュを生成します (ここでも、hmac は私が実世界で使用されているのを見たものです) )

  • c.) 結果の一方向ハッシュは、ネットワーク経由で送信されたハッシュと一致する必要があります。400 (または「不正な要求」と見なされる http コード) を返信しない場合は、
于 2012-01-24T02:58:27.217 に答える
1

WCF を介して REST を実装するための戦いを続ける前に、Tim Ewald によるこの記事を読むことをお勧めします。特に印象に残ったのは、次の言葉です。

HTTP を除外するように設計されたレイヤーの上に、HTTP を除外するように設計されたレイヤーを構築したいかどうかはわかりません。

私は過去 12 か月間、WCF を使用して REST ベースのものを開発してきました。私見 WCF がテーブルにもたらすものは、REST 作業を行うために導入される複雑さよりも重要です。

于 2008-09-27T14:50:32.483 に答える
1

はい、Moto に同意しました。WCF スターター キットからのリンクは、カスタム HTTP ヘッダー ( http://msdn.microsoft.com/en-us/library/dd203052.aspx ) を使用した資格情報の認証に最も近いものです。

しかし、私は例を進めることができませんでした。

于 2009-01-05T01:22:41.817 に答える
1

custombasicauth @ codeplex を試す

于 2009-03-22T09:49:13.400 に答える