docs(oidc): zaufane domeny instytucjonalne i wiązanie istniejących kont - #33
Merged
Conversation
Trzy przełączniki obrazu BPP ustawiane w .env po stronie bpp-deploy (DJANGO_BPP_OIDC_GRACE_BIND, _TRUSTED_EMAIL_DOMAINS, _GRACE_BIND_PRIVILEGED) nie były nigdzie opisane — operator nie miał skąd wiedzieć, że istnieją. docs/konfiguracja/architektura.md dostaje sekcję operatorską: dlaczego BPP wiąże po (issuer, sub) a nie po e-mailu, dlaczego ścieżka przez profil jest ślepa w instalacji czysto-SSO (wymaga hasła lokalnego), dlaczego zaufanie bierze się z domeny a nie z email_verified (realm LDAP-owy trzyma instytucjonalny adres w `mail`, a email_verified opisuje prywatny `email`), oraz dwa ostrzeżenia — lista domen jako jedyna bramka trybu uprzywilejowanego i zakaz "naprawiania" kolizji przez czyszczenie adresu e-mail. CLAUDE.md dostaje sam tripwire wg podziału z docs-sync: reguła, objaw po którym agent rozpozna sytuację (pełny flow 302/302/200 bez 403 — WAF NIE jest winny — plus komunikat z appservera i błąd AXES na /oidc/callback/) oraz trzy anty-fixy. Dowody i detal zostają w docs/. mkdocs build --strict czysty. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_0175jeAqUnobDP5rz1waUAow
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Dokumentuje trzy przełączniki obrazu BPP, które operator ustawia w
.envpostronie
bpp-deploy, a które nie były opisane nigdzie:Wynik sesji diagnostycznej: użytkownik nie mógł wejść do BPP przez Keycloaka,
podejrzenie padło na WAF — a flow OIDC przechodził w całości (302 → 302 → 200,
zero 403). Winna była kolizja dwóch zmergowanych PR-ów w
bpp, naprawionaw iplweb/bpp#753.
Co gdzie trafiło (wg podziału z
docs-sync)docs/konfiguracja/architektura.md— sekcja operatorska: dlaczego BPP wiążetożsamość po
(issuer, sub)a nie po e-mailu, dlaczego domyślna ścieżka „Połączkonto z SSO" jest ślepa w instalacji czysto-SSO (wymaga hasła lokalnego),
dlaczego zaufanie bierze się z domeny a nie z
email_verified(realm LDAP-owytrzyma adres instytucjonalny w
mail, aemail_verifiedopisuje prywatnyemail), tabela zmiennych, warianty z prefiksem skrótu uczelni.Dwa ostrzeżenia, bo oba przypadki realnie kosztują:
trzeba potwierdzić z IT, że użytkownik nie zmieni sobie adresu w katalogu;
puste konto i osierocą prawdziwe, z uprawnieniami i powiązanym
Autorem.CLAUDE.md— sam tripwire: reguła, objaw po którym agent rozpozna sytuację(pełny flow bez 403 → WAF nie jest winny; komunikat z
appservera; błąd AXES na/oidc/callback/) i trzy anty-fixy. Dowody i detal zostają wdocs/, zgodniez zasadą, że CLAUDE.md ładuje się w każdej sesji.
Weryfikacja
mkdocs build --strict— czysty, bez zerwanych linków i luk w nawigacji.Zmiany wyłącznie dokumentacyjne — żadnego kodu, skryptów ani Compose.
🤖 Generated with Claude Code
https://claude.ai/code/session_0175jeAqUnobDP5rz1waUAow