ここでの懸念は何ですか？
- 一部のサービスは、認証を必要としないエンドポイントを公開する場合があります
Spring Security にはpermitAll()アクセス ルールがあります
- 一部のサービスは、セッション ID とトークンを必要とするエンドポイントを公開する場合があります」、任意の不透明な値 (たとえば、「推測しにくい」URL がわかっている場合にファイルをダウンロードする) API Gateway/Spring Security では、すべての特定の認証要件を持つエンドポイント。
Zuul プロキシはセッションを持つことができます。Spring Security OAuth 2.0 を使用している場合は、有効なアクセス トークンを受け取るたびにセッションを使用ResourceServerSecurityConfigurer#stateless(false)してアクティブ化し、セッションを作成できます。HttpSecurity#sessionManagement().sessionCreationPolicy(...)JSESSIONID Cookie が HTTP 応答に配置されます。
- ダウンストリーム サービスごとに必要な設定を提供するために、実際のサービス チームをどのように強制しますか?
ここでの質問がよくわかりません。API ゲートウェイ (zuul プロキシ) レベルでセキュリティ制約を適用したくないですか? または、プロキシとターゲット アプリケーションの両方で「セキュリティ ダブル チェック」を実行しようとしていますか?
- ゲートウェイ全体を停止することなく、(サービスのニーズに応じて) ゲートウェイで頻繁に認証設定を変更できるようにするにはどうすればよいですか?
ZuulRouteZuulをスタンドアロン ライブラリとして使用する場合、実行時に s を動的に追加できます。コンテキストが起動時に一度初期化されるSpring Securityにラップされています...実行時にセキュリティ構成を簡単に変更できるとは思えません。
コメント内の OP による次の精度を編集します。チームがセキュリティ ルールに責任を負う必要がある場合、集中型ゲートウェイを持つことは設計上の矛盾です。
マイクロサービスの哲学に対する私の解釈は、各アプリケーションはスタンドアロンであり、その機能範囲全体を担当し、セキュリティ/アクセス制御はその一部であるというものです。各アプリケーションが各リソースに必要なスコープを定義することで、(認可サーバーを呼び出すか、JWT を使用して) アプリケーション レベルでトークンを簡単に検証できます。Spring Cloud にはすでにOAuth 2.0 starterがあります。または、「プレーンな」Spring Boot を使用する場合は簡単に作成できます。
そうすれば、個々のアプリを必要な場所 (パブリック クラウドまたはオンプレミス サーバー) に展開できます。セキュリティのためにアップストリーム コンポーネントに依存したり、ゲートウェイ構成の展開を他のチームと同期したりする必要はありません。
API Gateway は簡単に誘惑されますが、リスクと制約を見逃さないでください。
- 内部通話を保護できなくなります
- 上流のネットワーク コンポーネントに依存する必要があり、アプリケーションの入力を当然のことと見なす必要があります。
- 高度なアクセス制御ルールは頭痛の種になる可能性があります: ユーザーの個々のアクセス許可をどのように取得するかなど
- 構成の変更を他のチームと同期する必要があります