SILVER
/
NODEDC_PLATFORM
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
NODEDC_PLATFORM/docs/AUTH_BRANDED_LOGIN_RFC.md

5.1 KiB
Raw Blame History

NODE.DC branded login RFC

Цель

Пользователь должен видеть единое окно входа NODE.DC в визуальной логике текущего Plane login: темный фон, компактная карточка, NODE.DC logo, крупный заголовок, email/password, яркая CTA-кнопка.

При этом Authentik остается внутренним identity provider и продолжает владеть паролями, MFA, recovery, lockout, session, OAuth/OIDC и audit events.

Жесткие запреты

Запрещенные варианты реализации:

  • reverse proxy, который переписывает HTML Authentik на лету;
  • frontend-only форма в Launcher, которая принимает email/password;
  • BFF endpoint в Launcher, который принимает пароль пользователя и пересылает его в Authentik;
  • OAuth password grant / ROPC;
  • хранение паролей, refresh tokens или Authentik session cookies в frontend/localStorage;
  • обход Authentik CSRF, MFA, recovery, lockout, enrollment и audit flow.

Эти варианты расширяют trusted boundary платформы: Launcher становится обработчиком паролей, а это ломает разделение ответственности и усложняет аудит.

Выбранный безопасный путь

Базовый production-safe путь: Authentik-native branded flow.

  • UI кастомизируется через Brand/Flow внутри Authentik.
  • branding_custom_css задает NODE.DC look без HTML-прокси.
  • Password stage, Identification stage, User Login stage, MFA/recovery остаются штатными Authentik stages.
  • Identification stage связан со штатным Password stage, поэтому email и password показываются в одном Authentik challenge без передачи пароля в Launcher.
  • Launcher и Task Manager остаются OIDC clients и не получают пароль пользователя.
  • Direct links на Launcher/Task Manager продолжают идти через Authorization Code Flow + PKCE.
  • OAuth2 provider end-session использует штатный Authentik invalidation flow с UserLogoutStage, чтобы пользователь не попадал на Authentik application logout dashboard.

Если Brand/CSS не даст pixel-level соответствие Plane login, следующий допустимый уровень — кастомный Authentik template/flow executor внутри Authentik deployment. Это тоже остается IdP-side custom UI, но требует отдельной security review при каждом upgrade Authentik.

Runtime prototype

Локальный bootstrap настраивает Brand для auth.local.nodedc:

  • title: NODE.DC;
  • default authentication flow: default-authentication-flow;
  • flow title: Работайте во всех измерениях.;
  • default locale: ru;
  • theme: dark;
  • dark NODE.DC CSS из /templates/branding/nodedc-login.css;
  • без изменения password/MFA/recovery mechanics.

Файлы:

  • infra/authentik/bootstrap-dev.py — idempotent Brand/Flow bootstrap;
  • infra/authentik/custom-templates/branding/nodedc-login.css — native Authentik Brand CSS.

Security acceptance

Перед переводом в production нужно проверить:

  • пароль не проходит через Launcher/BFF/network logs вне Authentik;
  • CSRF token и Authentik cookies остаются штатными;
  • MFA/passkeys/recovery/enrollment работают после стилизации;
  • failed login/lockout/audit events остаются в Authentik;
  • logout/SLO закрывает Launcher и app sessions;
  • прямой заход task.local.nodedc и launcher.local.nodedc возвращает пользователя после login;
  • UI не содержит слова authentik в пользовательском flow;
  • кастомизация переживает restart контейнеров и повторный bootstrap;
  • fallback admin URL к Authentik остается доступен только как служебный контур.

Upgrade policy

Brand/CSS считается безопасным maintenance layer. Template override считается повышенным риском: перед обновлением Authentik нужно прогонять visual/security regression, потому что DOM web components может измениться.

Источники