[Feature] Canopy auth 2/2: SSO (OIDC/OAuth2), break-glass and the auth design doc

Đã đóng
  • Có gì không ổn?
#14,162 0 bình luận 0 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 1 ngày

@hanahmily đang làm issue này rồi.

Từ ngày 25/10/2026.

  • #1439 của @hanahmily — đang mở

Đánh giá

Độ khó
5/5
Thời gian dự kiến
Hơn một tuần
Mức phù hợp với người mới
20/100
Loại issue
Tính năng
Độ rõ ràng
Đặc tả rõ ràng
Mức độ hoạt động
Sôi nổi
Công nghệ
node.js, typescript
Lĩnh vực
authentication, backend-api-design, documentation, testing

Hướng nghiên cứu

Start with the referenced Horizon authentication files under apps/bff/src/user/oidc/, roles.ts and break-glass.ts, then read leaf issue #14159 for the required auth and session interfaces. Implementing this issue spans SSO flows, role mapping, break-glass behavior, web login, docs and tests, so first map those entry points and the acceptance oracles. Done means the mock IdP and login tests pass, config keys and examples are documented, and the design doc and README cover the listed requirements.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

database feature

Summary (executable leaf 2/2 of #14001)

Canopy's SSO authentication, plus break-glass and the design doc, following Horizon's apps/bff/src/user/oidc/ (discovery.ts, flows.ts, identity.ts, route.ts, userinfo.ts), roles.ts and break-glass.ts. It has three parts:

  • Part 1: the sso backend with role mapping.
  • Part 2: break-glass gated by SSO health.
  • Part 3: canopy/docs/auth-design.md and the remaining README.

It depends on leaf 1/2 (#14159): the auth config, argon2id verifier, session store, middleware and tokens.

Part 1: sso backend

  1. auth.backend: sso with auth.sso.providers[], in Horizon's provider shape: an OIDC provider (issuer discovery, e.g. Google) and an OAuth2 provider (explicit authorize/token/userinfo endpoints, e.g. GitHub). Authorization-code flow with PKCE and state/nonce; the client secret comes from env or a file, never the config file in clear.
  2. Routes: start (GET /auth/sso/:provider/start) and callback (GET /auth/sso/:provider/callback) create a #14159 session for the resolved principal. GET /auth/meta (or the existing meta) lists the configured providers for the web login page.
  3. Role mapping auth.sso.roles: defaultRoles, roleByEmail (exact, case-insensitive), roleByDomain, mapped to Canopy roles via #14159's role mapping. With no matching role, the login is refused, not given a default admin.
  4. The resolution order in the middleware becomes Horizon's: IdP bearer token, if supported by the provider (see out of scope), → API token (#14159) → cookie session.
  5. Web: the login page shows a button per provider when backend: sso.
  6. An SSO health probe (discovery or token endpoint reachable) exposed internally for Part 2.

Part 2: break-glass

  1. auth.breakGlass: {enabled, users[]} with argon2id hashes (#14159's argon2id verifier, with the same dummy-hash timing).
  2. With auth.backend: sso, POST /auth/login against break-glass users is accepted only while Part 1's SSO health probe reports unhealthy. Otherwise it gets the same 401 as a wrong password.
  3. Every break-glass success logs at WARN with username and client IP. Failures log at INFO without the password.
  4. The web login page shows the break-glass form only when the server reports SSO unhealthy and break-glass enabled.

Part 3: design doc and README

  1. canopy/docs/auth-design.md covering:
    • the auth.* / session.* config schema and its parity with Horizon's;
    • the resolution order (IdP bearer → API token → cookie session);
    • role re-resolution and caching (30 s success, never failure);
    • username as the credential anchor;
    • break-glass gating;
    • the argon2id (WASM) choice and bcrypt compatibility;
    • in-memory sessions and their restart behavior;
    • what is out of scope (LDAP/SAML, multi-IdP).
  2. canopy/README.md: every CANOPY_AUTH_* / config key with defaults, plus minimal working examples for local, sso (GitHub OAuth2 and a generic OIDC), tokens, and break-glass. Remove obsolete LDAP-centric or CANOPY_USERS-only notes, keeping the alias documented as deprecated.
  3. A link from the main BanyanDB docs where Canopy is described, if such a page exists.

Concrete oracle (against an in-process mock IdP; no live provider)

Part 1
  • Mock OIDC issuer: start → redirect with PKCE code_challenge, state, nonce → callback with a valid code → session cookie, /auth/session shows the mapped role.
  • roleByEmail: {[email protected]: admin}, roleByDomain: {x.com: viewer} → alice is admin and [email protected] readonly. [email protected] with no defaultRoles → refused (403 page/JSON).
  • A wrong state or replayed code → 400, no session. An ID token with a wrong nonce, aud or issuer → refused.
  • Mock GitHub-style OAuth2 (userinfo plus emails endpoint) → email resolved, role mapped.
Part 2
  • SSO healthy (mock) + correct break-glass password → 401 invalid_credentials.
  • SSO unhealthy + correct password → session, and exactly one WARN containing the username and IP.
  • SSO unhealthy + wrong password → 401, one argon2id verify ran.
  • backend: local → breakGlass is ignored and the startup log says so.

Acceptance criteria

  • Vitest tests with an in-process mock IdP (no network), a controllable SSO health probe and log capture cover every oracle line, through app.inject. Web login-page tests cover the provider buttons and the break-glass form.
  • The #14001 acceptance "GitHub OAuth2 end-to-end (consent screen)" is covered by the mock flow, plus a documented manual check with a real GitHub OAuth app; the manual check isn't automated.
  • Every config key the code reads appears in the README with its default. A test run by npm test compares the schema's keys to the README table, and the README examples parse with the real config loader.
  • Existing tests pass; links are valid; license artifacts are regenerated if dependencies change.

Out of scope

LDAP/SAML, multi-IdP failover, accepting IdP access tokens as bearers unless Horizon does (follow Horizon; note the choice), health-probe tuning beyond Horizon's defaults.

Ngôn ngữ chính
Java
Star
25k
Fork
6.6k
Merge trung bình
12 giờ 41 phút
Pull request đã merge (30 ngày)
48

Chuẩn bị môi trường

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của apache/skywalking

Tất cả issue của apache/skywalking

Issue tương tự

Thêm issue về Java

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.