実装する場合、開発者はユーザーIDの形式を意識している必要があります。フォーマットは以下のとおりでなければなりません。idKeycloakランタイムは、多くの場合、ユーザーIDでユーザーを検索する必要があります。クエリーを発行する必要がありません。プロバイダー・クラスを作成するときにパラメーターとして渡されるので、そこから取得できます。外部IDは、プロバイダー・クラスが外部ストアでユーザーを見つけるために必要な情報です。これは多くの場合、ユーザー名かUIDです。f:332a234e31234:wburkeランタイムがIDによるルックアップを実行すると、コンポーネントIDを取得するためにIDが解析されます。場所を特定するために使用されます。そのプロバイダーにはIDが渡されます。プロバイダーは、外部IDを取得するためにIDを再度解析し、それを外部ユーザー・ストレージにユーザーを配置するために使用します。ファイルを追加する必要があります。実装の完全修飾クラス名の行区切りリストが含まれていなければなりません。簡単な読み取り専用の参照のサンプルユーザー・ストレージSPIの基本実装を示すために、簡単なサンプルで説明します。プロパティー・ファイルには、ユーザー名とパスワードの定義が含まれており、クラスパス上の特定のロケーションにハードコードされています。プロバイダーにより、IDとユーザー名でユーザーを検索し、パスワードを検証することもできるようになります。このプロバイダーに基づくユーザーは、読み取り専用になります。クラスについて説明します。多くのインターフェイスを実装しています。インターフェイスが実装されています。インターフェイスが実装されています。プロパティー・ファイルは読み取り専用です。プロパティー・ファイルへの参照が格納されます。後で、これらをすべて使用します。ロードされたユーザーのマップがあることにも注意してください。ユーザーを見つけるたびに、このマップに保存して、同じトランザクション内でそれを再度作成しないで済むようにします。多くのプロバイダがこれを行う必要があるので、従うことは良い習慣です(つまり、JPAと統合するすべてのプロバイダー)。プロバイダー・クラス・インスタンスは、トランザクション毎に都度作成され、トランザクション完了後にクローズされることも注意してください。メソッドは、ユーザーがログインする際にKeycloakログインページにより呼び出されます。マップを確認して、ユーザーがすでにトランザクション内にロードされているかどうかを確かめます。ロードされていなかった場合、プロパティー・ファイル内でユーザー名を検索します。内にそれを格納し、このインスタンスを返します。基本実装を提供します。これにより、外部IDとしてユーザーのユーザー名を使用する、必須ストレージIDフォーマットに基づいたユーザーIDが自動的に生成されます。すべてのgetメソッドは、nullか空のコレクションを返します。ロールとグループ・マッピングを返すメソッドは、全ユーザーのレルム用に設定されたデフォルトのロールとグループを返します。そのため、管理コンソール内でユーザーを更新しようとすると、エラーが発生します。パラメーターを解析します。パラメーターに埋め込まれたユーザー名を取得するために呼び出されます。メソッドはnullを返します。実装メソッドを見ていきましょう。メソッドは、ランタイムによって呼び出されて、特定のクレデンシャル・タイプがユーザーのために設定されているかどうかを判断します。このメソッドは、パスワードがユーザー用に設定されていることを確認します。メソッドは、特定のクレデンシャル・タイプに対する検証がサポートされているかどうかを返します。あるかどうかを確認します。メソッドはパスワードの検証を担当します。パラメーターは、すべてのクレデンシャル・タイプのための単なる抽象的なインターフェイスです。インスタンスであることも確認します。インスタンスに格納されます。メソッドは、プロパティー・ファイルに格納されているプレーンテキストのパスワードに対してその値を確認します。戻り値は、パスワードが有効であるということを意味します。インターフェイスを実装するのは、ユーザー・パスワードの変更を禁止するためだけです。これをしなければならない理由は、そうしないと、ランタイムによりKeycloakのローカル・ストレージ内でパスワードがオーバーライドできるようになってしまうからです。これについて、詳しくはこの章で後ほど説明します。メソッドは、クレデンシャル・タイプがパスワードであるかどうかを確認するだけです。プロバイダー・ファクトリーの実装プロバイダー・クラスに関しては完了したので、それでは次にプロバイダー・ファクトリー・クラスを見ていきましょう。クラスを実装する際、テンプレート・パラメーターとして具体的なプロバイダー・クラスの実装を渡す必要があるということです。テンプレート・パラメーターを指定しないと、プロバイダーは機能しません。メソッドは、レルム用のユーザー・ストレージ・プロバイダーを有効にする必要がある場合、ランタイム内のファクトリーを識別し、管理コンソールで表示される文字列にもなります。Keycloakが起動すると、各プロバイダー・ファクトリーのインスタンスが1つだけ作成されます。メソッドがこれらのファクトリー・インスタンスでそれぞれ呼び出されます。メソッドも同様にあります。メソッドが呼び出されます。メソッドの実装では、クラスパスからユーザー宣言を含むプロパティー・ファイルを見つけます。フィールドにロードします。パラメーターは、サーバー設定により設定されるファクトリー設定です。次のような引数でサーバーを起動することができます。--spi-storage-readonly-property-file-path=/other-users.propertiesこれをハードコーディングせずに、ユーザー・プロパティー・ファイルのクラスパスを指定することができます。設定を取り込むことができます。クラスを単にアロケートするだけです。このcreateメソッドはトランザクション毎に都度呼び出されます。パッケージ化とデプロイプロバイダー実装のためのクラス・ファイルはjar内に置かれる必要があります。ファイル内でプロバイダー・ファクトリー・クラスを宣言する必要もあります。ページ内で、レルム毎にユーザー・ストレージ・プロバイダーを有効にします。先ほど作成したプロバイダーを一覧から選択します。プロバイダーの設定ページが表示されます。メインページに戻ります。これで、プロバイダーが表示されるようになりました。ファイル内で宣言されたユーザーを使用してログインすることができます。このユーザーは、ログイン後、アカウントページを見ることしかできません。サンプルには少し工夫が必要です。プロバイダーのjarに組み込まれたプロパティー・ファイルにハードコードされていて、これはあまり便利ではありません。プロバイダーのインスタンス毎にこのファイルの場所を設定できるようにすることをお勧めします。このプロバイダーを複数の異なるレルムで複数回再利用して、まったく異なるユーザー・プロパティー・ファイルを指すようにしたい場合があります。この設定は管理コンソールのUI内でも変更できるようにすることをお勧めします。プロバイダーの設定を処理する、実装可能な追加のメソッドがあります。プロバイダーごとに設定したい変数を記述すると、管理コンソールが自動的に汎用入力ページを表示してこの設定を収集します。実装されると、プロバイダーが初めて作成された時、および更新時に、callbackメソッドが設定を保存する前に検証します。インターフェイスからこれらのメソッドを継承します。インスタンスのリストを返します。これらのインスタンスは、プロバイダーの設定変数をそれぞれレンダリングして格納するのに必要なメタデータを宣言します。サンプルを拡張してみましょう。クラスは、設定プロパティーのリストを作成するための優れたヘルパークラスです。ここでは、String型のpathという名前の変数を指定します。