マイクロサービス アーキテクチャ上の SSO。 私たちはKeycloakを使用しています。 パート1

X5 Retail Group も例外ではなく、どのような大企業でも、発展するにつれてユーザーの承認が必要なプロジェクトの数が増加します。 時間の経過とともに、あるアプリケーションから別のアプリケーションへのユーザーのシームレスな移行が必要になり、単一のシングル サインオン (SSO) サーバーを使用する必要が生じます。 しかし、追加の属性を持たない AD などの ID プロバイダーがすでにさまざまなプロジェクトで使用されている場合はどうなるでしょうか。 「識別ブローカー」と呼ばれる一種のシステムが助けになります。 最も機能的なのは、Keycloak、Gravitee アクセス管理などの代表的なものです。ほとんどの場合、マシンの対話、ユーザーの参加など、ユースケースはさまざまです。ソリューションは、すべての要件を XNUMX つに結合できる柔軟でスケーラブルな機能をサポートする必要があります。そしてそのようなソリューションとして、当社には現在、インディケーションブローカーであるKeycloakが存在します。

Keycloak は、RedHat によって管理されているオープンソースの ID およびアクセス制御製品です。 これは、SSO (RH-SSO) を使用する同社製品の基礎です。

コンセプト

ソリューションとアプローチに取り組み始める前に、プロセスの用語と順序を決定する必要があります。

識別 これは、サブジェクトをその識別子 (つまり、名前、ログイン、または番号の定義) によって認識するための手順です。

認証 - これは認証手順です (ユーザーはパスワードでチェックされ、レターは電子署名でチェックされます)。

承認 - これは、リソース (電子メールなど) へのアクセスの提供です。

ID ブローカー Keycloak

キークローク は、マイクロサービス アーキテクチャ パターンを使用できる IS で使用するために設計されたオープン ソースの ID およびアクセス管理ソリューションです。

Keycloakは、シングル・サインオン（SSO）、仲介型IDおよびソーシャル・ログイン、ユーザー・フェデレーション、クライアント・アダプター、管理コンソール、アカウント管理コンソールなどの機能を提供します。

Keycloakでサポートされる基本機能:

• ブラウザ アプリケーションのシングル サインオンとシングル サイン アウト。
• OpenID/OAuth 2.0/SAML のサポート。
• ID ブローカリング - 外部の OpenID Connect または SAML ID プロバイダーを使用した認証。
• ソーシャル ログイン – ユーザー識別のための Google、GitHub、Facebook、Twitter のサポート。
• ユーザー フェデレーション - LDAP サーバー、Active Directory サーバー、および他の ID プロバイダーからのユーザーの同期。
• Kerberos ブリッジ - 自動ユーザー認証に Kerberos サーバーを使用します。
• 管理コンソール - Web 経由で設定とソリューション オプションを一元管理します。
• アカウント管理コンソール - ユーザー プロファイルの自己管理用。
• 企業のコーポレートアイデンティティに基づいたソリューションのカスタマイズ。
• 2FA 認証 - Google Authenticator または FreeOTP を使用した TOTP/HOTP のサポート。
• ログイン フロー - ユーザーの自己登録、パスワードの回復とリセットなどが可能です。
• セッション管理 - 管理者はユーザー セッションを XNUMX つのポイントから管理できます。
• トークン マッパー - ユーザー属性、ロール、その他の必須属性をトークンにバインドします。
• レルム、アプリケーション、ユーザー全体にわたる柔軟なポリシー管理。
• CORS サポート - クライアント アダプターには CORS サポートが組み込まれています。
• サービス プロバイダー インターフェイス (SPI) - 認証フロー、アイデンティティ プロバイダー、プロトコル マッピングなど、サーバーのさまざまな側面をカスタマイズできる多数の SPI。
• JavaScript アプリケーション、WildFly、JBoss EAP、Fuse、Tomcat、Jetty、Spring 用のクライアントアダプター。
• OpenID Connect Relying Party ライブラリまたは SAML 2.0 Service Provider Library をサポートするさまざまなアプリケーションの操作のサポート。
• プラグインを使用して拡張可能。

CI / CD プロセスおよび Keycloak での管理プロセスの自動化には、REST API / JAVA API を使用できます。 ドキュメントは電子的に入手できます。

REST API https://www.keycloak.org/docs-api/8.0/rest-api/index.html
Java API https://www.keycloak.org/docs-api/8.0/javadocs/index.html

エンタープライズ ID プロバイダー (オンプレミス)

ユーザー フェデレーション サービスを通じてユーザーを認証する機能。

パススルー認証も使用できます。ユーザーがKerberos (LDAPまたはAD)を使用してワークステーションに対して認証する場合、ユーザー名とパスワードを再度入力することなく、Keycloakに対して自動的に認証されます。

ユーザーの認証とさらなる認可には、プロジェクトの初期段階で時間のかかる設定や統合を必要としないため、開発環境に最も適したリレーショナル DBMS を使用できます。 デフォルトでは、Keycloakは組み込みDBMSを使用して設定とユーザーデータを保存します。

サポートされている DBMS のリストは多岐にわたり、MS SQL、Oracle、PostgreSQL、MariaDB、Oracle などが含まれます。 これまでに最もテストされたのは、Oracle 12C Release1 RAC と MariaDB 3.12 の Galera 10.1.19 クラスターです。

ID プロバイダー - ソーシャル ログイン

SNSからのログインも可能です。 ユーザーを認証する機能を有効にするには、Keycloack 管理コンソールを使用します。 アプリケーション コードを変更する必要はなく、この機能はすぐに使用でき、プロジェクトのどの段階でもアクティブ化できます。

ユーザー認証に OpenID/SAML ID プロバイダーを使用することができます。

KeycloakでOAuth2を使用する一般的な認可シナリオ

認可コードの流れ - サーバー側アプリケーションで使用されます。 アプリケーションのソース コードとクライアント データを部外者が利用できないサーバー アプリケーションに適しているため、最も一般的なタイプの承認権限の XNUMX つです。 この場合のプロセスはリダイレクトに基づいています。 アプリケーションは、ユーザー エージェントを通じてリダイレクトされた API 認証コードを受信するために、Web ブラウザーなどのユーザー エージェント (ユーザー エージェント) と対話できる必要があります。

暗黙的なフロー - モバイルまたは Web アプリケーション (ユーザーのデバイス上で実行されるアプリケーション) によって使用されます。

暗黙的承認パーミッション タイプは、クライアントの機密性が保証できないモバイル アプリケーションや Web アプリケーションで使用されます。 暗黙的なアクセス許可の種類では、ユーザー エージェントのリダイレクトも使用されます。これにより、アプリケーションでさらに使用するために、アクセス トークンがユーザー エージェントに渡されます。 これにより、ユーザーおよびユーザーのデバイス上の他のアプリケーションがトークンを利用できるようになります。 このタイプの承認権限はアプリケーションの ID を認証せず、プロセス自体はリダイレクト URL (事前にサービスに登録されている) に依存します。

インプリシット フローは、アクセス トークンのリフレッシュ トークンをサポートしません。

クライアント認証情報の付与フロー — アプリケーションが API にアクセスするときに使用されます。 このタイプの承認権限は通常、ユーザーとの即時対話なしでバックグラウンドで実行する必要があるサーバー間の対話に使用されます。 クライアント資格情報付与フローを使用すると、Web サービス (機密クライアント) が、別の Web サービスを呼び出すときに認証のためにユーザーになりすますのではなく、独自の資格情報を使用できるようになります。 より高いレベルのセキュリティを実現するために、呼び出し側サービスが資格情報として (共有シークレットの代わりに) 証明書を使用することが可能です。

OAuth2 仕様については、以下で説明されています。
RFC-6749
RFC-8252
RFC-6819

JWTトークンとその利点

JWT (JSON Web Token) はオープン標準です (https://tools.ietf.org/html/rfc7519) は、関係者間で情報を JSON オブジェクトとして安全に転送するためのコンパクトで自己完結型の方法を定義します。

標準によれば、トークンは、ドットで区切られた Base-64 形式の XNUMX つの部分で構成されます。 最初の部分はヘッダーと呼ばれ、トークンの種類とデジタル署名を取得するためのハッシュ アルゴリズムの名前が含まれます。 XNUMX 番目の部分には、基本情報 (ユーザー、属性など) が格納されます。 XNUMX 番目の部分はデジタル署名です。

。 。
トークンを DB に保存しないでください。 有効なトークンはパスワードと同等であるため、トークンを保存することは、パスワードをクリア テキストで保存することと同じです。
アクセストークン 所有者に安全なサーバー リソースへのアクセスを許可するトークンです。 通常、有効期間は短く、トークンを要求している当事者の IP アドレスなどの追加情報が含まれる場合があります。

リフレッシュトークン 有効期限が切れた後にクライアントが新しいアクセス トークンを要求できるようにするトークンです。 これらのトークンは通常、長期間発行されます。

マイクロサービス アーキテクチャで使用する主な利点は次のとおりです。

• ワンタイム認証でさまざまなアプリケーションやサービスにアクセスできます。
• ユーザー プロファイルに多数の必須属性が存在しない場合は、自動化されたものやオンザフライで行われるものなど、ペイロードに追加できるデータで強化することができます。
• アクティブなセッションに関する情報を保存する必要はなく、サーバー アプリケーションは署名を検証するだけで済みます。
• ペイロード内の追加属性による、より柔軟なアクセス制御。
• ヘッダーとペイロードにトークン署名を使用すると、ソリューション全体のセキュリティが向上します。

JWT トークン - 構成

タイトル - デフォルトでは、ヘッダーにはトークンのタイプと暗号化に使用されるアルゴリズムのみが含まれます。

トークンのタイプは「typ」キーに格納されます。 JWT では「type」キーは無視されます。 「typ」キーが存在する場合、このオブジェクトが JSON Web トークンであることを示すために、その値は JWT である必要があります。

256 番目のキー「alg」は、トークンの暗号化に使用されるアルゴリズムを定義します。 デフォルトでは HS64 に設定されている必要があります。 ヘッダーはbaseXNUMXでエンコードされます。

{ "alg": "HS256", "type": "JWT"}
ペイロード (コンテンツ) — ペイロードには、検証が必要な情報が保存されます。 ペイロード内の各キーは「ステートメント」として知られています。 たとえば、招待制（クローズドプロモーション）のみで応募することもできます。 誰かを参加に招待したいときは、招待状を送ります。 電子メール アドレスが招待を受け入れた人のものであることを確認することが重要です。そのため、このアドレスをペイロードに含めます。このため、「電子メール」キーに保存します。

{ "Eメール"： "[メール保護]" }

ペイロード内のキーは任意です。 ただし、予約されているものがいくつかあります。

• iss (発行者) - トークンの送信元のアプリケーションを識別します。
• sub (件名) - トークンの件名を定義します。
• aud (Audience) は、このトークンの受信者のリストである、大文字と小文字を区別する文字列または URI の配列です。 受信側は、指定されたキーを持つ JWT を受信すると、受信者にそれ自体が存在するかどうかを確認する必要があります。そうでない場合は、トークンを無視します。
• exp (有効期限) - トークンの有効期限がいつ切れるかを示します。 JWT 標準では、そのすべての実装で期限切れのトークンを拒否することが要求されます。 exp キーは、UNIX 形式のタイムスタンプである必要があります。
• nbf (Not Before) は、トークンが有効になる瞬間を決定する UNIX 形式の時刻です。
• iat (発行時刻) - このキーはトークンが発行された時刻を表し、JWT の経過時間を決定するために使用できます。 iat キーは、UNIX 形式のタイムスタンプである必要があります。
• Jti (JWT ID) — このトークンの一意の識別子を定義する文字列。大文字と小文字は区別されます。

ペイロードは暗号化された形式で送信されないことを理解することが重要です (ただし、トークンをネストすることができ、暗号化されたデータを送信することは可能です)。 したがって、秘密情報を保存することはできません。 ヘッダーと同様に、ペイロードは Base64 でエンコードされます。
署名 - タイトルとペイロードがあれば、署名を計算できます。

Base64 エンコード: ヘッダーとペイロードが取得され、ドットを介して文字列に結合されます。 次に、この文字列と秘密キーが、ヘッダーで指定された暗号化アルゴリズム (「alg」キー) に入力されます。 キーには任意の文字列を指定できます。 拾うまでに時間がかかるため、長い弦が最も好まれます。

{"alg":"RSA1_5","ペイロード":"A128CBC-HS256"}

Keycloakフェイルオーバー・クラスター・アーキテクチャの構築

すべてのプロジェクトに単一のクラスターを使用する場合、SSO ソリューションの要件が増加します。 プロジェクトの数が少ない場合、これらの要件はすべてのプロジェクトでそれほど顕著ではありませんが、ユーザーと統合の数が増加すると、可用性とパフォーマンスの要件が増加します。

単一の SSO 障害のリスクが増加すると、ソリューション アーキテクチャの要件と冗長コンポーネントに使用される方法が増加し、SLA が非常に厳しくなります。 この点で、多くの場合、ソリューションの開発または実装の初期段階では、プロジェクトには独自の非フォールト トレラント インフラストラクチャが存在します。 開発が進むにつれて、開発と拡張の機会を設ける必要があります。 コンテナ仮想化またはハイブリッド アプローチを使用してフェールオーバー クラスターを構築するのが最も柔軟です。

アクティブ/アクティブ クラスタ モードおよびアクティブ/パッシブ クラスタ モードで動作するには、リレーショナル データベース内のデータの一貫性を確保する必要があります。両方のデータベース ノードが、地理的に分散された異なるデータ センター間で同期してレプリケートされる必要があります。

フォールト トレラントなインストールの最も単純な例。

単一クラスターを使用する利点は次のとおりです。

• 高い可用性とパフォーマンス。
• 動作モードのサポート: アクティブ/アクティブ、アクティブ/パッシブ。
• 動的にスケーリングする機能 - コンテナ仮想化を使用する場合。
• 一元的な管理と監視が可能。
• プロジェクト内のユーザーの識別/認証/認可のための統合アプローチ。
• ユーザーの関与なしで、異なるプロジェクト間でより透明性の高い対話が可能になります。
• さまざまなプロジェクトで JWT トークンを再利用する機能。
• 単一の信頼点。
• マイクロサービス/コンテナ仮想化を使用してプロジェクトをより迅速に起動します (追加のコンポーネントを持ち上げて構成する必要はありません)。
• ベンダーから商用サポートを購入することができます。

クラスターを計画するときに注意すべきこと

DBMS

Keycloakはデータベース管理システムを使用して、レルム、クライアント、ユーザーなどを保存します。
MS SQL、Oracle、MySQL、PostgreSQL など、幅広い DBMS がサポートされています。 Keycloakには独自の組み込みリレーショナルデータベースが付属しています。 開発環境など、ロードされていない環境で使用することをお勧めします。

アクティブ/アクティブ クラスタ モードおよびアクティブ/パッシブ クラスタ モードで動作するには、リレーショナル データベース内のデータの一貫性が必要であり、両方のデータベース クラスタ ノードがデータ センター間で同期してレプリケートされます。

分散キャッシュ (Infinspan)

クラスターが正しく機能するには、JBoss Data Grid を使用して次のタイプのキャッシュを追加同期する必要があります。

認証セッション - 特定のユーザーを認証するときにデータを保存するために使用されます。 このキャッシュからのリクエストには通常、ブラウザーとKeycloakサーバーのみが含まれ、アプリケーションは含まれません。

アクション トークンは、ユーザーがアクションを非同期的に (電子メール経由で) 確認する必要があるシナリオで使用されます。 たとえば、パスワードを忘れた場合のフロー中、actionTokens Infinispan キャッシュは、既に使用されている関連アクション トークンに関するメタデータを追跡するために使用されるため、再利用することはできません。

永続データのキャッシュと無効化 - データベースへの不必要なクエリを回避するために永続データをキャッシュするために使用されます。 いずれかのKeycloakサーバーがデータを更新すると、すべてのデータセンター内の他のすべてのKeycloakサーバーがそれを認識する必要があります。

作業 - クラスター ノードとデータ センター間で無効なメッセージを送信するためにのみ使用されます。

ユーザー セッション - ユーザーのブラウザ セッションの間有効なユーザー セッションに関するデータを保存するために使用されます。 キャッシュは、エンド ユーザーおよびアプリケーションからの HTTP リクエストを処理する必要があります。

ブルート フォース保護 - 失敗したログインに関するデータを追跡するために使用されます。

負荷分散

ロード バランサーは Keycloak への単一のエントリ ポイントであり、スティッキー セッションをサポートする必要があります。

アプリケーションサーバー

これらはコンポーネント間の相互作用を制御するために使用され、既存の自動化ツールやインフラストラクチャ自動化ツールの動的なスケーリングを使用して仮想化またはコンテナ化できます。 OpenShift、Kubernates、Rancher での最も一般的なデプロイメント シナリオ。

これで最初の部分、つまり理論的な部分が完了しました。 次の一連の記事では、さまざまな ID プロバイダーとの統合例と設定例を分析します。

出所： habr.com