ADR-0025: Identity Role + Permission Scope Model
Статус
Accepted
Контекст
Pin требует RBAC + ABAC: роли удобны для администрирования, но каждый backend метод должен проверять конкретный permission и scope. Permissions приходят из разных сервисов, но должны быть видимы в одном каталоге для Admin Panel, Gateway и IdentityContext.
Решение
Identity Service хранит:
PermissionScopeDefinition— каталог всех permissions всех сервисов;Role— человекочитаемая роль;RolePermission— связь роли с permission и scope restrictions;UserRoleAssignment— связь пользователя с ролью и сроком действия.
Runtime authorization проверяет PermissionCode + scope, а не RoleCode.
Последствия
- Роли можно менять без изменения service code.
- Permission catalog становится source of truth для UI и actor context.
- Owning service остается ответственным за final business policy.
- Изменение permissions роли инвалидирует permission snapshots и sessions по policy.
Ссылки
- Permission И Policy Catalog
- Identity Service
Обратные ссылки
Автоссылки: где используется этот документ.
- API (2): PUT /api/agent/crm/{deals|leads}/{id}/executor — Передать ведение (сменить исполнителя), PUT /api/agent/crm/{deals|leads}/{id}/responsible — Назначить/снять ответственного (куратора)
- Use Cases (6): UC-CRM-009. Передача ведения сделки (смена исполнителя), UC-CRM-010. Назначение/снятие ответственного (куратора) процесса — ответственный ≠ исполнитель, UC-CRM-011. Лид с несколькими инвесторами: назначение основного инвестора, UC-CRM-012. Управление составом участников лида (добавление/снятие: второй агент, супруг/юрист инвестора), UC-CRM-015. Явное назначение исполнителя для разрешения спора о комиссии, US-реестр «Участники и владение процессами» (US-CRM-PART / US-AG-ADMIN / US-AGT-MULTI / US-INV-CO)
- adr (4): ADR-0046: Security Coding Standards, ADR-0051: API Gateway (YARP) Как Единая Точка Входа, ADR-0061: Независимый агент, отвязка от агентства и приглашения по номеру телефона, ADR-0070: Мульти-агентство и контекст активного агентства