[APIView] Lightweight App Permissions

[AlitzelMendez]

closes: #13004

Implements a group-based Role-Based Access Control (RBAC) system for APIView that replaces the current simple "approvers" configuration list with a more robust permissions model.

Problem

The current APIView permissions model has several limitations:

• No formal role hierarchy - everyone in the approvers list gets the same elevated permissions
• No language scoping - users can't be designated as architects for specific languages
• The approvers list is self-administered with no audit trail
• Limited ability to show/hide UI features based on user roles

Solution

This PR implements a group-based permissions system with:

Two types of roles:

• Global Roles (ServiceTeam, SdkTeam, Admin) - apply to all languages
• Language-Scoped Roles (Architect, DeputyArchitect) - must be assigned to a specific language

Key Features:

• Groups are stored in a new Permissions Cosmos DB container
• Users inherit roles from all groups they belong to
• Effective permissions are computed by merging roles from all group memberships
• 15-minute cache with automatic invalidation when groups are updated
• Admin-only management UI for permission groups

API Endpoints

Method	Endpoint	Description	Auth
GET	/api/permissions/me	Get current user's permissions	Authenticated
GET	/api/permissions/groups	List all groups	Admin
GET	/api/permissions/groups/{groupId}	Get group details	Admin
POST	/api/permissions/groups	Create group	Admin
PUT	/api/permissions/groups/{groupId}	Update group	Admin
DELETE	/api/permissions/groups/{groupId}	Delete group	Admin
POST	/api/permissions/groups/{groupId}/members	Add members	Admin
DELETE	/api/permissions/groups/{groupId}/members/{userId}	Remove member	Admin

Screenshots

Button only visible to Admins

Page only accessible to Admins

[Copilot]

Pull request overview

This PR implements a lightweight role-based access control (RBAC) system for APIView to manage user permissions through groups. The system introduces five role types (Service Team, SDK Team, Deputy Architect, Architect, and Admin) that can be assigned globally or scoped to specific programming languages. The implementation includes a comprehensive admin UI for managing permission groups, members, and role assignments.

Key changes:

• Backend permission system with Cosmos DB storage, caching layer, and RESTful API
• Frontend admin page with group management, role assignment, and member management capabilities
• Integration with existing user profile system to include permissions data
• Comprehensive test coverage for both backend and frontend components

Reviewed changes

Copilot reviewed 29 out of 29 changed files in this pull request and generated 7 comments.

Show a summary per file

File	Description
tools/apiview/parsers/apiview-treestyle-parser-schema/permissions.tsp	TypeSpec schema defining permission models and role types
src/dotnet/APIView/APIViewWeb/LeanModels/PermissionsModels.cs	C# models for permissions with polymorphic role assignments
src/dotnet/APIView/APIViewWeb/Repositories/CosmosPermissionsRepository.cs	Cosmos DB repository for CRUD operations on permission groups
src/dotnet/APIView/APIViewWeb/Managers/PermissionsManager.cs	Business logic layer with caching for permission operations
src/dotnet/APIView/APIViewWeb/LeanControllers/PermissionsController.cs	REST API endpoints with admin authorization checks
src/dotnet/APIView/APIViewWeb/Startup.cs	Dependency injection configuration for new services
src/dotnet/APIView/ClientSPA/src/app/_models/permissions.ts	TypeScript models matching backend schema
src/dotnet/APIView/ClientSPA/src/app/_services/permissions/permissions.service.ts	Angular service for permissions API and helper methods
src/dotnet/APIView/ClientSPA/src/app/_components/admin-permissions-page/*	Complete admin UI with group management, role assignment, and member management
src/dotnet/APIView/ClientSPA/src/app/_components/shared/nav-bar/*	Integration of admin link visible only to admins
src/dotnet/APIView/APIViewUnitTests/PermissionsManagerTests.cs	Comprehensive backend unit tests
src/dotnet/APIView/ClientSPA/src/app/_services/permissions/permissions.service.spec.ts	Frontend service unit tests
src/dotnet/APIView/ClientSPA/src/app/_components/admin-permissions-page/*.spec.ts	Admin page component unit tests

[AlitzelMendez]

In person conversation:

1. Validate GithubUser (with our database) -> can we do autocomplete? maybe with the user in our database?
2. bulk add, multiple people add the same time
3. if you are nothing we try it you like the azure sdk team? as default

[AlitzelMendez]

This is the updated version, with autocomplete of existing users

[praveenkuttappan]

Can we use GitHub team instead of implementing this logic in APIView? I feel that this role management within APIView is not really required. We can create a GitHub team or DL for each language and check if a user is part of that architect group? Is there any reason for service team member role? We can check with Wes whether we can use GitHub teams to verify architect membership.

[AlitzelMendez]

Can we use GitHub team instead of implementing this logic in APIView? I feel that this role management within APIView is not really required. We can create a GitHub team or DL for each language and check if a user is part of that architect group? Is there any reason for service team member role? We can check with Wes whether we can use GitHub teams to verify architect membership.

I don't think this resolves all our needs.

1. We will keep having just one approver list that is not specific to languages. Once we have the new UI and it becomes easier to switch between different languages, making an error or approving something that is not intended can become more likely.
2. We will have the same list for staging and production. Well, we could create more lists—is this an option?
3. The list of approvers is not the same as the names on our approver list. Which one is out of date? Who is maintaining these lists? Will we have control over them?
4. We will not have an "Admin" group, which is something we really want to leverage.

I think it is an interesting approach, especially for requests like: #13589, but I am unsure if it can fulfill our needs.