19.3. 認証プロバイダーについて
認証プロバイダーは、ユーザーアイデンティティーのサードパーティーソース (アイデンティティープロバイダー (IDP) など) に接続し、ユーザーアイデンティティーを取得します。そして、そのアイデンティティーに基づいてトークンを発行し、そのトークンを Red Hat Advanced Cluster Security for Kubernetes (RHACS) に返します。このトークンにより、RHACS はユーザーを承認できるようになります。RHACS は、ユーザーインターフェイスおよび API 呼び出し内でトークンを使用します。
RHACS をインストールした後、ユーザーを認証するように IDP を設定する必要があります。
					IDP として OpenID Connect (OIDC) を使用している場合、RHACS は、ユーザー ID トークンまたは UserInfo エンドポイント応答から groups、email、userid、name などの特定のクレームの値を検査するマッピングルールに依存してユーザーを承認します。これらの詳細が存在しない場合、マッピングは成功せず、ユーザーは必要なリソースにアクセスできません。したがって、マッピングを成功させるには、IDP からのユーザーを承認するために必要なクレーム (groups など) が IDP の認証応答に含まれていることを確認する必要があります。
				
19.3.1. クレームマッピング
クレームは、アイデンティティプロバイダーが発行するトークン内にユーザーに関するデータを含めます。
クレームマッピングを使用すると、RHACS が IDP から受け取るクレーム属性を RHACS 発行トークンの別の属性にカスタマイズするかどうかを指定できます。クレームマッピングを使用しない場合、RHACS は RHACS 発行のトークンにクレーム属性を含めません。
					たとえば、クレームマッピングを使用して、ユーザー ID の roles から RHACS 発行のトークンの groups にマッピングできます。
				
RHACS は、認証プロバイダーごとに異なるデフォルトのクレームマッピングを使用します。
19.3.1.1. OIDC のデフォルトのクレームマッピング
次のリストは、デフォルトの OIDC クレームマッピングを示しています。
- 
								subからuseridに
- 
								nameからnameに
- 
								emailからemailに
- 
								groupsからgroupsに
19.3.1.2. Auth0 のデフォルトのクレームマッピング
						Auth0 のデフォルトのクレームマッピングは、OIDC のデフォルトのクレームマッピングと同じです。
					
19.3.1.3. SAML 2.0 のデフォルトのクレームマッピング
次のリストは、SAML 2.0 のデフォルトのクレームマッピングに適用されます。
- 
								Subject.NameIDはuseridにマッピングされる
- 
								応答からのすべての SAML AttributeStatement.Attributeは、その名前にマッピングされる
19.3.1.4. Google IAP のデフォルトのクレームマッピング
次のリストは、Google IAP のデフォルトのクレームマッピングを示しています。
- 
								subからuseridに
- 
								emailからemailに
- 
								hdからhdに
- 
								google.access_levelsからaccess_levelsに
19.3.1.5. ユーザー証明書のデフォルトのクレームマッピング
ユーザー証明書は、サードパーティーの IDP と通信する代わりに、ユーザーが使用する証明書からユーザー情報を取得するため、他のすべての認証プロバイダーとは異なります。
ユーザー証明書のデフォルトのクレームマッピングには次のものが含まれます。
- 
								CertFingerprintからuseridに
- 
								SubjectからCommon Name nameに
- 
								EmailAddressesからemailに
- 
								SubjectからOrganizational Unit groupsに
19.3.1.6. OpenShift Auth のデフォルトのクレームマッピング
次のリストは、OpenShift Auth のデフォルトのクレームマッピングを示しています。
- 
								groupsからgroupsに
- 
								uidからuseridに
- 
								nameからnameに
19.3.2. Rules
					ユーザーを承認するために、RHACS は、ユーザー ID から groups、email、userid、name などの特定のクレームの値を検査するマッピングルールに依存します。ルールを使用すると、特定の値を持つ属性を持つユーザーを特定のロールにマッピングできます。例として、ルールには次の内容を含めることができます。key は email、value は john@redhat.com、role は Admin です。
				
					クレームが欠落している場合、マッピングは成功せず、ユーザーは必要なリソースにアクセスできません。したがって、マッピングを成功させるには、IDP からの認証応答に、ユーザー (groups など) を承認するために必要なクレームが含まれていることを確認する必要があります。
				
19.3.3. 最小アクセスロール
					RHACS は、特定の認証プロバイダーが発行した RHACS トークンを使用して、すべての呼び出し元に最小限のアクセスロールを割り当てます。最小アクセスロールは、デフォルトでは None に設定されています。
				
					たとえば、Analyst という最小アクセスロールを持つ認証プロバイダーがあるとします。その場合、このプロバイダーを使用してログインするすべてのユーザーには、Analyst ロールが割り当てられます。
				
19.3.4. 必須の属性
必須の属性は、ユーザー ID に特定の値の属性があるかどうかに基づいて、RHACS トークンの発行を制限できます。
					たとえば、キー is_internal の属性の属性値が true である場合にのみトークンを発行するように RHACS を設定できます。is_internal 属性が false に設定されているか、設定されていないユーザーはトークンを取得しません。