1

RESTful API を提供するアプリケーションを作成しています。アプリケーションを保護する必要がありますが、認証/暗号化メカニズムによってインターフェイス プログラムや API が汚染されることは望ましくありません。

私たちのケースでプロキシが役立つかどうか疑問に思っていましたが、私は Web 開発の専門家ではないので、私の写真が理にかなっているのかどうかを知る必要があります。システムの構造は次のとおりです。

  1. サーバー プログラムは単に API を TCP ポートにエクスポートしますが、ローカル プロセス (にバインド) からのみアクセスできます127.0.0.1。

  2. プロキシ サーバーは SSL と認証を管理します。

    • URIとメソッドはそのままエクスポートされますが…</li>
    • 必要な機能を備えた認証済みユーザーのみが実際に呼び出すことができ、さらに…</li>
    • 通信は暗号化されたチャネルで実行されている必要があります

だから、私の質問は次のとおりです。

  1. これは合理的なシナリオですか？

  2. このジョブで実行できる適切なプロキシ サーバーは何ですか?

  3. これを行うことに欠点はありますか？

ご協力いただきありがとうございます！

4

1 に答える 1

2

HTTPSリバースプロキシを使用することで、一般的なシナリオを実現できるようです。そこには複数の実装があります。

人気のあるものはApacheHttpdです。これは、着信HTTPS接続、認証（さまざまなメカニズムを使用）、およびリバースプロキシを処理できます。

「プレーンな」HTTPアプリケーションをリッスンする典型的なシナリオは、そのlocalhost前にApache Httpdを配置し、外部接続を処理することです。ここで、

  • mod_sslサーバーのSSL/TLS構成を処理します。
  • さまざまなmod_auth*モジュールの1つが認証を処理します（認証の実行方法によって異なります）。REMOTE_USERこれらは、認証されたユーザー名（たとえば）を承認のためにバックエンドにエクスポートできる必要があります。
  • mod_proxyバックエンドアプリケーションへの接続を処理します（たとえばmod_proxy_http、アプリケーションサーバーがHTTP自体を使用している場合）。

特定のアクションを実行するために必要な機能を持つユーザーのみを許可することが、承認部分です。これは、フロントエンドが「必要な機能を備えている」と定義する方法を推測できないため、メインAPIから分離するのが困難です。ロジックの残りの部分と絡ませる必要があるというわけではありませんが、認証システムはAPIがどのように機能するか（つまり、可能なアクションが何であるか）を知る必要があるため、通常はメインアプリケーション内に実装するのが最適です。

于 2012-10-07T15:39:06.273 に答える