メソッドをオーバーライドし、自動的にプロパティー・ファイルと同期させます。外部ストアと同期させることができます。getメソッドは、ローカルストアが同期していることを確認することができます。setメソッドは、外部ストアをローカルストアと同期し続けることができます。メソッドは、ユーザーをローカルで作成したときに自動的に生成されたIDを常に返すべきだということです。他のインポートではないサンプルが示すように、フェデレーションIDを返すべきではありません。メソッドはローカル・ストレージからユーザーを削除する必要はありません。ランタイムがこの操作を自動的に実行します。ローカル・ストレージから削除される前に呼び出される点に注意してください。ImportedUserValidationインターフェイスこの章の前半で、ユーザーに対するクエリーの機能について説明しました。ローカル・ストレージが最初に照会され、ユーザーがそこで見つかった場合、クエリーは終了します。プロキシーする必要があるので、上記の実装では問題になります。ユーザー・ストレージSPIでは、リンクされたローカルユーザーがローカル・データベースからロードされるたびに、コールバックがあります。メソッドが呼び出されます。ここでは、パラメーターとして渡されたローカルユーザーをプロキシーして返すことができます。ユーザーが外部ストアにまだ存在するかどうかを任意で確認することもできます。返すと、ローカルユーザーはデータベースから削除されます。ImportSynchronizationインターフェイスインポートによる方法を使用すると、ローカルユーザーのコピーが外部ストレージと同期しない可能性があるということがわかります。ユーザーが外部ストアから削除されている可能性があります。model);}このインターフェイスは、プロバイダー・ファクトリーによって実装されます。このインターフェイスがプロバイダー・ファクトリーによって実装されると、管理コンソールのプロバイダーの管理ページに追加のオプションが表示されます。ボタンをクリックして、手動で同期させることができます。メソッドが呼び出されます。追加の設定オプションが表示され、自動的に同期実行が予定されます。メソッドが呼び出されます。ユーザー・キャッシュID、ユーザー名、または電子メールのクエリーによってユーザー・オブジェクトが読み込まれると、キャッシュされます。インターフェイス全体を反復し、この情報をローカルのメモリー内専用キャッシュに保持します。クラスターでは、このキャッシュはまだローカルですが、無効化キャッシュになります。ユーザー・オブジェクトが変更されると、キャッシュは削除されます。このエビクション・イベントはクラスター全体に伝播され、他のノードのユーザー・キャッシュも無効になります。呼び出すことで、ユーザー・キャッシュにアクセスできます。clear();}特定のユーザー、レルムに含まれるユーザー、またはキャッシュ全体を削除するメソッドがあります。OnUserCacheコールバック・インターフェイスプロバイダーの実装に固有の追加情報をキャッシュすることができます。delegate);}このコールバックが必要な場合、プロバイダー・クラスはこのインターフェイスを実装する必要があります。インターフェイスです。これは、ローカル・ストレージにローカルでキャッシュされるインスタンスです。インスタンスを取得することを可能にします。メソッドは、ユーザーに関する追加情報をキャッシュするためのマップを返します。インターフェイスの一部ではありません。メソッドを使ってユーザーのクレデンシャルをキャッシュします。管理コンソールのユーザー・ストレージ・プロバイダーの管理ページで、一意なキャッシュ・ポリシーを指定できます。EEコンポーネント内にパッケージ化することができます。ディレクトリーに格納することができます。ファイルを利用できます。このファイルの詳細については、WildFlyのドキュメントを参照してください。他のきめ細かなアクション間の外部依存関係を引き出すことができます。プロバイダーの実装はプレーンなJavaオブジェクトである必要があります。クラスをステートフルEJBとして実装することもサポートしています。これは、JPAを使用してリレーショナル・ストアに接続する場合に特に便利です。それを行う方法は以下のとおりです。アノテーションを定義して、そこにプロバイダー・クラスを指定する必要があります。これをしないと、EJBはユーザーを正しくプロキシーしないので、プロバイダーは動作しません。メソッドに付与する必要があります。しないと、ステートフルBeanはクリーンアップされず、最終的にエラーメッセージが表示されることがあります。実装はプレーンなJavaオブジェクトである必要があります。ファクトリー・クラスは、create()メソッドでステートフルEJBのJNDIルックアップを実行します。}また、この例では、プロバイダーと同じJAR内にJPAデプロイメントを定義していることを前提としています。ファイルも意味します。JPAを使用する場合、追加のデータソースはXAデータソースでなければなりません。KeycloakデータソースはXAデータソースではありません。同じトランザクションで2つ以上の非XAデータソースと対話する場合、サーバーはエラーメッセージを返します。単一のトランザクションでは、非XAリソースは1つだけ許可されます。XAデータソースのデプロイの詳細については、WildFlyのマニュアルを参照してください。CDIはサポートされていません。APIを使用して、ユーザー・ストレージ・プロバイダーの配備を作成、削除、更新できます。ユーザー・ストレージSPIは汎用コンポーネント・インターフェイスの上に構築されているため、汎用APIを使用してプロバイダーを管理します。RESTコンポーネントAPIは、レルム管理リソースの下にあります。APIのJavaクライアントとの対話のみを示します。使ってこれを行う方法を抽出できます。プロバイダー・タイプ、および設定を指定する必要があります。componentrealmREsource.components().component(component.getId()).remove();以前のユーザー・フェデレーションSPIからの移行この章は、以前の(および現在は削除された)ユーザー・フェデレーションSPIを使用してプロバイダーを実装した場合にのみ適用されます。Sign-Onバージョン7.0は、サポートされていませんが、以前のSPIが利用可能でした。Sign-Onバージョン7.1から削除されました。この章では、このSPIを使用してプロバイダーを作成した場合の、SPIを移植するためのいくつかの方法について説明します。以前のユーザー・フェデレーションSPIでは、Keycloakのデータベース内でユーザーのローカルコピーを作成し、外部ストアからの情報をローカルコピーにインポートする必要がありました。これはもう要件ではなくなりました。以前のプロバイダーをそのまま移植することもできますが、インポートしない方法の方がより良いアプローチになるかを検討する必要があります。インポートによる方法の利点は、以下のとおりです。Keycloakは、基本的に外部ストアの永続ユーザーキャッシュになります。ユーザーがインポートされると、外部ストアにアクセスしなくなり、その負荷が無くなります。公式のユーザーストアをKeycloakにし、従来の外部ストアは廃止する場合、アプリケーションを徐々に移行してKeycloakを使用することができます。すべてのアプリケーションが移行されたら、インポートされたユーザーのリンクを解除し、従来のレガシー外部ストアは廃止します。インポートによる方法の使用には明らかな欠点がいくつかあります。初回のユーザーの検索では、Keycloakのデータベースを複数回更新する必要があります。これは大きなパフォーマンス低下を招き、Keycloakのデータベースに多くの負担をかけることになります。ユーザー・フェデレーティッド・ストレージのアプローチでは、必要に応じて追加のデータのみが保存されるだけであり、外部ストアの機能によってはまったく使用されない可能性もあります。インポートのアプローチでは、ローカルのKeycloakストレージと外部ストレージを同期させておく必要があります。ユーザー・ストレージSPIには、同期をサポートできるために実装できるケーパビリティー・インターフェイスがありますが、これはすぐにやっかいで面倒なものになります。完全なインターフェイスだったということです。このインターフェイスにはすべてのメソッドを実装しました。代わりにこのインターフェイスを、必要に応じて実装可能な複数のケイパビリティー・インターフェイスに分割しています。新しいSPIに完全に同等のものを持ちます。この両者の違いはインポート方法にあります。呼び出す必要はありません。メソッドは存在しません。以前のプロバイダーをそのまま移植する場合は、このインターフェイスを実装します。以前のSPIでは、ローカルユーザーがキャッシュ内にあっても、ユーザーがアクセスされるたびにこのメソッドが呼び出されました。新しいSPIでは、このメソッドはローカルユーザーがローカル・ストレージからロードされたときにのみ呼び出されます。メソッドはまったく呼び出されません。メソッドは、新しいSPIには存在しません。ケーパビリティー・インターフェイスに移動されました。この新しいインターフェイスは実装するためにオプションです。プロバイダーがユーザーの作成と削除をサポートしていない場合は、実装する必要はありません。インターフェイスにカプセル化されました。この実装は任意で、クレデンシャルの検証や更新をサポートするかどうかによって異なります。インターフェイスに移行されました。インターフェイスを実装しないと、プロバイダーが提供するクレデンシャルはKeycloakストレージ内でローカルにオーバーライドされる可能性があることに注意してください。カプセル化されました。このインターフェイスを実装しないと、管理コンソールでユーザーを表示できなくなります。ログインすることはできます。インターフェイスにカプセル化されています。インターフェイスを実装してください。新しいモデルへのアップグレードユーザーストレージSPIインスタンスは、異なる一連のリレーショナル・テーブルに格納されます。Keycloakは自動的に移行スクリプトを実行します。含め、それ以降のストレージモデルにそのまま変換されます。この移行は、以前のユーザー・フェデレーション・プロバイダーと同じプロバイダーID("ldap"、"kerberos"など)を持つユーザー・ストレージ・プロバイダーが存在する場合にのみ発生します。これを知ることにより、取ることができるさまざまなアプローチがあります。以前のKeycloakのデプロイメントで、以前のプロバイダーを削除することができます。これにより、インポートした全ユーザーのローカルリンクされたコピーが削除されます。次に、Keycloakをアップグレードするときに、レルム用に新しいプロバイダーをデプロイして設定するだけです。確認する新しいプロバイダーを実装することです。このプロバイダーがサーバーでデプロイされていることを確認してください。サーバーを起動し、組み込みの移行スクリプトで以前のデータモデルを新しいデータモデルに変換します。この場合、以前にリンクされたインポート済みユーザーは、正常に動作し、すべて同じになります。インポートによる方法を廃止してユーザー・ストレージ・プロバイダーを実装し直すことに決めた場合は、Keycloakをアップグレードする前に以前のプロバイダーを削除することをお勧めします。これにより、インポートされたすべてのユーザーのリンクされたローカル・インポート済みのコピーが削除されます。ストリームベースのインターフェイスKeycloakのユーザー・ストレージ・インターフェイスの多くには、潜在的に大きなオブジェクトのセットを返す可能性のあるクエリーメソッドが含まれているため、メモリー消費と処理時間の点で重大な影響が生じる可能性があります。これは、オブジェクトの内部状態の小さなサブセットのみがクエリーメソッドのロジックで使用される場合に特に当てはまります。サブ・インターフェイスが追加されました。サブ・インターフェイスは、スーパー・インターフェイスの元のコレクションベースのメソッドをストリームベースの異なる形に置き換え、コレクション・ベースのメソッドをデフォルトにします。呼び出し、結果を適切なコレクション・タイプに収集します。サブ・インターフェイスにより、実装はデータセットを処理するためのストリームベースのアプローチにフォーカスし、そのアプローチの潜在的なメモリーとパフォーマンスの最適化から利益を得ることができます。パッケージ内のすべてのインターフェイスと、カスタムストレージ実装のスコープに応じて実装される可能性のあるその他のいくつかのインターフェイス)が含まれます。サブ・インターフェイスを提供するインターフェイスのリストを参照してください。サブ・インターフェイスを実装する必要があります。異形を使用しています。パッケージのボールトSPIを使用できます。プロバイダーは、このSPIの実装の一例です。一般的に、次のルールが適用されます。シークレットがレルム間で漏洩するのを防ぐために、レルムによって取得できるシークレットを隔離または制限したい場合があります。その場合、プロバイダーは、たとえば、エントリーにプレフィックスとしてレルム名を付けるなどして、シークレットを検索するときにレルム名を考慮する必要があります。使用されたかどうかに応じて、一般的に異なるエントリー名に評価されます。インスタンスにレルムを渡す必要があります。実装する必要があります。いずれかでシークレットの表現を保持し、必要に応じて2つの間で変換することを期待されています。以下で説明するように、このバッファーは使用後に破棄されることに注意してください。レルムの分離に関して、すべての組み込みのボールト・プロバイダー・ファクトリーでは、1つ以上のキーリゾルバーを設定できます。式から得られる)を組み合わせて、ボールトからシークレットを取得するために使用される最終的なエントリー名を得るアルゴリズムまたは戦略を実装します。この設定を処理するコードは、抽象ボールト・プロバイダーおよびボールト・プロバイダー・ファクトリー・クラスに抽出されているため、キーリゾルバーのサポートを提供するカスタム実装は、SPIインターフェースを実装する代わりにこれらの抽象クラスを拡張して、シークレットを取得するときに試されるキーリゾルバーを設定する機能を継承できます。カスタム・プロバイダーをパッケージングしてデプロイする方法についての詳細は、サービス・プロバイダー・インターフェイスの章を参照してください。ボールトから取得した値を消費するボールトには機密データが含まれており、Keycloakはそれに応じてシークレットを扱います。シークレットにアクセスすると、シークレットはボールトから取得され、必要な時間だけJVMメモリーに保持されます。その後、JVMメモリーからコンテンツを破棄するすべての可能な試行が行われます。ステートメント内でのみボールト・シークレットを使用することで実現されます。メソッドを直接使用することもできます。)で平文のシークレット(通常はバイト配列)を解釈できる利点があります。オブジェクトは不変であるため、ランダムなガーベージでオーバーライドしてもコンテンツを破棄できないことに注意してください。オブジェクトに保存されたシークレットは少なくとも次のGCラウンドまで存続します。したがって、プレーンなバイト配列と文字配列およびバッファーを使用することをお勧めします。