Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

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

Aperta
  • Qualcosa non va?
#14,162 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

@hanahmily ci sta già lavorando.

Dal 25/10/2026.

  • #1439 di @hanahmily — aperta

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
20/100
Tipo di issue
Funzionalità
Chiarezza
Specificata chiaramente
Stato di attività
Attiva
Stack tecnologico
node.js, typescript
Ambito
authentication, backend-api-design, documentation, testing

Direzione di ricerca

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.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

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.

Lingua principale
Java
Stelle
25k
Fork
6.6k
Merge medio
15h 37m
PR unite (30g)
32

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di apache/skywalking

Tutte le issue di apache/skywalking

Issue simili

Altre issue su Java

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.