Implementación interna de permisos

Esta página documenta cómo Summit Auth almacena y resuelve permisos. Para el contrato que consumen las aplicaciones, consulta Claims y permisos.

Catálogo de permisos

PermissionSubjectDefinition define los subjects y PermissionActionDefinition las acciones disponibles. A partir de ambos, ApplicationDbContext.GetDefaultPermissionDefinitions() mantiene el catálogo de PermissionDefinition.

El valor estable sigue este formato:

{module}.{subject}.{action}

Ejemplos vigentes:

auth.users.read
billing.subscriptions.manage
api.billing.sync
api.productaccess.sync

Cada definición también posee un Resource. Los permisos generales del servidor usan auth_server; los de una organización usan organization; otros módulos pueden exigir su propio resource o scope.

Permisos de usuarios y roles Identity

Los permisos generales se asignan como claims de tipo permission a usuarios o roles Identity. SummitPermissions centraliza los valores que utiliza el código para evitar strings divergentes.

Cuando una página declara:

[Authorize(Policy = SummitPermissions.BillingRead)]

PermissionAuthorizationPolicyProvider busca una PermissionDefinition activa con ese valor y crea la policy dinámicamente. El handler autoriza cuando se cumple alguna de estas condiciones:

El principal tiene el rol Identity Admin.
El principal lleva el permiso como claim directo.
Alguno de sus roles tiene ese permiso almacenado.

Cuando el permiso pertenece a un resource diferente de auth_server, la policy también exige el scope correspondiente en el principal.

Los permisos de roles no se copian a la cookie. El proveedor consulta AspNetRoles y AspNetRoleClaims y conserva temporalmente el resultado en IMemoryCache. Este diseño evita que el tamaño de la cookie crezca con cada permiso del rol.

Emisión de permisos

AuthorizationController calcula los permisos efectivos para UserInfo. Antes de aceptar un valor, verifica que la definición continúe activa y que su resource sea compatible con los scopes concedidos.

Los claims permission no se emiten en access tokens ni en ID tokens. Las aplicaciones deben obtenerlos mediante /connect/userinfo. Esto separa la autorización en vivo del tamaño del token.

Permisos de organizaciones

Los permisos organizacionales no se asignan a roles Identity. Cada organización tiene sus propios OrganizationRole, relacionados con PermissionDefinition mediante OrganizationRolePermission.

OrganizationAccessService.GetAccessAsync(userId, organizationId) valida:

que la organización esté activa;
que la membresía del usuario esté activa;
el rol organizacional de esa membresía;
el conjunto actual de permisos de ese rol.

OrganizationManagementService parte siempre de ese resultado para listar o modificar miembros, cambiar roles y asignar puestos de una suscripción.

El claim organization_permission tampoco se emite en tokens. Se calcula en UserInfo para la organización activa, mientras que la autorización dentro del servidor consulta la base de datos directamente.

Mapa de protección administrativa

La portada Pages/Admin/Index conserva AdminOnly. Las áreas funcionales usan permisos granulares:

Área	Lectura	Administración
Aplicaciones	`ApplicationsRead`	`ApplicationsManage`
Usuarios	`UsersRead`	`UsersManage`
Roles	`RolesRead`	`RolesManage`
Scopes	`ScopesRead`	`ScopesManage`
Tokens	`TokensRead`	`TokensRevoke` para la acción disponible
Autorizaciones	`AuthorizationsRead`	`AuthorizationsRevoke` para la acción disponible
Acceso a productos	`ProductAccessRead`	`ProductAccessManage`
Facturación	permisos de lectura/administración por recurso de Billing	permisos de administración por recurso de Billing
Auditoría	`AuditLogsRead`	solo lectura

Las APIs internas usan InternalBillingSync (api.billing.sync) e InternalProductAccessSync (api.productaccess.sync) con el esquema Bearer de OpenIddict Validation.