[release-1.6] RHIDP-7461: List the steps for role-based access in UI (#1189)

* RHIDP-7461: List the steps for role-based access in UI

* Incorporated review comments

---------

Co-authored-by: Heena Manwani <[email protected]>

Author: openshift-cherrypick-robot

assemblies/assembly-configuring-authorization-in-rhdh.adoc

@@ -35,7 +35,7 @@ include::assembly-managing-authorizations-by-using-external-files.adoc[leveloffs
 
 include::assembly-configuring-guest-access-with-rbac-ui.adoc[leveloffset=+1]
 
-include::modules/authorization/proc-delegating-rbac-access.adoc[leveloffset=+1]
+include::assembly-delegating-rbac-access-rhdh.adoc[leveloffset=+1]
 
 include::modules/authorization/ref-rbac-permission-policies.adoc[leveloffset=+1]
 

assemblies/assembly-delegating-rbac-access-rhdh.adoc

@@ -0,0 +1,25 @@
+:_mod-docs-content-type: ASSEMBLY
+
+[id="assembly-delegating-rbac-access-rhdh_{context}"]
+= Delegating role-based access controls (RBAC) access in {product}
+
+An enterprise customer requires the ability to delegate role-based access control (RBAC) responsibilities to other individuals in the organization. In this scenario, you, as the administrator, can provide access to the RBAC plugin specifically to designated users, such as team leads. Each team lead is then able to manage permissions exclusively for users within their respective team or department, without visibility into or control over permissions outside their assigned scope. This approach allows team leads to manage access and permissions for their own teams independently, while administrators maintain global oversight.
+
+In {product}, you can delegate RBAC access using the multitenancy feature of the RBAC plugin, specifically the `IS_OWNER` conditional rule. You can either use the web UI or the RBAC backend API, depending on your preferred workflow and level of automation:
+
+* Use the web UI to create roles, assign users or groups, define permissions, and apply ownership conditions through an intuitive interface.
+
+* Use the API for a more flexible and automatable approach, where you can programmatically manage roles, permissions, and ownership conditions using authenticated curl requests.
+
+By delegating RBAC access through either method, you can expect the following outcomes:
+
+* Team leads can manage RBAC settings for their teams independently.
+* Visibility of other users' or teams' permissions is restricted.
+* Administrators retain overarching control while delegating team-specific access.
+
+.Prerequisites
+* Your {product-very-short} instance is running with the RBAC plugin installed and configured.
+* You have administrative access to {product-very-short}.
+
+include::modules/authorization/proc-delegating-rbac-access-webui.adoc[leveloffset=+1]
+include::modules/authorization/proc-delegating-rbac-access-api.adoc[leveloffset=+1]

modules/authorization/proc-delegating-rbac-access.adoc renamed to modules/authorization/proc-delegating-rbac-access-api.adoc

@@ -1,24 +1,13 @@
-[id='proc-delegating-rbac-access_{context}']
-= Delegating role-based access controls (RBAC) access in {product}
+[id='proc-delegating-rbac-access-api_{context}']
+= Delegating RBAC access in {product} by using API
 
-An enterprise customer requires the ability to delegate role-based access control (RBAC) responsibilities to other individuals in the organization. In this scenario, you, as the administrator, can provide access to the RBAC plugin specifically to designated users, such as team leads. Each team lead is then able to manage permissions exclusively for users within their respective team or department, without visibility into or control over permissions outside their assigned scope. This approach allows team leads to manage access and permissions for their own teams independently, while administrators maintain global oversight.
-
-In {product-very-short}, you can delegate RBAC access using the multitenancy feature of RBAC plugin, specifically the `IS_OWNER` conditional rule.
-
-By delegating the RBAC access, you can expect the following outcomes:
-
-* Team leads can manage RBAC settings for their teams independently.
-* Visibility of other users' or teams' permissions is restricted.
-* Administrators retain overarching control while delegating team-specific access.
+You can delegate the RBAC access in {product} by using the RBAC backend API.
 
 .Prerequisites
-* Your {product-very-short} instance is up and running with RBAC plugin installed and configured.
-* You have administrative access to {product-very-short}.
 * You have API access using `curl` or another tool.
 
 .Procedure
-. In your {product-very-short} instance, navigate to the *Administration -> RBAC* page.
-. Create a new role designated for team leads using the Web UI or API:
+. Create a new role designated for team leads using the RBAC backend API:
 +
 --
 .Example of creating a new role for the team lead using the RBAC backend API
@@ -35,11 +24,9 @@ curl -X POST 'http://localhost:7007/api/permission/roles' \
   }
 }'
 ----
-
-For more information about creating a role using the Web UI, see xref:proc-rbac-ui-create-role_title-authorization[Creating a role in the {product} Web UI].
 --
 
-. Allow team leads to read catalog entities and create permissions in the RBAC plugin using the Web UI or the following API request:
+. Allow team leads to read catalog entities and create permissions in the RBAC plugin using the following API request:
 +
 --
 .Example of granting the team lead role permission to create RBAC policies and read catalog entities

modules/authorization/proc-delegating-rbac-access-webui.adoc

@@ -0,0 +1,29 @@
+[id='proc-delegating-rbac-access-webui_{context}']
+= Delegating RBAC access in {product} by using the web UI
+
+You can delegate the RBAC access in {product} by using the web UI.
+
+.Procedure
+. Log in to your {product-very-short} instance with administrator credentials.
+. Navigate to *Administration → RBAC*.
+. Click *Create Role* and define a new role for team leads, such as `role:default/team_lead`.
+. In the *Members* section, add the user or group, such as `user:default/team_lead`.
+. Grant permissions required by team leads, such as:
++
+--
+* `policy.entity.create` to allow policy creation.
+* `catalog-entity:read` to allow catalog access.
+--
+. Apply *conditions* to limit access as follows:
++
+* Use the `IS_OWNER` rule to ensure team leads can only manage resources they own.
+
+. Click *Save* to create the role and apply changes.
+
+.Verification
+* Log in as a team lead.
+* Verify the following:
++
+** RBAC UI is accessible.
+** Only users or roles related to their team are visible.
+** No access to roles or permissions outside their scope is granted.