Update RBAC docs

- Managing Users and Groups
- Managing Applications
- Managing Tags

New docs:
- RBAC overview

docs/access-control-and-security/applications.md

@@ -1,130 +1,96 @@
-# Enabling Security via Applications
+import Tabs from '@theme/Tabs';
+import TabItem from '@theme/TabItem';
 
-Orkes has added a security layer called Applications, enabling the connection between the workers and the Orkes Conductor cluster. Every connection in/out of Orkes Conductor requires an authentication header with a JSON Web Token (JWT). This header is of the format: `'X-Authorization: <JWT Token>'`.
 
-An application represents an entity interacting with the Conductor server via APIs or SDKs. Each application can have multiple access key and secret combinations, which are used to generate an authentication token for securing and controlling access to each API request.
+# Managing Applications
 
-This document provides a detailed guide on creating application-based control for your metadata as well as the process for generating JWT tokens for each application.
+An application represents an application that interacts with a Conductor server via APIs or SDKs. The application layer in Conductor provides application-based access to resources in your cluster. 
 
-Watch how we can configure and manage Applications and its access from the UI.
+Each application can also have one or more access key/secret pairs, which are used to grant access to Conductor SDK and API. Learn more about authentication in [Authentication and Access Keys](/sdks/authentication).
 
-<center><iframe width="510" height="300" src="https://www.youtube.com/embed/PY34TcVzof0?si=ANSHZW6IMVDx1rI9" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" allowfullscreen="allowfullscreen"
-mozallowfullscreen="mozallowfullscreen"
-msallowfullscreen="msallowfullscreen"
-oallowfullscreen="oallowfullscreen"
-webkitallowfullscreen="webkitallowfullscreen"></iframe></center>
-
-## Prototyping​
-
-For quick testing on Orkes Conductor without creating an application, you can obtain a JWT token from the Orkes Conductor dashboard. Click the account button in the bottom left corner and select "Copy Token." This token remains valid for your current session and has the same access as your user account.
-
-## Application
-
-Each application can generate one or more sets of keys and secrets to produce a JWT token. Applications can grant access to entities such as workflows, tasks, secrets, environment variables, tags, domains, integrations, and prompts.
-
-### Configuring Application​
-
-To create a new application,
-
-1. Navigate to **Access Control > Applications** from the left menu on your Orkes Conductor console.
-2. Click **+ Create application** and provide an app name.
-3. Click **Save** to create the application.
-
-Depending upon your role, you can see two different role sections that can be granted to the application.
 
-* Unrestricted roles: Can be granted only by an Admin.
-* Application roles: Can be granted by anyone with access to Applications.
+## Application roles
 
-<p align="center"><img src="/content/img/app-roles.png" alt="App roles" width="80%" height="auto"></img></p>
+By default, all applications can manage workflow and task executions if they have access to the required resources. For example, an application can execute `someWorkflow` long as Execute permission is granted for those resources. Likewise, an application can view workflow executions if Read permission is granted.
 
-General application roles include:
+Application roles grant additional access on top of this default behavior and should be selected only if your application is used for another purpose besides managing workflow executions. These additional application roles should be selected based on your application requirements. There are two categories of application roles available: 
 
-* **Worker**: Poll and update tasks. It requires Execute permissions on the tasks.
-* **Metadata API**: Create and manage workflow and task definitions.
-* **Application API**: Create and manage applications.
+<Tabs>
+<TabItem value="application roles" label="Application Roles">
 
-The application's behavior depends on the chosen role, so select roles based on your requirements.
+Application roles an be added by any user with access to applications. General application roles include:
+* **Worker**—Poll and execute tasks that it has Execute permissions for.
+    This role should be granted to a task worker application that is responsible for polling and executing a task.
+* **Metadata API**—Create and manage workflow and task metadata.
+    This role should be granted to an application that is responsible for retrieving and managing workflow and task definitions, such as for testing or CI/CD integration purposes.
+* **Application API**—Create and manage applications.
+    This role should be granted to an application that is responsible for managing other applications in the cluster.
 
-Admins have additional unrestricted roles, such as:
+</TabItem>
 
-- **Unrestricted Worker** - Poll, execute updates, maintain logs, and handle any task without any constraints
-- **Metadata Manager** - Create, update, delete, and administer Workflow or Task definitions permissions.
-- **Workflow Manager** - Responsible for managing the lifecycle of workflows within the system. Initiate, pause, resume, rerun, delete, and oversee any Workflow operation.
-- **Application Manager** - Handles the creation, modification, and deletion of applications within the system.
+<TabItem value="unrestricted roles" label="Unrestricted Roles">
 
-### Generating Access Keys​
+Unrestricted roles an only be added by an Admin. Unrestricted roles include:
+* **Unrestricted Worker**—Poll, execute updates, maintain logs, and handle any task without any constraints
+* **Metadata Manager**—Create, update, delete, and grant permissions to any workflow or task definition in the cluster.
+* **Workflow Manager**—Manage the lifecycle of workflows within the system. Start, pause, resume, rerun, and delete any workflow execution.
+* **Application Manager**—Manage applications in the cluster, such as creating, modifying, and deleting applications.
 
-Once permissions are assigned, generate an **Access Key**:
+</TabItem>
+</Tabs>
 
-1. Click **+ Create access key** to generate a unique Key Id and Key Secret.
-2. The key secret is shown only once; copy and store it privately.
+<p align="center"><img src="/content/img/RBAC/app-roles.png" alt="App roles" width="80%" height="auto"></img></p>
 
-Once a key has been created, you can perform three actions on the key:
 
-<p align="center"><img src="/content/img/actions-on-the-generated-key.jpg" alt="Generated Key in the Conductor" width="90%" height="auto"></img></p>
+## Configuring applications
 
-* **Copy** - Use the copy button to copy the key ID.
-* **Pause** - Use the pause button to temporarily restrict access to the application. 
-* **Delete** - Use the delete button to permanently remove the key.
+Configure the application’s roles and permissions to control what your application can do and what resources it can access, including workflows, tasks, secrets, environment variables, tags, domains, integrations, and prompts.
 
-### Adding Permissions​
+**To configure an application:**
+1. Create an application.
+    1. In the left navigation menu, go to **Access Control** > **Applications**.
+    2. Select **(+) Create application**.
+    3. Enter the application name.
+    4. Select **Save**.
+    The application has been created. You can proceed to add roles or permissions to the application.
+2. Add roles to the application.
+    1. In the Application Roles or Unrestricted Roles section, toggle the different application roles for your application.
+3. Add permissions to grant application-level access to resources.
+    1. In the Permissions section, select **+ Add Permission**.
+    2. Toggle between each resource type and select the resources to provide access to.
+    3. Toggle the access levels for your selected resource:
+        * **Read**—The application will be able to view the resource.
+        * **Update**—The application will be able to update the resource. The application must also have the Metadata API role to update metadata resources.
+        * **Execute**—The application will be able to execute the resource. The application must also have the Worker role to execute resources.
+        * **Delete**—The application will be able to delete the resource. The application must also have the Metadata API role to delete metadata resources.
 
-In this section, you can provide the application with access to workflows, tasks, secrets, environment variables, tags, domains, integrations, and prompts. 
+:::tip
+You can grant permissions to **tags**, rather than to individual resources. Tags can be added to multiple resources, so that when you grant a permission to a tag, it instantly provides access to all tagged resources. Learn more about tags in [Managing Tags](/access-control-and-security/tags).
+:::
 
-To grant permissions to the application:
-
-1. Click **+Add Permission**.
-2. Select the required metadata to have access to selected workflows, tasks, secrets, environment variables, tags, domains, integrations, and prompts.
-3. Select all targets that the application needs access to.
-4. Choose the required permissions for the selected targets.
-   * **Read** - The user can view the entities, but cannot modify or run them.
-   * **Create** - The user can create the entities.
-   * **Update** - Allows the user to update the entities. Requires Metadata API role for this.
-   * **Execute** - Allows the user to run the entities. Requires Worker role for this.
-   * **Delete** - Allows the user to delete the entities. Requires Metadata API role for this.
-5. Click **Add Permissions**.
-
-## Generating Token​
-
-Access keys can be used to create JWTs for authenticating connections to the Conductor server. All of the [Conductor SDKs](/content/category/sdks) support this authentication. When using a Conductor SDK, the key and secret are provided to the SDK, and the authentication is handled automatically.
-
-Alternatively, create a JWT via an API call. Here's an example call to the Orkes Playground:
-
-```c
-curl -s -X "POST" "https://play.orkes.io/api/token" \
-  -H 'Content-Type: application/json; charset=utf-8' \
-  -d '{"keyId": "<your keyId>","keySecret": "<your secret>"}'
-
- {"token":"<JWT Token>"}
- ```
-
-Sending the key Id and secret generates a JWT. This JWT can be used to make calls to the Orkes Conductor cluster. The header for authentication is `X-Authorization:`.
+<br/>
+<center><iframe width="510" height="300" src="https://www.youtube.com/embed/PY34TcVzof0?si=ANSHZW6IMVDx1rI9" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" allowfullscreen="allowfullscreen"
+mozallowfullscreen="mozallowfullscreen"
+msallowfullscreen="msallowfullscreen"
+oallowfullscreen="oallowfullscreen"
+webkitallowfullscreen="webkitallowfullscreen"></iframe></center>
 
+## Example application setup
 
-For example, this call to the **_super_weather_** workflow uses a JWT token to get the weather in Beverly Hills, CA:
+<details><summary>Example</summary>
 
-```c
-curl -s -X "POST" "https://play.orkes.io/api/workflow/super_weather" \
-   -H 'Content-Type: application/json; charset=utf-8'  \
-   -H 'X-Authorization:  <JWT Token>'\
-   -d '{"zip": "90210"}'
-   ```
+In this example, two programs have access to Orkes Conductor workflows. Both of these workflows rely on the same task, Task X, which is performed by a worker application, Worker X.
 
-## Example
 
-<details><summary>Example Application Setup</summary>
-<p>
-Let’s consider that two programs have access to Orkes Conductor workflows. Both these workflows rely on a single task, i.e., Task X, which is performed by a worker application Worker X.
+<p align="center"><img src="/content/img/RBAC/application_access_example.jpg" alt="Example application" width="90%" height="auto"></img></p>
 
-One way to handle this is to create a single application with access to Workflow 1, Workflow 2, and Task X and supply keys/secrets from the application to Program 1, Program 2, and Worker X. But this violates the principle of least privilege, where applications should only have access to the endpoints they require (E.g., Here Worker X should not have access to execute the two workflows).
 
-<p align="center"><img src="/content/img/application_access_example.jpg" alt="Example application" width="90%" height="auto"></img></p>
-In order to satisfy the principle of least privilege, we'll create 3 Applications.
+One way to handle this is to create a single application with Execute access to Workflow 1, Workflow 2, and Task X and provide the application keys/secrets to Program 1, Program 2, and Worker X. However, this setup violates the principle of least privilege, where applications should only have access to the endpoints they require. In this case, Worker X should not have Execute access for the workflows.
 
-1. Application **Worker X** with the EXECUTE permission for **Task X**. This allows the worker to poll the task queue for work.
-2. Application **Program 1** with the EXECUTE permission for **Workflow 1** and **Task X** so that it can successfully invoke Workflow 1.
-3. Application **Program 2** with the EXECUTE permission for **Workflow 2** and **Task X** so that it can successfully invoke Workflow 2.
+To satisfy the principle of least privilege, we will create three applications instead:
+1. **Application Worker X**—Has the Worker role and Execute permission for Task X. This allows the worker to poll the task queue for work.
+2. **Application Program 1**—Has Execute permission for Workflow 1 and for Task X so that it can successfully invoke Workflow 1. No additional application role is required.
+3. **Application Program 2**—Has Execute permission for Workflow 2 and for Task X so that it can successfully invoke Workflow 2. No additional application role is required.
 
-The worker application has no access to the workflows - since this application only needs to poll the task. The other two applications have only the required access to execute the workflow and the tasks inside the specific workflow.
-</p>
+With this set-up, the worker application has no access to the workflows, since it only needs to poll the task. Likewise, the other two applications only have the required access to execute the workflow and its necessary tasks, and no other workflows.
 </details>