110 lines
4.0 KiB
Markdown
110 lines
4.0 KiB
Markdown
# Architecture: NODE.DC Multi-App Platform
|
||
|
||
## Цель
|
||
|
||
Собрать единую платформенную основу для Launcher, Task Manager / Plane и будущих приложений NODE.DC.
|
||
|
||
Целевой пользовательский сценарий:
|
||
|
||
1. Пользователь открывает Launcher.
|
||
2. Если сессии нет, его отправляет в Authentik.
|
||
3. После логина Launcher получает identity и app access.
|
||
4. Launcher показывает только доступные приложения.
|
||
5. Переход в Task Manager не требует повторного логина.
|
||
6. Прямой URL Task Manager тоже защищен.
|
||
|
||
## Роли компонентов
|
||
|
||
`Authentik` является единым Identity Provider:
|
||
|
||
- логин;
|
||
- пароль;
|
||
- активность пользователя;
|
||
- группы;
|
||
- app access;
|
||
- OIDC claims;
|
||
- будущие invite/enrollment/MFA flows.
|
||
|
||
`Launcher` является control plane:
|
||
|
||
- входная точка пользователя;
|
||
- список доступных приложений;
|
||
- admin UI управления пользователями и доступами;
|
||
- backend-интеграция с Authentik API;
|
||
- audit log админских действий.
|
||
|
||
`Task Manager / Plane` остается отдельным приложением:
|
||
|
||
- собственная БД;
|
||
- собственные workspace/project/task/comment модели;
|
||
- собственные роли workspace/project;
|
||
- OIDC login через Authentik;
|
||
- mapping внешней identity на существующего Plane user.
|
||
|
||
`Reverse proxy` является внешним защитным и маршрутизирующим слоем:
|
||
|
||
- единая точка входа;
|
||
- HTTPS в staging/production;
|
||
- routing по app domain;
|
||
- forward headers для Authentik;
|
||
- deny для пользователей без app access.
|
||
|
||
## Repository layout
|
||
|
||
Рабочая схема:
|
||
|
||
```text
|
||
NODEDC/
|
||
DOC/
|
||
platform/
|
||
docs/
|
||
infra/
|
||
packages/
|
||
tasks/
|
||
|
||
/Users/dcconstructions/Downloads/mnt/data/nodedc_launcher
|
||
/Users/dcconstructions/Downloads/mnt/data/dc_taskmanager/NODEDC_TASKMANAGER
|
||
```
|
||
|
||
`platform/` не забирает исходники Launcher и Plane внутрь себя. Он хранит только платформенный слой и договоренности между приложениями.
|
||
|
||
## Data ownership
|
||
|
||
Не создается единая общая таблица `users` для всех приложений.
|
||
|
||
Логическая схема:
|
||
|
||
```text
|
||
authentik_db -> identity, groups, app access
|
||
launcher_db -> app registry, local profiles, audit
|
||
plane_db -> workspace, projects, tasks, comments, app roles
|
||
future_app_db -> доменная логика будущих приложений
|
||
```
|
||
|
||
Связь между identity и локальными пользователями выполняется через explicit mapping, а не через прямое чтение чужих таблиц.
|
||
|
||
## Auth flow
|
||
|
||
Для приложений, которые контролируются кодом:
|
||
|
||
- OIDC Authorization Code Flow + PKCE;
|
||
- backend/session или BFF layer;
|
||
- JWT/JWKS validation server-side;
|
||
- проверка `issuer`, `audience`, `exp`, `sub`;
|
||
- проверка app access group;
|
||
- локальный user profile или external identity link.
|
||
|
||
Для legacy/временных приложений допускается reverse proxy forward-auth, но это временный внешний слой, а не единственная долгосрочная модель.
|
||
|
||
## Plane migration rule
|
||
|
||
Существующий Plane user нельзя пересоздавать.
|
||
|
||
Нужен mapping:
|
||
|
||
```text
|
||
authentik_user.sub -> existing plane_user.id
|
||
```
|
||
|
||
Plane должен логинить существующего пользователя по link, сохраняя все старые workspace, assignee, owner, created_by, comments и attachments.
|