[v2.13.0] Add info about Azure AD Roles claims

docs/how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/authentication-config/configure-azure-ad.md

@@ -363,3 +363,22 @@ Since the filter prevents Rancher from seeing that the user belongs to an exclud
 >- If you don't wish to upgrade to v2.7.0+ after the Azure AD Graph API is retired, you'll need to either:
     - Use the built-in Rancher auth or
     - Use another third-party auth system and set that up in Rancher. Please see the [authentication docs](authentication-config.md) to learn how to configure other open authentication providers.
+
+## Azure AD Roles Claims
+
+Rancher supports the Roles claim provided by the Azure AD OIDC provider token, allowing for complete delegation of Role-Based Access Control (RBAC) to Azure AD. Previously, Rancher only processed the `Groups` claim to determine a user's `group` membership. This enhancement extends the logic to also include the Roles claim within the user's OIDC token.
+
+By including the Roles claim, administrators can:
+
+- Define specific high-level roles in Azure AD.
+- Bind these Azure AD Roles directly to ProjectRoles or ClusterRoles within Rancher.
+- Centralize and fully delegate access control decisions to the external OIDC provider.
+
+For example, consider the following role structure in Azure AD:
+
+| Azure AD Role Name | Members        |
+|--------------------|----------------|
+| project-alpha-dev  | User A, User C |
+
+
+User A logs into Rancher via Azure AD. The OIDC token includes a Roles claim, [`project-alpha-dev`]. The Rancher logic processes the token, and the internal list of `groups`/roles for User A which includes `project-alpha-dev`. An administrator has created a Project Role Binding that maps the Azure AD Role `project-alpha-dev` to the Project Role `Dev Member` for Project Alpha. User A is automatically granted the `Dev Member` role in Project Alpha.

versioned_docs/version-2.13/how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/authentication-config/configure-azure-ad.md

@@ -363,3 +363,22 @@ Since the filter prevents Rancher from seeing that the user belongs to an exclud
 >- If you don't wish to upgrade to v2.7.0+ after the Azure AD Graph API is retired, you'll need to either:
     - Use the built-in Rancher auth or
     - Use another third-party auth system and set that up in Rancher. Please see the [authentication docs](authentication-config.md) to learn how to configure other open authentication providers.
+
+## Azure AD Roles Claims
+
+Rancher supports the Roles claim provided by the Azure AD OIDC provider token, allowing for complete delegation of Role-Based Access Control (RBAC) to Azure AD. Previously, Rancher only processed the `Groups` claim to determine a user's `group` membership. This enhancement extends the logic to also include the Roles claim within the user's OIDC token.
+
+By including the Roles claim, administrators can:
+
+- Define specific high-level roles in Azure AD.
+- Bind these Azure AD Roles directly to ProjectRoles or ClusterRoles within Rancher.
+- Centralize and fully delegate access control decisions to the external OIDC provider.
+
+For example, consider the following role structure in Azure AD:
+
+| Azure AD Role Name | Members        |
+|--------------------|----------------|
+| project-alpha-dev  | User A, User C |
+
+
+User A logs into Rancher via Azure AD. The OIDC token includes a Roles claim, [`project-alpha-dev`]. The Rancher logic processes the token, and the internal list of `groups`/roles for User A which includes `project-alpha-dev`. An administrator has created a Project Role Binding that maps the Azure AD Role `project-alpha-dev` to the Project Role `Dev Member` for Project Alpha. User A is automatically granted the `Dev Member` role in Project Alpha.