19.3. Understanding authentication providers


An authentication provider connects to a third-party source of user identity (for example, an identity provider or IDP), gets the user identity, issues a token based on that identity, and returns the token to Red Hat Advanced Cluster Security for Kubernetes (RHACS). This token allows RHACS to authorize the user. RHACS uses the token within the user interface and API calls.

After installing RHACS, you must set up your IDP to authorize users.

注記

If you are using OpenID Connect (OIDC) as your IDP, RHACS relies on mapping rules that examine the values of specific claims like groups, email, userid and name from either the user ID token or the UserInfo endpoint response to authorize the users. If these details are absent, the mapping cannot succeed and the user does not get access to the required resources. Therefore, you need to ensure that the claims required to authorize users from your IDP, for example, groups, are included in the authentication response of your IDP to enable successful mapping.

19.3.1. Claim mappings

A claim is the data an identity provider includes about a user inside the token they issue.

Using claim mappings, you can specify if RHACS should customize the claim attribute it receives from an IDP to another attribute in the RHACS-issued token. If you do not use the claim mapping, RHACS does not include the claim attribute in the RHACS-issued token.

For example, you can map from roles in the user identity to groups in the RHACS-issued token using claim mapping.

RHACS uses different default claim mappings for every authentication provider.

19.3.1.1. OIDC default claim mappings

The following list provides the default OIDC claim mappings:

  • sub to userid
  • name to name
  • email to email
  • groups to groups

19.3.1.2. Auth0 default claim mappings

The Auth0 default claim mappings are the same as the OIDC default claim mappings.

19.3.1.3. SAML 2.0 default claim mappings

The following list applies to SAML 2.0 default claim mappings:

  • Subject.NameID is mapped to userid
  • every SAML AttributeStatement.Attribute from the response gets mapped to its name

19.3.1.4. Google IAP default claim mappings

The following list provides the Google IAP default claim mappings:

  • sub to userid
  • email to email
  • hd to hd
  • google.access_levels to access_levels

19.3.1.5. User certificates default claim mappings

User certificates differ from all other authentication providers because instead of communicating with a third-party IDP, they get user information from certificates used by the user.

The default claim mappings for user certificates include:

  • CertFingerprint to userid
  • Subject Common Name to name
  • EmailAddresses to email
  • Subject Organizational Unit to groups

19.3.1.6. OpenShift Auth default claim mappings

The following list provides the OpenShift Auth default claim mappings:

  • groups to groups
  • uid to userid
  • name to name

19.3.2. Rules

To authorize users, RHACS relies on mapping rules that examine the values of specific claims such as groups, email, userid, and name from the user identity. Rules allow mapping of users who have attributes with a specific value to a specific role. As an example, a rule could include the following:`key` is email, value is john@redhat.com, role is Admin.

If the claim is missing, the mapping cannot succeed, and the user does not get access to the required resources. Therefore, to enable successful mapping, you must ensure that the authentication response from your IDP includes the required claims to authorize users, for example, groups.

19.3.3. Minimum access role

RHACS assigns a minimum access role to every caller with a RHACS token issued by a particular authentication provider. The minimum access role is set to None by default.

For example, suppose there is an authentication provider with the minimum access role of Analyst. In that case, all users who log in using this provider will have the Analyst role assigned to them.

19.3.4. Required attributes

Required attributes can restrict issuing of the RHACS token based on whether a user identity has an attribute with a specific value.

For example, you can configure RHACS only to issue a token when the attribute with key is_internal has the attribute value true. Users with the attribute is_internal set to false or not set do not get a token.

Red Hat logoGithubRedditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

Red Hat ドキュメントについて

Legal Notice

Theme

© 2026 Red Hat
トップに戻る