5.11. ユーザープロファイルの定義
Red Hat Single Sign-On では、ユーザーは属性セットに関連付けられます。これらの属性は、Red Hat Single Sign-On 内でユーザーの説明や識別のために使用され、これらに関する追加情報をアプリケーションに渡すのに使用されます。
ユーザープロファイルは、ユーザー属性とレルム内で管理する方法を表す明確に定義されたスキーマを定義します。ユーザー情報に対する一貫したビューを提供することで、管理者は属性の管理方法に関するさまざまな要素を制御したり、Red Hat Single Sign-On を拡張して追加の属性をサポートするのがより簡単になります。
他の機能の中で、管理者は以下を行うことができます。
- ユーザー属性のスキーマを定義できます。
- コンテキスト情報に基づいて属性が必要なかどうかを定義します (例: ユーザーまたは管理者に必要となる場合、または両方の場合、または要求されるスコープに応じて)。
- ユーザー属性を表示および編集するための特定のパーミッションを定義してください。これにより、一部の属性が表示できないか、3 番目の部分 (管理者を含む) によって変更されない、強力なプライバシー要件に準拠することができます。
- ユーザープロファイルのコンプライアンスを動的に実施して、ユーザー情報が常に、属性に関連付けられたメタデータとルールに準拠します。
- 組み込みバリデーターを利用するか、カスタムレジストリーを書き込むことで、属性ごとに検証ルールを定義します。
- 属性の定義やそれらを手動で変更しなくても、ユーザーがアカウントコンソール内の登録、更新プロファイル、ブローカー、個人情報などと対話するフォームを動的にレンダリングします。
ユーザープロファイルの機能は、ユーザープロファイル SPI によってサポートされます。デフォルトでは、これらの機能は無効になり、レルムは、レガシー動作と後方互換性を維持するデフォルト設定を使用するよう設定されます。
レガシーの動作は、カスタム属性の管理方法に制限なく、ユーザー名、メール、最初、および姓などのユーザールート属性を管理する際に、Red Hat Single Sign-On が使用するデフォルトの制約を維持することです。登録、プロファイル更新、ブローカー、およびアカウントコンソールを介したアカウントフローなどのユーザーフローについては、ユーザーが上記の属性を変更できるように、上記の属性を使用するように制限されています。
Red Hat Single Sign-On をすでに使用している場合は、レガシー動作がこれまでに使用している内容になります。
宣言的プロバイダーは、レガシーの動作とは異なるため、管理コンソールと明確に定義された JSON スキーマを使用して、レルムにユーザープロファイル設定を定義する柔軟性が非常に高くなります。
次のセクションでは、宣言型プロバイダーを使用して独自のユーザープロファイル設定を定義する方法を説明します。
今後は、Red Hat Single Sign-On ではレガシー動作のサポートがなくなりました。理想的には、ユーザープロファイルが提供する新機能を確認し、それに応じてレルムを移行する必要があります。
5.11.1. ユーザープロファイルの有効化
宣言型ユーザープロファイルは テクノロジープレビュー であるため、完全にサポートされていません。この機能はデフォルトで無効になっています。
--Dkeycloak.profile=preview
または -Dkeycloak.profile.feature.declarative_user_profile=enabled
でサーバーを起動できるようにするには、以下を実行します。詳細は、Profiles を参照してください。
declarative_user_profile
機能を有効にする他に、レルムのユーザープロファイルを有効にする必要があります。これには、左側のメニューの Realm Settings
リンクをクリックし、User Profile Enabled
スイッチを有効にします。
有効化して Save
ボタンをクリックすると、ユーザー属性の設定を管理できる User Profile
にアクセスできます。
レルムのユーザープロファイルを有効にすると、Red Hat Single Sign-On は、ユーザープロファイル設定に基づいて属性の管理方法に追加の制約を指定します。つまり、以下は、この機能が有効な場合に予想される内容のリストです。
-
管理の観点からは、ユーザー詳細ページの
Attributes
タブに、ユーザープロファイル設定で定義された属性のみが表示されます。属性管理時には、属性ごとに定義された条件も考慮されます。 - アカウントコンソールにおける登録、更新プロファイル、ブローカー、個人情報などのユーザー向けフォームは、ユーザープロファイルの設定に基づいて動的にレンダリングされます。そのため、Red Hat Single Sign-On は異なるテンプレートに依存して、これらのフォームを動的にレンダリングします。
次のトピックでは、ユーザープロファイル設定を管理する方法と、レルムへの影響を説明します。
5.11.2. ユーザープロファイルの管理
ユーザープロファイル設定は、レルムごとに管理されます。これには、左側のメニューで Realm Settings
リンクをクリックし、User Profile
タブをクリックします。
ユーザープロファイルタブ
Attributes
サブタブでは、現在ユーザープロファイルに関連付けられている属性のリストがあります。デフォルトでは、設定はユーザー root 属性に基づいて作成され、各属性は検証およびパーミッションに関してデフォルトで設定されます。
Attribute Groups
サブタブで、属性グループを管理できます。属性グループを使用すると、ユーザーに表示されるフォームをレンダリングする際に属性を関連付けることができます。
現在、属性グループはレンダリング目的でのみ使用されますが、今後はリンク先の属性へのトップレベル設定の定義も有効にする必要があります。
JSON Editor
サブタブで、明確に定義された JSON スキーマを使用して設定を表示および編集できます。他のタブで表示される JSON 設定に反映されたときに、変更を加えます。
次のセクションでは、Attributes
サブタブで設定を管理する方法を学びます。
5.11.3. 属性の管理
Attributes
サブタブで、ユーザープロファイルに関連する属性を作成、編集、および削除できます。
新しい属性を定義してユーザープロファイルに関連付けるには、属性リストの右上にある Create
ボタンをクリックします。
属性設定
属性の設定時に、以下の設定を定義できます。
- 名前
- 属性の名前。
- 表示名
- 属性のユーザーフレンドリーな名前。主にユーザーに表示されるフォームをレンダリングする場合に使用されます。これは国際化をサポートするため、メッセージバンドルから値をロードできるようにします。
- 属性グループ
- 属性が属する属性グループ (ある場合)。
- スコープを指定した場合に有効化
- 属性を動的に有効化するためにスコープのリストを定義します。設定されていない場合、属性は常に有効になり、ユーザーに表示されるフォームをレンダリングする際に、ユーザープロファイルの管理時に常にその制約が強制されます。そうしないと、リスト内のスコープのいずれかがクライアントによって要求される場合にのみ、同じ制約が適用されます。
- 必須/任意
- 必要に応じて属性を設定します。有効でなければ、属性は任意です。それ以外の場合は、ユーザーおよび管理者が属性を提供する必要があります。また、必須の属性も、クライアントが必要とするスコープをベースにする必要があります。
- Permission
- このセクションでは、ユーザーおよび管理者の読み取りおよび書き込みパーミッションを定義できます。
- 検証
- 本セクションでは、属性値を管理する際に実行される検証を定義できます。Red Hat Single Sign-On は、独自の追加の可能性から選択できる組み込みバリデーターのセットを提供します。
- アノテーション
- このセクションでは、アノテーションを属性に関連付けることができます。アノテーションは、レンダリングの目的で追加のメタデータをフロントエンドに渡すのに役立ちます。
5.11.3.1. パーミッションの管理
Permission
セクションで、アクセスユーザーおよび管理者が属性の読み書きレベルを定義できます。
属性パーミッション
そのためには、以下の設定を使用できます。
- ユーザー表示可能か ?
- 有効にすると、属性を表示できます。それ以外の場合は、ユーザーは属性にアクセスできません。
- ユーザーを編集可能か ?
- 有効にすると、ユーザーは属性を表示および編集できます。それ以外の場合は、ユーザーは属性への書き込み権限がありません。
- 管理者ビューはどれですか ?
- 有効にすると、管理者は属性を表示できます。それ以外の場合は、管理者は属性にアクセスできません。
- 管理者を編集可能か ?
- 有効にすると、管理者は属性を表示および編集できます。それ以外の場合は、管理者は属性への書き込み権限がありません。
属性を作成すると、属性にパーミッションが設定されません。実質的には、ユーザーまたは管理者にも属性はアクセスできません。属性を作成したら、ターゲット対象者のみが属性を表示できるように、パーミッションを設定します。
パーミッションには、属性の管理方法とユーザーに表示される形式で属性の管理方法に直接影響があります。
たとえば、ユーザーが属性を表示可能とすると、管理コンソールを介してユーザーを管理する場合 (ユーザー API からも)、管理者は属性にアクセスできません。また、プロファイルの更新時には属性を変更できません。ユーザー属性が既存のアイデンティティーストア (フェデレーション) から取得され、ソースアイデンティティーストア以外の属性を更新せずに属性をユーザーに表示される場合に、興味のある設定。
同様に、ユーザーの読み取り専用アクセスを持つ管理者に対してのみ、属性を書き込み可能としてマークすることもできます。この場合、属性の管理は管理者のみが許可されます。
プライバシーの要件によっては、管理者にもアクセスできるが、ユーザーの読み取り/書き込みパーミッションで属性にアクセスすることが望ましい場合があります。
ユーザープロファイル設定に新しい属性を追加する場合は必ず、適切なパーミッションを設定してください。
5.11.3.2. 検証の管理
Validation
セクションで、異なる形式の検証から選択し、属性値が特定のルールに準拠することを確認できます。
属性の検証
Red Hat Single Sign-On は、追加設定なしで異なるバリデーターを提供します。
Name | 説明 | 設定 |
---|---|---|
length | 最小と最大長に基づいて文字列値の長さを確認します。 | min: 許容される最小長を定義する整数。 max: 許容される最大長を定義する整数。 trim-disabled: 検証前に値がトリミングされるかどうかを定義するブール値。 |
integer | 値が整数であり、下限または上限の範囲内にあるかどうかを確認します。範囲が定義されていない場合、バリデーターは、値が有効な数字のみを確認します。 | Min: 小さい範囲を定義する整数。 max: 上限を定義する整数。 |
double | 値が二重で、下層または上位の範囲内であるかどうかを確認します。範囲が定義されていない場合、バリデーターは、値が有効な数字のみを確認します。 | Min: 小さい範囲を定義する整数。 max: 上限を定義する整数。 |
uri | 値が有効な URI かどうかを確認します。 | なし |
pattern | 値が特定の RegEx パターンと一致するかどうかを確認します。 | パターン: 値の検証時に使用する RegEx パターン。 error-message: i18n バンドルのエラーメッセージのキー。設定されていない場合には、汎用メッセージが使用されます。 |
| 値が有効なメールアドレスの形式かどうかを確認します。 | なし |
local-date | レルムまたはユーザーロケールに基づいて、値が有効な形式かどうかを確認します。 | なし |
person-name-prohibited-characters | 値がスクリプトインジェクションなどの攻撃にもう 1 つのバリアとして有効な人名であるかを確認します。検証は、デフォルト RegEx パターンをベースとしています。このパターンでは、文字が人名では一般的ではありません。 | error-message: i18n バンドルのエラーメッセージのキー。設定されていない場合には、汎用メッセージが使用されます。 |
username-prohibited-characters | 値がスクリプトインジェクションなどの攻撃のためにもう 1 つのバリアとして有効なユーザー名であるかを確認します。検証は、ユーザー名に共通の文字をブロックするデフォルトの RegEx パターンに基づいています。 | error-message: i18n バンドルのエラーメッセージのキー。設定されていない場合には、汎用メッセージが使用されます。 |
options | 値が許可された値の定義されたセットからのものであるかどうかを確認してください。選択フィールドと複数選択フィールドから入力された値を検証するのに便利です。 | options: 許可された値を含む文字列の配列。 |
5.11.3.2.1. アノテーションの管理
フロントエンドに追加情報を渡すには、属性をレンダリングする方法を決定するアノテーションで属性を切り分けることができます。この機能は、Red Hat Single Sign-On を拡張して、属性に関連付けられたアノテーションに基づいて動的にページをレンダリングする場合に便利です。このメカニズムは、たとえば 属性に Form input filed を設定するため に使用されます。
属性アノテーション
5.11.4. 属性グループの管理
属性グループ
サブタブで、属性グループを作成、編集、および削除できます。属性グループを使用すると、相関属性のコンテナーを定義でき、ユーザーに表示されるフォームで一緒にレンダリングできます。
属性グループリスト
属性にバインドされる属性グループを削除できません。そのため、最初に属性を更新してバインディングを削除する必要があります。
新規グループを作成するには、属性グループリストの右上にある Create
ボタンをクリックします。
属性グループ設定
グループを設定する際に、以下の設定を定義できます。
- 名前
- グループの名前。
- 表示名
- グループのユーザーフレンドリーな名前。主にユーザーに表示されるフォームをレンダリングする場合に使用されます。これは国際化をサポートするため、メッセージバンドルから値をロードできるようにします。
- 説明の表示
- ユーザーに表示されるフォームをレンダリングする際にツールチップとして表示されるユーザーフレンドリーなテキストです。
- アノテーション
- このセクションでは、アノテーションを属性に関連付けることができます。アノテーションは、レンダリングの目的で追加のメタデータをフロントエンドに渡すのに役立ちます。
5.11.5. JSON 設定の使用
ユーザープロファイル設定は、明確に定義された JSON スキーマを使用して保存されます。JSON Editor
サブタブで直接ユーザープロファイル設定の編集を選択できます。
JSON 設定
JSON スキーマは以下のように定義されます。
{ "attributes": [ { "name": "myattribute", "required": { "roles": [ "user", "admin" ], "scopes": [ "foo", "bar" ] }, "permissions": { "view": [ "admin", "user" ], "edit": [ "admin", "user" ] }, "validations": { "email": {}, "length": { "max": 255 } }, "annotations": { "myannotation": "myannotation-value" } } ], "groups": [ { "name": "personalInfo", "displayHeader": "Personal Information" } ] }
{
"attributes": [
{
"name": "myattribute",
"required": {
"roles": [ "user", "admin" ],
"scopes": [ "foo", "bar" ]
},
"permissions": {
"view": [ "admin", "user" ],
"edit": [ "admin", "user" ]
},
"validations": {
"email": {},
"length": {
"max": 255
}
},
"annotations": {
"myannotation": "myannotation-value"
}
}
],
"groups": [
{
"name": "personalInfo",
"displayHeader": "Personal Information"
}
]
}
スキーマは、必要な数の属性をサポートします。
属性ごとに、name
、オプションで required
、permission
、および annotations
設定を定義する必要があります。
5.11.5.1. 必須プロパティー
required
設定は、属性が必要であるかどうかを定義します。Red Hat Single Sign-On では、異なる条件に基づいて必要に応じて属性を設定することができます。
required
設定が空のオブジェクトとして定義されている場合には、属性は常に必要になります。
{ "attributes": [ { "name": "myattribute", "required": {} ] }
{
"attributes": [
{
"name": "myattribute",
"required": {}
]
}
一方、ユーザーまたは管理者または両方に必要な属性の作成を選択できます。また、Red Hat Single Sign-On での認証時に、特定のスコープが要求される場合にのみ属性にマークを付けます。
ユーザーや管理者の必要に応じて属性にマークを付けるには、roles
プロパティーを以下のように設定します。
{ "attributes": [ { "name": "myattribute", "required": { "roles": ["user"] } ] }
{
"attributes": [
{
"name": "myattribute",
"required": {
"roles": ["user"]
}
]
}
roles
プロパティーは、user
または admin
によって属性が必要であるかどうかによって、値がユーザーまたは admin のいずれかである配列を想定します。
同様に、ユーザーの認証時に 1 つ以上のスコープのセットがクライアントによって要求される場合に、属性の作成を選択できます。そのため、以下のように scopes
プロパティーを使用できます。
{ "attributes": [ { "name": "myattribute", "required": { "scopes": ["foo"] } ] }
{
"attributes": [
{
"name": "myattribute",
"required": {
"scopes": ["foo"]
}
]
}
scopes
プロパティーは、クライアントスコープを表す任意の文字列を持つことができます。
5.11.5.2. パーミッションプロパティー
属性レベルの permissions
プロパティーを使用すると、属性への読み取りと書き込みのパーミッションを定義できます。パーミッションは、ユーザー、管理者、またはその両方の属性に対してこれらの操作を実行するかどうかに基づいて設定されます。
{ "attributes": [ { "name": "myattribute", "permissions": { "view": ["admin"], "edit": ["user"] } ] }
{
"attributes": [
{
"name": "myattribute",
"permissions": {
"view": ["admin"],
"edit": ["user"]
}
]
}
view
プロパティーと edit
プロパティーはいずれも、user
または admin
が表示可能または管理者が管理者が編集できるかによって、値がユーザーまたは admin のいずれかであることを想定します。
edit
パーミッションが付与されると、view
パーミッションは暗黙的に付与されます。
5.11.5.3. annotations プロパティー
属性レベルの annotation
プロパティーを使用して、追加のメタデータを属性に関連付けることができます。アノテーションは、主に、ユーザープロファイル設定に基づいてユーザー属性のレンダリングに属性に関する追加情報を渡す場合に有用です。各アノテーションはキー/値のペアです。
{ "attributes": [ { "name": "myattribute", "annotations": { "foo": ["foo-value"], "bar": ["bar-value"] } ] }
{
"attributes": [
{
"name": "myattribute",
"annotations": {
"foo": ["foo-value"],
"bar": ["bar-value"]
}
]
}
5.11.6. 動的フォームの使用
ユーザープロファイルの主な機能の 1 つは、属性メタデータに基づいてユーザーに表示されるフォームを動的にレンダリングすることがあります。機能がレルムで有効にされている場合、登録や更新などのフォームは、ユーザープロファイル設定に基づいてページを動的にレンダリングする特定のテーマテンプレートを使用してレンダリングされます。
ただし、デフォルトのレンダリングメカニズムがニーズに対応する場合は、すべてのテンプレートをカスタマイズする必要はありません。テーマのカスタマイズをまだ必要な場合には、以下で参照する必要があるテンプレートを以下に示します。
テンプレート | 説明 |
---|---|
base/login/update-user-profile.ftl | 更新プロファイルのページをレンダリングするテンプレート。 |
base/login/register-user-profile.ftl | 登録ページをレンダリングするテンプレート。 |
base/login/idp-review-user-profile.ftl | ルールをレンダリングするテンプレートは、ブローカーを使用してユーザーをフェデレーションする際に、ユーザープロファイルをレビュー/更新するテンプレートです。 |
base/login/user-profile-commons.ftl | 属性設定に基づいてフォームに入力フィールドをレンダリングするテンプレート。上記の 3 つのページテンプレートすべてから使用されます。ここで新しい入力タイプを実装できます。 |
デフォルトのレンダリングメカニズムは、次の機能を提供します。
- 属性に設定されたパーミッションに基づいて、フィールドを動的に表示します。
- 属性に設定された制約に基づいて、必須フィールドのマーカーを動的にレンダリングします。
- 属性に設定されたフィールド入力タイプ (テキスト、日付、数値、選択、複数選択) を動的にレンダリングします。
- 属性に設定されたパーミッションに応じて、読み取り専用フィールドを動的にレンダリングします。
- 属性に設定された順序フィールドに応じて動的に順序フィールドが続きます。
- 同じ属性グループに属する動的なグループフィールド。
5.11.6.1. 順序の属性
属性の順序は、属性リストページにあるときに上下矢印をクリックすると設定されます。
ordering 属性
このページに設定した順番は、フィールドが動的形式でレンダリングされると考慮されます。
5.11.6.2. 属性のグループ化
動的フォームがレンダリングされると、同じ属性グループに属する属性をグループ化しようとします。
動的更新プロファイルフォーム
属性が属性グループにリンクされている場合、属性の順番も同じグループ内の属性が一緒に閉じられるようにすることが重要になります。それ以外の場合は、グループ内の属性に連続的な順序がない場合、同じグループヘッダーが動的形式で複数回レンダリングされる可能性があります。
5.11.6.3. 属性用のフォーム入力レポートの設定
Red Hat Single Sign-On は、動的フォームおよびその視覚化の他の側面で属性に使用される入力タイプを設定するための組み込みのアノテーションを提供します。
利用可能なアノテーションは以下のとおりです。
名前 | 説明 |
---|---|
inputType | フォーム入力フィールドのタイプ。利用可能なタイプは以下の表で説明されています。 |
inputHelperTextBefore |
入力フィールドの前 (上) に表示されるヘルパーテキスト。ここでは、直接テキストまたは国際化パターン ( |
inputHelperTextAfter |
入力フィールドの後にレンダリングされるヘルパーテキスト。ここでは、直接テキストまたは国際化パターン ( |
inputOptionsFromValidation | タイプを選択および複数選択するためのアノテーション。入力オプションの取得元となるカスタム属性検証のオプション名。詳しい説明 を参照してください。 |
inputOptionLabelsI18nPrefix | タイプを選択および複数選択するためのアノテーション。UI でオプションをレンダリングする国際化キー接頭辞。詳しい説明 を参照してください。 |
inputOptionLabels | タイプを選択および複数選択するためのアノテーション。オプションの UI ラベルを定義するためのオプションのマップ (直接または国際化を使用)。詳しい説明 を参照してください。 |
inputTypePlaceholder |
フィールドに適用される HTML 入力 |
inputTypeSize |
フィールドに適用される HTML 入力 |
inputTypeCols |
フィールドに適用される HTML 入力 |
inputTypeRows |
フィールドに適用される HTML 入力 |
inputTypePattern |
クライアント側の検証を提供するフィールドに適用される HTML 入力 |
inputTypeMaxLength |
クライアント側の検証を提供するフィールドに適用される HTML 入力 |
inputTypeMinLength |
クライアント側の検証を提供するフィールドに適用される HTML 入力 |
inputTypeMax |
クライアント側の検証を提供するフィールドに適用される HTML 入力 |
inputTypeMin |
クライアント側の検証を提供するフィールドに適用される HTML 入力 |
inputTypeStep |
フィールドに適用される HTML 入力 |
フィールドタイプは、HTML フォームフィールドタグとそれに適用される属性を使用します。フィールドタイプは、HTML 仕様とブラウザーサポートに基づいて動作します。
ビジュアルレンダリングは、使用するテーマに適用されている css スタイルにも依存します。
利用可能な inputType
アノテーションの値:
名前 | 説明 | 使用される HTML タグ |
---|---|---|
text | 単一行のテキスト入力。 | 入力 (input) |
textarea | 複数の行テキスト入力。 | textarea |
select | 一般的な単一の選択入力。以下の オプションの設定方法の説明 を参照してください。 | select |
select-radiobuttons | ラジオボタンをグループ化して入力を 1 つ選択します。以下の オプションの設定方法の説明 を参照してください。 | 入力グループ |
複数選択 | 一般的な複数選択入力。以下の オプションの設定方法の説明 を参照してください。 | select |
multiselect-checkboxes | チェックボックスのグループで入力を複数選択します。以下の オプションの設定方法の説明 を参照してください。 | 入力グループ |
html5-email | HTML 5 仕様に基づくメールアドレスの単一行のテキスト入力。 | 入力 (input) |
html5-tel | HTML 5 仕様に基づく電話番号の単一行のテキスト入力。 | 入力 (input) |
html5-url | HTML 5 仕様に基づく URL の単一行のテキスト入力。 | 入力 (input) |
html5-number |
HTML 5 仕様に基づく数値 ( | 入力 (input) |
html5-range | HTML 5 仕様に基づいて入力した数字のスライダー。 | 入力 (input) |
html5-datetime-local | HTML 5 仕様に基づく日付入力。 | 入力 (input) |
html5-date | HTML 5 仕様に基づく日付入力。 | 入力 (input) |
html5-month | HTML 5 仕様に基づいた月入力。 | 入力 (input) |
html5-week | HTML 5 仕様に基づく週入力。 | 入力 (input) |
html5-time | HTML 5 仕様に基づく時間入力。 | 入力 (input) |
5.11.6.3.1. select フィールドおよび multiselect フィールドのオプションの定義
選択フィールドと複数選択フィールドのオプションは、属性に適用された検証から取得され、UI に表示される検証とフィールドオプションが常に一貫していることを確認します。デフォルトでは、オプションは組み込み options
の検証から取得されます。
さまざまな方法を使用して、人間が判読できるラベルを選択およびマルチ選択オプションで提供できます。最も単純なケースでは、属性値が UI ラベルと同じである場合です。この場合、追加の設定は必要ありません。
オプションの値は UI ラベルと同じです。
属性値が UI に適さない ID の種類である場合、inputOptionLabelsI18nPrefix
アノテーションによって提供される単純な国際化サポートを使用できます。これは国際化キーの接頭辞を定義します。オプション値はこの接頭辞に追加されるドットになります。
i18n キー接頭辞を使用した UI ラベルの簡単な国際化
オプション値のローカライズされた UI ラベルテキストは、一般的なローカリゼーションメカニズムを使用して、userprofile.jobtitle.sweng
キーおよび userprofile.jobtitle.swarch
キーで提供する必要があります。
inputOptionLabels
アノテーションを使用して、個別のオプションのラベルを指定することもできます。オプションのラベルのマップが含まれています - マップのキーはオプション値 (検証で定義) であり、マップの値は UI ラベルテキスト自体またはそのオプションの国際化パターン ($ {i18n.key}
など) です。
User Profile JSON Editor
を使用して map を inputOptionLabels
アノテーションの値として入力する必要があります。
国際化なしで各オプションの直接入力されたラベルの例:
"attributes": [ ... { "name": "jobTitle", "validations": { "options": { "options":[ "sweng", "swarch" ] } }, "annotations": { "inputType": "select", "inputOptionLabels": { "sweng": "Software Engineer", "swarch": "Software Architect" } } } ... ]
"attributes": [
...
{
"name": "jobTitle",
"validations": {
"options": {
"options":[
"sweng",
"swarch"
]
}
},
"annotations": {
"inputType": "select",
"inputOptionLabels": {
"sweng": "Software Engineer",
"swarch": "Software Architect"
}
}
}
...
]
個別オプションの国際化されたラベルの例:
"attributes": [ ... { "name": "jobTitle", "validations": { "options": { "options":[ "sweng", "swarch" ] } }, "annotations": { "inputType": "select-radiobuttons", "inputOptionLabels": { "sweng": "${jobtitle.swengineer}", "swarch": "${jobtitle.swarchitect}" } } } ... ]
"attributes": [
...
{
"name": "jobTitle",
"validations": {
"options": {
"options":[
"sweng",
"swarch"
]
}
},
"annotations": {
"inputType": "select-radiobuttons",
"inputOptionLabels": {
"sweng": "${jobtitle.swengineer}",
"swarch": "${jobtitle.swarchitect}"
}
}
}
...
]
ローカライズされたテキストは、一般的なローカリゼーションメカニズムを使用して、jobtitle.swengineer
キーと jobtitle.swarchitect
キーで提供する必要があります。
inputOptionsFromValidation
属性アノテーションのおかげで、カスタムバリデーターを使用してオプションを提供できます。この検証には、オプションの配列を提供する options
設定が必要です。国際化は、組み込みの options
検証によって提供されるオプションの場合と同じように機能します。
カスタムバリデーターが提供するオプション
5.11.7. ユーザープロファイルのコンプライアンスの強制
ユーザープロファイルが設定に準拠していることを確認するには、管理者は VerifyProfile
の必須のアクションを使用して、最終的に Red Hat Single Sign-On への認証時にプロファイルの更新を強制することができます。
VerifyProfile
アクションは UpdateProfile
アクションに似ています。ただし、ユーザープロファイルが提供するすべての機能を活用して、ユーザープロファイルの設定により自動的にコンプライアンスが強制されます。
有効にすると、ユーザー認証時に VerifyProfile
アクションは以下の手順を実行します。
- ユーザープロファイルが、レルムに設定されたユーザープロファイル設定に完全準拠しているかどうかを確認します。
- そうでない場合には、認証中に追加のステップを実行して、ユーザーが不足している属性や無効な属性を更新できるようにします。
- ユーザープロファイルが設定に準拠する場合は、追加のステップが実行されず、ユーザーは認証プロセスを続行します。
デフォルトでは、VerifyProfile
アクションは無効になっています。これを有効にするには、左側のメニューの Authentication
リンクをクリックしてから、Required Actions
タブをクリックします。このタブで Register
ボタンをクリックし、VerifyProfile
アクションを選択します。
VerifyProfile Required Action の再入力
5.11.8. ユーザープロファイルへの移行
レルムにユーザープロファイル機能を有効にする前に、いくつかの重要な考慮事項に注意してください。属性メタデータを管理する単一の場所を提供することで、ユーザーや管理方法に設定できる属性は非常に厳しいものです。
ユーザー管理では、管理者はユーザープロファイル設定で定義された属性のみを管理できます。ユーザープロファイル設定で定義されておらず、ユーザープロファイル設定で定義されていない他の属性にはアクセスできません。ユーザーまたは管理者へ公開する必要のあるすべてのユーザー属性で、ユーザープロファイル設定を更新することが推奨されます。
ユーザー情報をクエリーするために、ユーザー REST API にアクセスする場合も同じ推奨事項が適用されます。
LDAP_ID
、LDAP_ENTRY_DN
、KERBEROS_ PRINCIPAL
などの Red Hat Single Sign-On 内部ユーザー属性に関しては、これらの属性をユーザープロファイル設定の属性としてアクセスできるようにする必要があります。表示可能な属性は管理者だけなので、管理コンソールを使用してユーザー属性を管理する場合や、ユーザー API でユーザーのクエリーを行う際には、この属性を表示可能としてマークすることが推奨されます。
そのため、レガシーテンプレート (ユーザー root 属性でハードコード化) へのカスタマイズがある場合、ユーザーに表示されるフォームをレンダリングする場合、これらのフォームを動的にレンダリングする新規テンプレートは使用されません。理想的には、テンプレートへのカスタマイズは回避し、これらの新規テンプレートが提供する動作のスタップをして、フォームを動的にレンダリングする必要があります。要件への対応が十分ではない場合は、それらをカスタマイズするか、フィードバックを提供してください。これにより、新しいテンプレートを拡張することが理にかっているかどうかについて話し合うことができます。