web-dev-qa-db-ja.com

Zuul-APIゲートウェイ認証

Zuulをいくつかのサービスの前でAPIゲートウェイとしてSpring Cloudを通じて紹介したいと思います。

認証に関して設計上の疑問がいくつかあります。認証は、サーブレットフィルタチェーンでZuulの前に来るSpring Securityによって処理されます。

私の懸念：

  • ゲートウェイは多くのサービスの前に配置されます

  • 一部のサービスは、認証を必要としないエンドポイントを公開する場合があります

  • 一部のサービスは、セッションIDを必要とするエンドポイントとトークンを含むエンドポイントを公開する場合があります」、任意の不透明な値（「推測が難しい」URLを知っている場合のファイルのダウンロードなど）API Gateway/Spring Securityでは、特定の認証要件を持つエンドポイント。

API Gatewayの管理に関して：

  • ダウンストリームサービスごとに必要な設定を提供するために、実際のサービスチームをどのように実施しますか？
  • ゲートウェイ全体を停止することなく、ゲートウェイで（サービスのニーズに応じて）認証設定の頻繁な変更をどのように許可しますか？

ありがとう、エイドリアン

spring-cloudnetflix-zuul
32
Adrian Ivan

Springセッションを使用して、Zuul Edge Serverの背後にあるすべてのサービスにセッションを複製しています。 Zuulはユーザーを認証し、ユーザーの資格情報を入力して、認証されたユーザーをセッションに挿入します。これはすべてのサービスに複製され、各サービスは独自のセキュリティルールと設定を担当します。本当に、Zuulがしていることはすべて、春のセキュリティでユーザーを検索することであり、バックエンドのサービスはニーズに応じてセキュリティルールを適用しています。このように、ゲートウェイを単なるダムプロキシにすることで、各サービスを個別に変更できます。

これの良い例は、Dave Syersのチュートリアルにあります Spring Security and an Angular JS app 。私も投稿しました 別の質問 これに関連してこれには、これをどのように行うかのサンプルが含まれていて、役立つかもしれません。

25
Andrew Serff
  • ゲートウェイは多くのサービスの前に座ります

ここでの懸念は何ですか？

  • 一部のサービスは、認証を必要としないエンドポイントを公開する場合があります

Spring SecurityにはpermitAll() accessルールがあります

  • 一部のサービスは、セッションIDを必要とするエンドポイントとトークンを含むエンドポイントを公開する場合があります」、任意の不透明な値（「推測が難しい」URLを知っている場合のファイルのダウンロードなど）API Gateway/Spring Securityでは、特定の認証要件を持つエンドポイント。

Zuulプロキシはセッションを持つことができます。 Spring Security OAuth 2.0）を使用している場合は、ResourceServerSecurityConfigurer#stateless(false)を使用し、HttpSecurity#sessionManagement().sessionCreationPolicy(...)でセッションをアクティブにして、有効なアクセストークンを受け取るたびにセッションを作成できます。 JSESSIONID CookieはHTTP応答に配置されます。

  • ダウンストリームサービスごとに必要な設定を提供するために、実際のサービスチームをどのように実施しますか？

ここで質問を理解したかどうかはわかりませんが、APIゲートウェイ（zuulプロキシ）レベルでセキュリティ制約を適用したくないですか？または、プロキシとターゲットアプリケーションの両方で「セキュリティダブルチェック」をしようとしていますか？

  • ゲートウェイ全体を停止することなく、（サービスのニーズに応じて）ゲートウェイで頻繁に認証設定を変更するにはどうすればよいですか？

Zuulでは、スタンドアロンライブラリとして使用する場合、ZuulRoutesを実行時に動的に追加できます。コンテキストが起動時に1回初期化されるSpring Securityにラップされています...実行時にセキュリティ設定を簡単に変更できるとは思えません。

コメント内のOPによる次の精度の編集：centralizedゲートウェイは設計上矛盾しています。

マイクロサービスの哲学の私の解釈では、各アプリケーションはスタンドアロンであり、その全機能範囲を担当し、セキュリティ/アクセス制御はその一部です。アプリケーションレベルでトークンを簡単に検証できます（承認サーバーを呼び出すか、JWTを使用して）。各アプリケーションは、各リソースに必要なスコープを定義します。 Spring Cloudには既に OAuth 2.0スターター がありますが、「プレーン」なSpring Bootを使用すれば簡単に作成できます。

これにより、セキュリティのアップストリームコンポーネントに依存したり、ゲートウェイ構成の展開を他のチームと同期したりすることなく、個々のアプリを任意の場所（パブリッククラウドまたはオンプレミスサーバー）に展開できます。

API Gatewayのことは簡単な誘惑ですが、リスクと制約を見逃さないでください。

  • 内部通話を保護することはできません
  • アップストリームネットワークコンポーネントに依存し、アプリケーションの入力を当然のように受け取らなければなりません。
  • 高度なアクセス制御ルールが頭痛の種になる可能性があります。ユーザーの個々のアクセス許可を取得する方法など
  • 構成の変更を他のチームと同期する必要があります
5
Michael Técourt