4.0 KiB

Raw Blame History

Architecture: NODE.DC Multi-App Platform

Цель

Собрать единую платформенную основу для Launcher, Task Manager / Plane и будущих приложений NODE.DC.

Целевой пользовательский сценарий:

Пользователь открывает Launcher.
Если сессии нет, его отправляет в Authentik.
После логина Launcher получает identity и app access.
Launcher показывает только доступные приложения.
Переход в Task Manager не требует повторного логина.
Прямой 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

Рабочая схема:

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 для всех приложений.

Логическая схема:

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:

authentik_user.sub -> existing plane_user.id

Plane должен логинить существующего пользователя по link, сохраняя все старые workspace, assignee, owner, created_by, comments и attachments.

4.0 KiB Raw Blame History Unescape Escape