0

私は現在、IISを介して実行されるRESTfulサービスを実装するためのWCFを調査しています。現在、当社のソフトウェアは、さまざまなソースに対してユーザーを認証する機能を提供しています

  1. データベースに保存されている独自の内部ユーザーアカウント

  2. 指定されたWindowsActiveDirectory。認証が成功すると、ルックアップが実行されて、winowsがリンクされている内部アカウントが検索されます。

  3. Novellなどの別のLDAPサーバー

したがって、これを機能させたいのは、クライアントがSSLを介して認証ヘッダー（今のところ基本）を使用してhttp（s）リクエストを送信し、サービスがカスタム認証を使用して上記のプロセスを実装することです。

今のところ、サービスをセルフホスティングしてカスタム認証の例を機能させようとすると、正常に起動しますが、ブラウザまたは認証ヘッダーを添付できるツールからリクエストを送信しようとすると、すべてが取得されます。

「エラー101（net :: ERR_CONNECTION_RESET）：接続がリセットされました。」

カスタム認証クラスにブレークポイントを設定しましたが、到達することはありません。そのため、構成に問題があると推測しています。

私のapp.config;

<configuration>

...

<system.serviceModel>

    <bindings>
        <webHttpBinding>
            <binding name="secure">
                <security mode="Transport">
                    <transport clientCredentialType="Basic"></transport>
                </security>
            </binding>
        </webHttpBinding>
    </bindings>

  <services>
    <service name="CELCAT.RegisterMarker.RegisterMarker" behaviorConfiguration="myServiceBehavior">
      <endpoint address="https://mymachine:8001/servicename" 
                binding="webHttpBinding"
                bindingConfiguration="secure" 
                contract="myServiceContract" />
    </service>
  </services>

  <behaviors>
    <serviceBehaviors>
      <behavior name="myServiceBehavior">
        <serviceMetadata httpGetEnabled="True"/>
        <serviceDebug includeExceptionDetailInFaults="True"/>
          <serviceAuthorization serviceAuthorizationManagerType="MyServiceAuthorizationManager, authenticatonassembly" />

          <serviceCredentials>
              <userNameAuthentication userNamePasswordValidationMode="Custom"
                                      customUserNamePasswordValidatorType="servicenamespace, serviceassembly" />

              <serviceCertificate findValue="certname"
                                  storeLocation="LocalMachine"
                                  storeName="My"
                                  x509FindType="FindBySubjectName" />
          </serviceCredentials>
      </behavior>
    </serviceBehaviors>
  </behaviors>

</system.serviceModel>
</configuration>

私がやろうとしていることはWCFでそのままでは不可能であるという投稿を読みました。これを実現するには、以下に説明するように、カスタムモジュールを作成するかインターセプターを要求する必要があります。

カスタムモジュールによる認証。 http://custombasicauth.codeplex.com/

リクエストインターセプターによる認証。 http://www.codeproject.com/KB/WCF/BasicAuthWCFRest.aspx

これは私には可能であるように思われるので、私の質問は

  1. 私がやろうとしていることは可能ですか？
  2. もしそうなら、私は何が間違っていますか？または、そうでない場合は、どちらの回避策が最適ですか？
4

2 に答える 2

2

アンドリュー教会からの多くのグーグルとプロンプトの後でOK（ありがとうアンドリュー）私はこれを理解しました。

問題は、証明書を生成したにもかかわらず、それをポートにバインドしていなかったことです。証明書の生成とバインドに役立つ手順は、次の場所にあります。

http://www.codeproject.com/Articles/24027/SSL-with-Self-hosted-WCF-Service

ただし、これはhttpcfgを使用するように要求します。このツールは、Windows Vistaまたは7（私のOS）には存在しないため、さらにGoogleがこの記事を公開しました。

http://msdn.microsoft.com/en-us/library/ms733791.aspx

これは、netshを使用するように指示します。完璧です。これにはappidというパラメーターが必要なため、これをどこで見つけることができるかわからなかったので、さらに検索するとここに戻ります。

netsh.exeではどのappidを使用する必要がありますか？

そこで、すべての手順を実行し、app.configの証明書部分をコメントアウトして、カスタム構成のブレークポイントに到達しました。

これが同じ問題を抱えている他の人に役立つことを願っています

于 2012-08-03T13:04:44.190 に答える
0

これが機能するかどうかはわかりませんが、過去に行ったことは、カスタムHTTPモジュールを使用することです。APIはアクセストークンを使用するため、モジュールを使用してヘッダーにトークンが存在するかどうかを検査します。トークンが存在しない場合は、APIの認証エンドポイントにリダイレクトします。エンドポイントは基本認証を期待しています。お役に立てれば。

于 2012-08-02T19:36:04.420 に答える