JHipster APIゲートウェイパーマリンク to " JHipster APIゲートウェイ"

JHipsterはAPIゲートウェイを生成できます。ゲートウェイは通常のJHipsterアプリケーションであるため、そのプロジェクトでは通常のJHipsterオプションと開発ワークフローを使用できますが、マイクロサービスへの入り口としても機能します。より具体的には、HTTPルーティングとロードバランシング、サービス品質、セキュリティ、およびすべてのマイクロサービスのAPIドキュメントを提供します。

サマリーパーマリンク to "サマリー"

アーキテクチャ図
HTTPルーティング
セキュリティ
自動ドキュメンテーション
レート制限
アクセス制御ポリシー

アーキテクチャ図パーマリンク to "アーキテクチャ図"

Diagram

ゲートウェイを使用したHTTPリクエストのルーティングパーマリンク to "ゲートウェイを使用したHTTPリクエストのルーティング"

ゲートウェイとマイクロサービスが起動されると、自身をConsulサービスレジストリに登録します。

ゲートウェイは、アプリケーション名を使用して、すべてのリクエストをマイクロサービスに自動的にプロキシします。たとえば、マイクロサービスapp1が登録されている場合、ゲートウェイの/services/app1のURLで利用できます。

たとえば、ゲートウェイがlocalhost:8080で実行されている場合、http://localhost:8080/services/app1/api/foosの指定で、マイクロサービスapp1で提供されているfoosのリソースを取得できます。Webブラウザでこれを行おうとしている場合は、RESTリソースがJHipsterでデフォルトで保護されていることを忘れないでください。したがって、正しいJWTヘッダーを送信するか（以下のセキュリティのポイントを参照）、以降のセキュリティに関するポイントを確認するか、またはマイクロサービスのMicroserviceSecurityConfigurationクラスでそれらのURLのセキュリティを削除する必要があります。

同じサービスのインスタンスが複数実行されている場合、ゲートウェイはそれらのインスタンスをJHipsterレジストリから取得し、Consulを使用してHTTPリクエストのロードバランシングを行います。

各ゲートウェイには特定の”admin > gateway”メニューがあり、オープンされたHTTPルートとマイクロサービスインスタンスを監視できます。

セキュリティパーマリンク to "セキュリティ"

標準のJHipsterセキュリティオプションについては、このセキュリティドキュメントページで詳しく説明されています。ただし、マイクロサービスアーキテクチャのセキュリティ保護には、いくつかの特定のチューニングとオプションがあります。これらについては、ここで詳しく説明します。

JWT (JSON Web Token) パーマリンク to "JWT (JSON Web Token)"

JWT (JSON Web Token)は、マイクロサービスアーキテクチャでアプリケーションを保護するための、業界標準の使いやすい方法です。

JHipsterは、Okta社が提供するJJWTライブラリのJWT実装を使用します。

トークンはゲートウェイによって生成され、基盤となるマイクロサービスに送信されます。共通のシークレットキーを共有するため、マイクロサービスはトークンを検証し、そのトークンを使用するユーザを認証できます。

これらのトークンは自己充足的であり、認証情報と認可情報の両方を持っているため、マイクロサービスはデータベースや外部システムに問い合わせる必要がありません。これは、スケーラブルなアーキテクチャを確保するために重要です。

セキュリティーを機能させるためには、JWTのシークレットトークンをすべてのアプリケーションで共有する必要があります。

各アプリケーションのデフォルトトークンは固有であり、JHipsterによって生成されます。これは.yo-rc.jsonファイルに格納されます。
トークンは、src/main/resources/config/application.ymlファイル内のjhipster.security.authentication.jwt.secretキーで構成されます。
このキーをすべてのアプリケーション間で共有するには、ゲートウェイからすべてのマイクロサービスにキーをコピーするか、JHipster固有のConsul K/Vストアの設定を使用してキーを共有します。これが、中央構成サーバが使用される主な理由の1つです。
開発と本番で異なるキーを使用することをお勧めします。

OpenID Connect パーマリンク to "OpenID Connect"

JHipsterはOpenID Connectのサポートを提供しており、詳細はOpenID Connectのドキュメントに記載されています。

このオプションを選択すると、デフォルトでKeycloakが使用され、Docker Composeを使用して完全なマイクロサービスアーキテクチャを実行することになります。Docker Composeドキュメントを必ず読み、Keycloak用に/etc/hostsを正しく設定してください。

OpenID Connectを使用する場合、JHipsterゲートウェイはOAuth2トークンをマイクロサービスに送信し、マイクロサービスはKeycloakにも接続されているトークンを受け入れます。

JWTとは異なり、これらのトークンは自己充足的ではなく、ステートフルである必要があるため、次のような問題が発生します。

マイクロサービスのパフォーマンスの問題：現在のユーザのセキュリティ情報を探すことは非常に一般的なため（そうでなければ最初からセキュリティオプションを使用することはありません）、各マイクロサービスはOpenID Connectサーバを呼び出してデータを取得します。そのため、通常のセットアップでは、これらの呼び出しは、リクエストを受け取るたびに各マイクロサービスによって行われ、これはすぐにパフォーマンスの問題を引き起こします。
- JHipsterマイクロサービスを生成するときに、キャッシュオプション（「キャッシュの使用」のドキュメントを参照）を選択した場合、これらの呼び出しをキャッシュする固有のCachedUserInfoTokenServicesSpring Beanが生成されます。適切にチューニングされれば、パフォーマンスの問題は解消されます。
- この「ユーザー情報」リクエストに関する詳細が必要な場合は、src/main/resources/application.yml構成ファイル内の標準のSpring Boot構成キーsecurity.oauth2.resource.userInfoUriを使用して構成されます。

自動ドキュメンテーションパーマリンク to "自動ドキュメンテーション"

ゲートウェイは、proxifiesのサービスのSwagger API定義を公開するため、Swagger UIやswagger-codegenなどのすべての有用なツールの恩恵を受けることができます。

ゲートウェイの「admin>API」メニューには、ゲートウェイのAPIと登録されたマイクロサービスのすべてのAPIを示す、固有のドロップダウンリストがあります。

このドロップダウンリストを使用すると、すべてのマイクロサービスAPIが自動的に文書化され、ゲートウェイからテスト可能になります。

セキュアなAPIを使用すると、セキュリティトークンがSwagger UIインタフェースに自動的に追加されるため、すべてのリクエストがすぐに機能するようになります。

レート制限パーマリンク to "レート制限"

これは、Bucket4jとHazelcastを使用して、マイクロサービスのQoSを提供する高度な機能です。

ゲートウェイはレート制限機能を提供するため、RESTリクエストの数を制限できます。

IPアドレスによる制限（匿名ユーザの場合）
ユーザログインによる制限（ログインユーザの場合）

JHipsterは、Bucket4jとHazelcastを使用してリクエスト数を計算し、制限を超えた場合にHTTP 429（過大なリクエストが発生）エラーを送信します。ユーザごとのデフォルトの制限は、1時間あたり100,000 APIコールです。

これは、特定のユーザのリクエストの洪水からマイクロサービスアーキテクチャを保護するための重要な機能です。

ゲートウェイはRESTエンドポイントを保護するため、ユーザのセキュリティ情報に完全にアクセスできるので、ユーザのセキュリティロールに応じて特定のレート制限を提供するように拡張できます。

レート制限を有効にするには、application-dev.ymlまたはapplication-prod.ymlファイルを開き、enabledをtrueに設定します。

jhipster:
    gateway:
        rate-limiting:
            enabled: true

データはHazelcastに格納されるため、Hazelcast分散キャッシュが設定されていれば、ゲートウェイの拡張が可能であり、すぐに動作するはずです。

すべてのゲートウェイには、デフォルトでHazelcastが設定されています。

さらにルールを追加する場合、または既存のルールを変更する場合は、それらをRateLimitingFilterクラスでコーディングする必要があります。変更の例は次のとおりです。

HTTP呼び出しの制限を下げる
1分または1日あたりの制限を追加
“admin”ユーザーの制限をすべて削除

アクセス制御ポリシーパーマリンク to "アクセス制御ポリシー"

デフォルトでは、登録されたすべてのマイクロサービスがゲートウェイを通じて利用可能です。ゲートウェイを通じて公開される特定のAPIを除外する場合は、ゲートウェイ固有のアクセス制御ポリシーフィルタを使用できます。これは、application-*.ymlファイルのjhipster.gateway.authorized-microservices-endpointsキーを使うことで設定可能です。

jhipster:
    gateway:
        authorized-microservices-endpoints: # アクセス制御ポリシー。ルートに対して空のままにすると、すべてのエンドポイントがアクセス可能になります。
            app1: /api,/v2/api-docs # 開発時の推奨設定

たとえば、マイクロサービスbarの/api/fooエンドポイントのみを使用可能にする場合は、次のように入力します。

jhipster:
    gateway:
        authorized-microservices-endpoints:
            bar: /api/foo

JHipster APIゲートウェイ パーマリンク to " JHipster APIゲートウェイ"

サマリー パーマリンク to "サマリー"

アーキテクチャ図 パーマリンク to "アーキテクチャ図"

ゲートウェイを使用したHTTPリクエストのルーティング パーマリンク to "ゲートウェイを使用したHTTPリクエストのルーティング"

セキュリティ パーマリンク to "セキュリティ"