Groups & Role-Based Access Control (RBAC)

Groups and RBAC are the basis of access management in Cakewalk. Groups define membership, while RBAC specifies the access granted, enabling scalable access control without managing individual users.

👥 Who It Applies To

Role	Capabilities
Admins	Create and manage groups, assign default apps, and define RBAC rules.
App Owners	See how group membership drives requests and access reviews for their apps.
Managers	Understand how their teams inherit access from groups.

---

📖 Key Concepts

Groups

• Definition: Collections of users that form the basis of RBAC.

• Types:

  • Synced groups: Imported from your IdP/HRIS (e.g., Entra, Okta).

    • Assigned groups: Membership managed manually in the IdP.

      • By default: read-only in Cakewalk.

      • Optionally: bidirectional sync for managed apps, allowing membership updates in Cakewalk to push back to the IdP.

    • Dynamic groups: Membership defined by IdP rules (always read-only in Cakewalk).

  • Cakewalk-managed groups: Created and maintained directly in Cakewalk.

👉 Groups can be imported and synced from your IdP/HRIS. For details, see HRIS & IdP.

---

Role-Based Access Control (RBAC)

• Apps and permissions are assigned via groups rather than individually.

• Each group can be linked to default apps (automatically assigned) and hidden apps (restricted visibility).

💡 Why this matters: Groups + RBAC automate onboarding, adapt automatically when people move roles and enforce least privilege consistently.

---

🛠 User Group Workflows

Setting Up Groups

• Navigation: Users → User Groups → New.

• Actions:

  • Create Cakewalk-managed groups directly in Cakewalk.

  • Import and sync groups from your IdP/HRIS (see HRIS & IdP for details).

  • Add members manually (for Cakewalk-managed groups and bidirectional sync) or let sync populate them.

  • Assign default apps or hidden apps (only available for managed apps).

• Outcome: Group membership mirrors your org structure, making access predictable and automatable.

• Who can do this: Admins can create, sync and manage all groups.

---

Implementing RBAC

Default Apps

• Definition: Managed apps automatically assigned to all members of a group.

• Use case: Universal apps (e.g., Slack for all employees, Jira for Engineering).

• Setup: Group Detail view → Apps → Default Apps.

• Outcome: A Grant access request is automatically generated for all new group members, while Remove access requests are automatically created for those leaving the group.

• Who does this concern: Admins.

Hidden Apps

• Definition: Managed apps intentionally hidden from a group’s App catalog.

• Use case: Restrict visibility of sensitive apps or reduce catalog noise.

• Setup: Group Detail view → Apps → Hidden Apps.

• Outcome: Hidden apps stay governable by Admins and App Owners but cannot be requested by employees in that group.

• Who does this concern: Admins.

---

📊 Group Types Overview

Group Type	Source	Editable in Cakewalk	Notes
Assigned (Synced)	IdP/HRIS	Optional	Read-only by default, but can be configured with bidirectional sync.
Dynamic (Synced)	IdP/HRIS	No	Membership defined by IdP rules; always read-only.
Cakewalk-managed	Cakewalk	Yes	Created/maintained directly in Cakewalk; manual membership control.

---

✅ Best Practices

• Mirror org structure in groups (departments, teams) for clear RBAC mapping.

• Use default apps only for truly universal tools; otherwise require requests to maintain least privilege.

• Apply hidden apps sparingly — only where access must be tightly controlled.

• Review group memberships regularly to avoid permission creep.

• Audit policies to ensure JML events (joiner, mover, leaver) handle group assignments correctly.