予備知識
この記事では、マイクロサービス アーキテクチャに基づいた ID 認証とユーザー承認の技術的ソリューションについて説明します。次の知識点をよく理解し、理解しておくことをお勧めします。
- マイクロサービス アーキテクチャに関連する概念: サービス登録、サービス検出、API ゲートウェイ
- ID 認証および認可テクノロジー: SSO、CAS、OAuth2.0、JWT
次の基本概念:
- 認証
- 承認する
- 認証
- 権限制御
前提条件となる背景
エンタープライズ アプリケーション システムの数が徐々に増加すると、各システムは独自のユーザー データを独立して管理し、情報の島になりやすくなり、分散型のユーザー管理モデルがエンタープライズ アプリケーションのプラットフォームへの進化を妨げます。企業のインターネット ビジネスがある程度の規模に発展すると、統一された標準化されたアカウント管理システムの構築が不可欠になります。これは、企業インターネット クラウド プラットフォームの重要なインフラストラクチャであり、アカウント管理、本人認証、ユーザー管理を一元的に行うことができるためです。認証などの基本機能は、クロスシステム シングル サインオンやサードパーティ認証ログインなどの基本機能を企業にもたらし、オープン プラットフォームとビジネス エコシステムを構築するために必要な条件を提供します。
モード紹介
マイクロサービス アーキテクチャの下では、企業のプラットフォーム エコロジーは合理的にビジネスに分割され、各ビジネス セグメントは独自のシステムを形成します。これらのシステム ビジネスは比較的独立しており、独立して分割される必要があります。各システムは独自のビジネスモデルに応じてセグメント化することができ、ビジネスモデルとユーザーニーズを総合的に分析した上で、独立したサービスを形成するために適切なドメインモデルを確立できます。
さらに、エンタープライズ プラットフォームの顧客範囲は、2B ビジネス、2C ビジネス、2G (ガバナンス) など、比較的複雑です。そのため、プラットフォーム レベルでの統一 ID 管理には、組織エンティティと個人エンティティが関与する必要があります。組織エンティティには、代理店 (G) が含まれます。これは、マルチテナント アーキテクチャの概念に似ていますが、従来のマルチテナント アーキテクチャよりも複雑です。
マイクロサービス アーキテクチャにおけるログイン認証の問題
過去のモノリシック アプリケーション アーキテクチャから分散アプリケーション アーキテクチャ、そして現在のマイクロサービス アーキテクチャに至るまで、アプリケーションのセキュリティ アクセスは常にテストされています。アーキテクチャやニーズの変化に適応するために、ID 認証と認証ソリューションは常に更新され、改革されています。数十、さらには数百のマイクロサービス間の呼び出しに直面した場合に、効率的かつ安全な ID 認証を確保するにはどうすればよいでしょうか? 外部サービスアクセスのためのきめ細かい認証ソリューションを提供するにはどうすればよいですか? この記事では、マイクロサービスアーキテクチャにおけるセキュリティ認証と認証スキームについて説明します。
統合アイデンティティマネージャー
Unified Identity Management (UIM) は、プラットフォーム全体のアカウントと権限制御の基盤であり、これを基に構築されたシステムは UIMS (Unified Identity Management System) と呼ばれ、アカウント管理、ID 認証、ユーザー認可、権限制御など、すべての動作を制御します。プラットフォーム下のシステムは、UIMS 処理を通じて、アカウントのパスワード管理、基本的なデータ管理、ロール権限管理などの機能を提供します。
「統一アイデンティティガバナンス」の概念に基づいて、UIMS は 2 レベルのアカウントシステム、基本権限モジュール、基本情報モジュールの 3 つのモジュールに分割できます。このうち、2 レベルのアカウント システムでは、アカウントを組織エンティティ アカウントと個人エンティティ アカウントの 2 つのカテゴリに分類し、個人エンティティは組織エンティティに従属することも、どの組織エンティティにも従属しないこともあり、個人エンティティは複数の組織エンティティに従属することもできます。組織エンティティを同時に管理、基本権限モジュール 各ビジネス システムのリソース権限を一元管理および認可。
基本情報モジュールは、組織エンティティおよび個人エンティティの名前、住所、法人名、氏名、電話番号、性別、その他の個人エンティティの基本情報を記述するために使用されます。UIMS は、さまざまなサブシステムに接続するための統合 API を提供します。多くのシステムやサービスが UIMS に依存します。
この記事では、UIMS の 2 レベルのアカウント システムと基本権限モジュールの 2 つのモジュールについてのみ説明します。これに基づいて、アカウント管理サービスと権限管理サービスを独立して提供することも、1 つのアカウント権限管理に結合することもできます。サービス。アカウント管理サービスには、ビジネス システム エンティティ、組織エンティティ、および個人エンティティの管理が含まれ、権限管理サービスには、認証、承認、および認証の 3 つの部分が含まれます。
シングル サインオン (SSO)
エンタープライズ プラットフォームには多くのサブシステムが含まれており、各サブシステムのユーザー管理を簡素化し、ユーザー エクスペリエンスを向上させるために、統一 ID 認証 (1 回のログイン、すべてのアクセス) の SSO の実現が重要な目標となっています。
- エンタープライズ OA、HR、CRM などの内部システムなどの企業内アプリケーションの場合、SSO は必要なオプションです。
- 外部アプリケーションの場合、SSO はオプションであり、どのアプリケーションを SSO システムに追加する必要があるかは、ビジネス システムによって決定されます。
たとえば、外部モールやプロパティ システムなどの外部サービス システムです。どのようなアプリケーションが SSO を採用するかどうかに関係なく、UIMS は技術的に SSO の機能を備えている必要があります。
許可されたログイン
プラットフォームビジネスが徐々に成長するにつれ、プラットフォームを利用する企業やメーカー、顧客などのリソースがプラットフォームを大きく豊かにするため、ビジネスのさらなる発展を支えるオープンなエコシステムの構築が必要となります。プラットフォーム レベルの認証ログイン機能を開くと、サードパーティ アプリケーションのアクセスが許可されます。サードパーティの承認されたログインを通じて、プラットフォームのサービス機能をサードパーティに開発でき、サードパーティのサービスと機能をプラットフォームに接続して、繁栄、共生、および共通の発展を実現できます。
サービス間認証
業務システムは複数のサービスに分割されており、粒度や業務要件に応じて、サービスの数や権限要件が異なります。マイクロサービス アーキテクチャにおける ID の認証と認可は、次の 2 つのタイプに分類できます。
- 内部サービスの認証と認可。
- 製品サービスや注文サービスなどの内部サービスは、BFF層（Backend For Frontend Layer）でセキュアなイントラネット環境にあり、セキュリティ要件が高くない場合は認証プロセスを実行する必要はありません。サービスは相互に排他的です。信頼。
- 外部サービスの認証と認可。
- 外部サービスの認証と認可は通常、外部アプリケーションによって開始され、リバース プロキシまたはゲートウェイを介してセキュリティ境界内のサービスへのリクエストを開始するため、厳密な認証プロセスを実装する必要があります。ワイヤレス APP、Web クライアント、デスクトップ クライアントなどの外部アプリケーション下のさまざまなサービスはすべて外部サービスです。
技術的ソリューション
オプション
Unified Identity Management System (UIMS) に基づいた ID 認証と認可の主な要件が提示されています。現在、統一された ID 認証と認可を実現するための技術的手段は数多くあり、それらは次の 2 つのカテゴリに要約できます。
- 従来の Cookie + セッション ソリューション、ステートフル セッション モード。
- トークン/チケットベースのソリューション、ステートレス対話モード。
具体的には：
- 分散セッション
- OAuth2.0
- CAS
上記の各オプションには長所と短所があります。
分散セッション
Distributed Session は古くて成熟したソリューションですが、そのステートフルな通信特性とマイクロサービスが提唱する API 指向のステートレス通信のため、相互に競合し、共有ストレージにはセキュリティ上のリスクがあるため、マイクロサービスは一般的には使用されません。
分散セッション
OAuth2.0 は業界で成熟した認証ログイン ソリューションですが、OAuth2.0 はさまざまなシナリオに適応できる 4 つの認証モードを提供し、トークンベースのセキュリティ フレームワークとして、統一された認証が必要なシナリオで広く使用できます。 ID の認証と認可。
JWT は通常、トークンの主要な標準として使用されます: JWT (JSON Web Token) は、簡潔な自己完結型の JSON 宣言仕様であり、その分散ストレージと自己復号化の特性により、非集中型の認証/認可シナリオで広く使用されています。
JWT 情報は署名されているため、送信者の信頼性が保証され、情報が改ざんまたは偽造されていないことが保証されます。ただし、自己完結型のクライアント側署名検証機能により、トークンが一度発行されると取り消すことができないため、JWT を統合 ID 認証および認可ソリューションとして使用するだけでは、統合されたアカウントのログアウトと破棄のニーズを満たすことができません。アカウントの禁止と解除の要件があるため、通常は OAuth2.0 と併用されます。
JWT の導入に関して、CAS は、CAS サーバーと CAS クライアントを含む、現在最も成熟したオープンソース シングル サインオン ソリューションです。
- CAS サーバーは独立して展開する必要がある war パッケージであり、ユーザー認証を担当します。
- CAS クライアントは、クライアントの保護されたリソースへのアクセス要求を処理する役割を担っており、認証が必要な場合にはアクセス要求を CAS サーバーにリダイレクトします。
CAS は柔軟で完全な認証プロセスを定義する認証フレームワークであることに注意してください。ただし、OAuth2、SAML、OpenID などの主流の認証および認可プロトコルと互換性があるため、一般的には CAS + OAuth2 ソリューションが使用されます。 SSO と認証されたログインを実装します。
CAS の概要については、apereo.github.io/ cas/ を参照してください。マイクロサービス アーキテクチャでは、通常、ID 認証とユーザー認可は独立した IDP (Identity Provider) サービスに分離されます。テクノロジーを選択するときは、次の点を考慮する必要があります。
- SSO の技術的ニーズを満たす。
- シンプルさとセキュリティのニーズを満たします。
- オープン性とスケーラビリティのニーズを満たします。
- 総合的に検討した結果、ステートレス API モードを採用することをお勧めします。その中でも OAuth2.0 に基づくソリューションが十分に満足できます。
クライアントトークンソリューション
トークンはクライアント側で生成され、認証サービスによって署名され、すべてのマイクロサービスにわたってユーザーの ID を確立できるように十分な情報が含まれている必要があります。トークンはすべてのリクエストに添付され、マイクロサービスのユーザー認証を提供します。このソリューションのセキュリティは比較的良好ですが、認証ログアウトが大きな問題です。これを軽減する方法としては、有効期間の短いトークンを使用したり、認証サービスを頻繁にチェックしたりすることが考えられます。 。クライアント トークンのエンコード スキームとして、Borsos は JSON Web トークン (JWT) を使用することを好みます。これは十分に単純で、比較的優れたライブラリ サポートを備えています。
APIゲートウェイと組み合わせたクライアントトークン
このスキームは、すべてのリクエストがゲートウェイを通過し、マイクロサービスを事実上隠蔽することを意味します。要求に応じて、ゲートウェイは元のユーザー トークンを内部セッション ID トークンに変換します。この場合、ゲートウェイはログアウト時にユーザーのトークンを取り消すことができるため、ログアウトは問題になりません。
