[Spike] Technical scoping for DAP role-based access controls

Summary

Technical scoping for implementing DAP role-based access controls in the Duo Settings page and making DAP permissions configurable at the instance/top-level group for GitLab.com and Self-Managed/Dedicated for admins and owners.

Background

We're implementing granular DAP settings to configure which roles can use which DAP features.

Design reference: https://www.figma.com/board/hOiNqnzdqAOiBhn7oYPM64/%F0%9F%9A%A7--19119-Permissions---Governance?node-id=0-1&p=f&t=yZgjDjT5pyXI65he-0

Design

image.png

Note: We're skipping the read-only view iteration and going directly to editable permissions. The current permission state can be visualized in our documentation.

Related discussion: https://docs.google.com/document/d/1R0dyoSSt5V2DabrvLOgp_HFvSbnsNV6mWQn9oOEKMVk/edit?tab=t.0

Problem Statement

Currently:

  • No UI exists to manage DAP permissions
  • Permissions are hardcoded
    • Dev+ for executing flows and agents
    • Maintainers+ only for creating/editing/publishing/enabling flows and agents
  • No APIs exist for granular permission control at the instance level or the top-level group
  • No ability to control which roles can use specific DAP features (Flows, Agents)
  • No Single Source of Truth (SSoT) for which features should be available with which role

We need to build a complete permission management system from the ground up.

Scope

In Scope

  • Create UI in the Duo Settings page to configure DAP permissions.
  • Build backend APIs for managing permissions.
  • Define and implement a permission data model (for example DAPPermission)
  • Make permissions editable for instance-level and top-level groups.
  • Configure which roles can:
    • Create and edit agents and flows.
    • Publish agents and flows.
    • Enable agents and flows.
    • Execute agents and flows.
      • @m_frankiewicz Is this something we also want to make controllable and dynamic?
  • Persist permission changes
  • Enforce permissions across all DAP features.

Out of Scope

  • Subgroup permission controls
  • Project permission controls
  • Allowing the maintainer to manage Duo feature availability on the instance level and top-level groups
  • Allowing the maintainer to manage Duo Agent Platform features on the instance level and top-level groups

Current State Analysis

What EXISTS Today

Flow/Agent Management APIs

  • REST/GraphQL API for creating/updating/deleting flows and agents
  • Hardcoded: Only maintainers+ can create/update/delete
  • No concept of publishing (auto-published on creation)
  • Managed by groupworkflow catalog

Flow Execution

  • Any developer can use features if the project has appropriate settings enabled.
  • No user-level control on usage
  • Managed by groupagent foundations

Catalog Browsing

  • Can browse the AI catalog without being logged in
  • Cannot do anything with it without appropriate permissions

What's MISSING Today (What We Need to Build)

  • API for configuring permissions at the namespace level
  • API for allowing/blocking flows at the namespace level
  • API for allowing/blocking agents at the namespace level
  • No granular permission system - it's all-or-nothing at the namespace level.
  • No SSoT (Single Source of Truth) for feature-role mappings across different DAP features
  • No UI for managing any of the above

Key Quote from Meeting

"we don't have an SSoT available on which features should be available with which role right now, so there's a chance that we have a spread of different permissions, e.g. running flows etc. normally requires Developers + but seeing the catalog might be available easier" - Basti

Technical Requirements

  • On GitLab.com there will be no instance level permissions
  • On Self-Managed/Dedicated there will be no top-level group permissions
  • Default permissions will be the current existing ones
  • Users with multiple roles always receive the maximum possible permissions. For example, a user has a developer and a maintainer role in a hierarchy. Developers can enable agents, but maintainers can't. Then the user is still allowed to enable agents because of their developer role.
  • The created service can later on be used by other teams around DAP as well
  • We might want to consider adding a cache, as we need to check for each execution all the permission configurations for all the roles a user has.

Backend/API Development

1. Data Model Design

  • Design permission schema for all 4 DAP permission actions
  • Define a structure for storing permissions:
    • 4 actions (create_edit_agents_flows, publish_agents_flows, enable_agents_flows, execute_agents_flows)
    • 6 role levels (guest, planner, reporter, developer, maintainer, owner)
    • Both instance-level and group-level contexts
  • Database schema design
  • Migration scripts for new tables
  • Default permission seeding matches current behavior

2. API Endpoints

  • Read Permissions API
    • Instance-level: GET /api/v4/admin/application_settings/dap_permissions
    • Group-level: GET /api/v4/groups/:id/dap_permissions
    • Return all 8 permission actions with their allowed roles
  • Update Permissions API
    • Instance-level: PUT /api/v4/admin/application_settings/dap_permissions
    • Group-level: PUT /api/v4/groups/:id/dap_permissions
    • Accept permission configuration changes.
    • Validate role assignments
    • Authorization: only admins/owners can modify
  • API Documentation
    • Document all endpoints
    • Request/response examples
    • Error codes and validation rules

3. Permission Enforcement Service

  • Create DapPermissionService
  • Implement the permission check method: can_user_perform_action?(user, namespace, action)
  • Support all four permission actions.
  • Permission resolution logic (instance vs. group)
  • Replace hardcoded checks across DAP features:
    • Creation/Editing
    • Publishing agents/flows
    • Enabling agents/flows
    • Executing agents/flows

Frontend Development

1. UI Components

  • Implement the design suggested by Andrew above
  • Create DapUserAccessSettings component
    • For each role, checkboxes/toggles for each permission
    • Responsive layout
    • Based on Andrew's Figma design

2. Integration into Duo Settings

  • Add User Access section to Duo Settings page
  • Position between existing Duo configuration
  • Handle instance-level vs. group-level contexts

Database Schema

dap_permission_settings table:

  • Stores permission configurations
  • One row per namespace (NULL for instance-level)
  • Contains all 4 actions mapped to allowed roles
  • Unique constraint on namespace_id
  • Timestamps for tracking

Next Steps

  1. Review & Approval
    • Engineering team review
    • Product review (Susie/Jordan)
    • Communication design (Andrew Bacon)
    • Collaborative approval to proceed
  2. Team Coordination
    • Kickoff with workflow catalog
    • Kickoff with agent foundations
    • Create issues
  3. Technical Prep
    • Hands-on with DAP
    • Set up feature flag
  4. Start Development
Edited by 🤖 GitLab Bot 🤖