カスタマーアイデンティティおよびアクセス管理（CIAM）とマルチテナンシーのサポート

Keycloak Organization 機能はテクノロジープレビュー機能であり、サーバーの起動時（または最適化されたイメージの構築時）に有効にする必要があります。

上記のコマンドを実行したら、https://#:8080/ でサーバーにアクセスできることを確認し、次の認証情報を使用して管理コンソールにログインしてください。

まず、orgdemo という名前の新しいレルムを作成しましょう。orgdemo レルムは、サードパーティである organizations と統合したいファーストパーティ企業であり、ユーザーは orgdemo レルムで利用可能なクライアントアプリケーションによって提供される保護されたリソースにアクセスできます。

そのため、管理コンソールから名前として orgdemo を使用して新しいレルムを作成します。

次の手順に従うために、orgdemo レルムにいくつかのユーザーも必要です。

mjane ユーザーは、レルム内のどの組織にも一致しないメールアカウントを持つレルムユーザーです。このユーザーを使用して、組織に関連付けられていない orgdemo レルム内の既存のレルムユーザーを表します。そのためには、次のようにユーザーを作成します。

レルムに認証できるように、このユーザーのパスワードを設定してください。

次に、alice@orga.com ユーザーを作成します。このユーザーは、組織に設定されたドメインの 1 つに一致するメールを持つ既存のレルムユーザーとして機能しますが、まだ組織のメンバーではありません。このユーザーは、自己登録を通じて、またはカスタムアイデンティティストアとの統合、あるいはレルムから利用可能なアイデンティティプロバイダーからのフェデレーションによって作成された可能性があります。

レルムに認証できるように、このユーザーのパスワードを設定してください。

レルムが作成されると、認証フローは組織メンバーを認証およびオンボードするための特定の手順を有効にするために自動的に更新されます。更新される認証フローは次のとおりです。

browser フローの主な変更点は、ユーザーが認証情報を求められる前に識別されるように、ID ファーストのログインがデフォルトになることです。first broker login フローに関しては、主な変更点は、組織に関連付けられたアイデンティティプロバイダーを通じて認証し、フローを正常に完了すると、ユーザーを組織メンバーとして自動的に追加することです。

ID ファーストのログインを実行するかどうかの決定は、レルム内の組織の可用性に基づいています。組織がまだ存在しない場合、ユーザーは通常の手順に従って、ユーザー名とパスワード、または browser フローに構成されたその他の手順を使用して認証を行います。

https://#:8080/realms/orgdemo/account にアクセスしてみてください。通常のログインページが表示されます。このページから、次の認証情報を使用して通常どおりレルムに認証できます。

ログインフォームを送信すると、レルムに認証され、ユーザーに代わって動作するクライアントアプリケーション（この場合はアカウントコンソール）に自動的にリダイレクトされます。

次に、orgademo レルムに組織を作成しましょう。そのためには、Realm Settings ページに移動し、Organizations 設定を有効にして、レルムの組織を有効にする必要があります。

組織を有効にすると、メニューの Organizations セクションをクリックできます。Create organization ボタンをクリックして、次のように新しい組織を作成します。

orga 組織が作成されたら、クライアントアプリケーションからサインアウトして、再度ログインしてみてください。この時点で、ID ファーストのログインページが表示されるはずです。

以前の試行とは異なり、orgdemo レルムには組織があり、認証フローは認証情報を求める前にユーザーを識別するように変更されました。

ID ファーストのログインページでは、引き続き mjane ユーザーとして認証できます。ただし、ユーザーは 2 つのステップで認証するようになります。最初のステップではユーザー名またはメールのみが要求され、2 番目のステップでパスワードが提供されます。

再度 https://#:8080/realms/orgdemo/account/ にログインして、bob@orga.com と入力してみてください。orgdemo レルムにはそのメールに関連付けられたアカウントはありません。

存在しないユーザーが組織ドメインに一致するメール ドメインを使用して認証を試みると、ID ファーストのログインページが再度表示され、指定されたユーザー名が無効であることが示されます。この時点で、2 番目のステップでユーザーに認証情報を求める理由はありません。

ユーザーが orgdemo レルムに認証し、最終的に orga 組織に参加できるようにするための方法はいくつかあります。

レルムで自己登録設定が有効になっている場合、ユーザーは ID ファーストのログインページの Register リンクをクリックして、orgdemo レルムにアカウントを作成できます。その後、管理者はユーザーに招待リンクを送信するか、手動で orga 組織のメンバーとして追加できます。

組織にドメインが設定されていないアイデンティティプロバイダーがあり、それらが public としてマークされている場合、ユーザーは ID ファーストのログインページのアイデンティティプロバイダーリンクをクリックして、アイデンティティプロバイダーを通じて認証すると、自動的にアカウントを作成して orga 組織に参加することもできます。

上記と同様に、組織に組織ドメインの 1 つで設定されたアイデンティティプロバイダーがある場合、ユーザーはアイデンティティプロバイダーに自動的にリダイレクトされて認証し、フローが完了すると、自動的にアカウントを作成して orga 組織に参加します。

詳細については、公式ドキュメントをご覧ください。

再度 https://#:8080/realms/orgdemo/account/ にログインして、alice@orga.com と入力してみてください。

以前とは異なり、ユーザーには認証情報を提供する 2 番目のステップが表示されるようになりました。ユーザーが orgdemo レルムに存在することを考えると、ユーザーがまだ組織のメンバーでなくても認証できるはずです。

管理者として、後でユーザーを組織への参加に招待するか、手動で組織に追加することを選択できます。

この機能を使用すると、組織に関連付けられたアイデンティティプロバイダーにドメインを設定できます。これは、特定のメール ドメインを使用するユーザーが常にアイデンティティプロバイダーを通じて認証するようにする場合に役立ちます。

orgdemo レルムのアイデンティティプロバイダーを使用してユーザーをフェデレーションするために、orga レルムを作成しましょう。アイデンティティプロバイダーは orga 組織に関連付けられます。

orga レルムを作成したら、このレルムに OpenID Connect クライアントを次のように作成します。

次に、orgdemo レルムのアイデンティティプロバイダーを使用して後でこのユーザーをフェデレーションできるように、ユーザーを作成します。

レルムに認証できるように、このユーザーのパスワードを設定してください。

次に、orgdemo レルムに OpenID Connect アイデンティティプロバイダーを次のように作成しましょう。

最後に、orgdemo レルムで作成したアイデンティティプロバイダーを orga 組織に関連付け、リンクしましょう。そのためには、メニューの Organizations セクションをクリックし、OrgA Inc 組織を選択します。Identity Providers タブに移動し、Link identity provider ボタンをクリックして、次の設定を入力します。

再度 https://#:8080/realms/orgdemo/account/ にログインして、jdoe@orga.com と入力してみてください。ユーザーは自動的に orga レルムにリダイレクトされて認証されます。

レルムにまだ存在しないユーザーが組織ドメインに一致するメール ドメインを使用して認証を試み、そのドメインが組織に関連付けられたアイデンティティプロバイダーにも設定されている場合、ユーザーは自動的にアイデンティティプロバイダーにリダイレクトされます。

これにより、次の認証情報を使用して orga レルムで認証できるようになります。

ユーザーが認証を完了すると、orgdemo レルムに自動的にリダイレクトされてアカウントが作成され、orga 組織に自動的に参加します。

jdoe@orga.com ユーザーとして再度認証した場合も同様です。ただし、今回はユーザーはすでにアイデンティティプロバイダーにリンクされており、常にアイデンティティプロバイダーを通じて認証されます。

これまでのところ、ユーザーを認証するために orgdemo レルムのアカウントコンソールクライアントを使用してきました。OpenID Connect クライアントとして、アクセストークンは認証が成功した結果として発行されます。

組織のコンテキストで認証する場合、アクセストークンはユーザーがメンバーである組織に関する特定のクレームで自動的に更新されます。

組織固有のクレームをトークンにマッピングするには、クライアントはサーバーに認証リクエストを送信するときに organization スコープをリクエストする必要があります。

その結果、トークンには次のようなクレームが含まれます。

organization クレームは、クライアント（例: ID トークンから）およびリソースサーバー（例: アクセストークンから）が、ユーザーが所属する組織に基づいて保護されたリソースへのアクセスを承認するために使用できます。

organization スコープは、レルムの組み込みのオプションのクライアントスコープです。そのため、デフォルトでは、レルムで作成されたすべてのクライアントに追加されます。