15.4. 読み取り専用ユーザー属性
Red Hat build of Keycloak に保存されている一般的なユーザーは、ユーザープロファイルに関連するさまざまな属性を持っています。このような属性には、email、firstname、lastname が含まれます。ただし、ユーザーには通常のプロファイルデータではなくメタデータの属性もある場合があります。通常、ユーザーのメタデータ属性は読み取り専用でなければならず、一般的なユーザーは Red Hat build of Keycloak のユーザーインターフェイスまたは Account REST API からこれらの属性を更新できないはずです。Admin REST API を使用してユーザーを作成または更新する場合に、管理者は一部の属性を読み取り専用にする必要があります。
メタデータ属性は通常、これらのグループの属性です。
-
ユーザーストレージプロバイダーに関連するさまざまなリンクまたはメタデータ。たとえば、LDAP 統合の場合に、
LDAP_ID
属性には LDAP サーバーのユーザーの ID が含まれます。 -
ユーザーストレージによってプロビジョニングされるメタデータ。たとえば、LDAP からプロビジョニングされる
createdTimestamp
は、常にユーザーまたは管理者によって読み取り専用である必要があります。 -
さまざまなオーセンティケーターに関連するメタデータ。たとえば、
KERBEROS_PRINCIPAL
属性には、特定ユーザーの kerberos プリンシパル名を含めることができます。同様に、属性usercertificate
には、X.509 証明書からのデータを使用したユーザーのバインディングに関連するメタデータを含めることができます。これは、通常 X.509 証明書認証が有効な場合に使用されます。 -
applications/clients によるユーザーの識別に関連するメタデータ。たとえば、
saml.persistent.name.id.my_app
には SAML NameID を含めることができます。これは、クライアントアプリケーションmy_app
がユーザーの識別子として使用されます。 - 認可ポリシーに関連するメタデータ。属性ベースのアクセス制御 (ABAC) に使用されます。これらの属性の値は、認可の決定に使用できます。したがって、ユーザーはこれらの属性を更新できないことが重要です。
長期的な観点から見ると、Red Hat build of Keycloak には適切なユーザープロファイル SPI があり、すべてのユーザー属性を詳細に設定できます。現在、この機能はまだ完全には利用できません。そのため Red Hat build of Keycloak には、ユーザーおよび、サーバーレベルで設定された管理者ににとって読み取り専用のユーザー属性の内部リストがあります。
これは、読み取り専用属性のリストで、Red Hat build of Keycloak のデフォルトプロバイダーや機能により内部で使用されます。そのため、これらは必ず読み取り専用になっています。
-
ユーザーの場合:
KERBEROS_PRINCIPAL
、LDAP_ID
、LDAP_ENTRY_DN
、CREATED_TIMESTAMP
、createTimestamp
、modifyTimestamp
、userCertificate
、saml.persistent.name.id.for.*
、ENABLED
、EMAIL_VERIFIED
-
管理者の場合:
KERBEROS_PRINCIPAL
、LDAP_ID
、LDAP_ENTRY_DN
、CREATED_TIMESTAMP
、createTimestamp
、modifyTimestamp
システム管理者は、このリストに属性を追加することもできます。現在、設定はサーバーレベルで利用できます。
この設定は、spi-user-profile-declarative-user-profile-read-only-attributes
オプションと `spi-user-profile-declarative-user-profile-admin-read-only-attributes
オプションを使用して追加できます。以下に例を示します。
kc.[sh|bat] start --spi-user-profile-declarative-user-profile-read-only-attributes=foo,bar*
この例では、ユーザーおよび管理者は foo
属性を更新できません。ユーザーは、bar
で始まる属性を編集できません。たとえば、bar
や barrier
などです。設定では大文字と小文字が区別されないため、この例では FOO
や BarRier
などの属性も拒否されます。ワイルドカード文字 *
は属性名の末尾でのみサポートされるので、管理者は指定された文字で始まるすべての属性を効果的に拒否できます。属性の途中の *
は通常の文字と見なされます。