ATM Platform
101 lines
6.0 KiB
Markdown
101 lines
6.0 KiB
Markdown
———————————————————————————————————————————————————————————————————————————==
|
|
P5.4 — o realm de um tenant novo.
|
|
|
|
DERIVADO de `tenants/plataforma/realm/athleticmap-realm.json`, que e o realm
|
|
que existe hoje. Os nove papeis e o cliente `spa` sao os de la — NAO inventei
|
|
nenhum, e um papel a mais aqui seria um papel que nenhum codigo verifica.
|
|
|
|
06/10/2026 — DECIMO papel: `atm_responsavel` (responsavel legal: app dos pais
|
|
e o portal). Verificado por codigo: o cadastro o da ao marcar o acompanhante
|
|
como responsavel (AcessoAoAppServico), o SPA leva quem so o tem ao /portal, e
|
|
a TravaDaEquipe o deixa FORA da leitura da equipe. Junto, o mapper
|
|
`acompanhante_id` (atributo -> claim) nos clients `spa` e `app`, como o
|
|
`funcionario_id`. Realm que ja existe nao reimporta: rodar
|
|
`scripts/papel_responsavel_nos_realms.py --check` / `--aplicar`.
|
|
|
|
── OS MARCADORES ───────────────────────────────────────────────────────────
|
|
|
|
{{REALM}} `athleticmap-<N>` — decidido em 2026-09-19
|
|
{{TENANT}} o nome comercial, que vira o subdominio
|
|
|
|
SAO COISAS DIFERENTES desde aquela decisao. O realm e numerado porque uma
|
|
instancia so de Keycloak nao comporta quatro realms chamados `athleticmap`; o
|
|
subdominio e o nome que o cliente ve.
|
|
|
|
── CLIENTES ────────────────────────────────────────────────────────────────
|
|
|
|
`spa` — tela web do tenant (redirect HTTPS do subdominio).
|
|
`app` — app mobile (PKCE; redirect `com.athleticmap.app:/oauthredirect` e
|
|
`https://{{TENANT}}.athleticmap.com/app/callback`). Sem ROPC.
|
|
Tenants ja provisionados: `scripts/client_app_mobile.py --aplicar`.
|
|
|
|
── O DOMINIO DOS REDIRECTS ─────────────────────────────────────────────────
|
|
|
|
`athleticmap.com`, e nao `athleticmap.influxdigital.com.br` — o canonico foi
|
|
decidido em 2026-09-16 (P0.9). O tenant `plataforma` ainda usa o antigo porque
|
|
o corte de dominio nao aconteceu; um tenant NOVO ja nasce no certo.
|
|
|
|
Se o corte nao tiver acontecido quando o primeiro tenant for provisionado, ESTE
|
|
arquivo precisa mudar junto — e o sintoma de esquecer e um login que redireciona
|
|
para um host que nao resolve.
|
|
|
|
── NAO HA USUARIO AQUI ─────────────────────────────────────────────────────
|
|
|
|
O administrador do cliente e criado pela Admin API, DEPOIS do realm, porque ele
|
|
precisa de senha temporaria e de `UPDATE_PASSWORD` — e nenhum dos dois cabe num
|
|
arquivo versionado. Ver EtapaCriarRealm.
|
|
———————————————————————————————————————————————————————————————————————————==
|
|
|
|
|
|
— O SMTP, E POR QUE ELE VIVE AQUI ————————————————————————————————————
|
|
|
|
Quem manda o e-mail de boas-vindas e o PROPRIO KEYCLOAK, pela Admin API
|
|
(`execute-actions-email`), e nao o `servico-captacao`.
|
|
|
|
Isso tem tres consequencias boas:
|
|
|
|
1. o nosso servico nao precisa de biblioteca de e-mail nem de configuracao de
|
|
SMTP — uma dependencia a menos e um segredo a menos por onde vazar;
|
|
2. o link de definicao de senha e gerado e assinado pelo proprio Keycloak, com
|
|
validade propria. Nao ha token nosso a inventar, guardar nem expirar;
|
|
3. "fechar a aba e voltar depois pelo link do e-mail" — criterio do card —
|
|
funciona de graca, porque o link nao depende de sessao nenhuma.
|
|
|
|
A SENHA DO SMTP NAO FICA NESTE ARQUIVO. Os marcadores sao preenchidos em memoria,
|
|
no momento de criar o realm, a partir da configuracao do servico — o realm e
|
|
criado pela API, e nao commitado. Um `{{SMTP_SENHA}}` literal que chegasse ao
|
|
Gitea seria um segredo versionado, que e exatamente o que a regra do repositorio
|
|
proibe.
|
|
|
|
── O `frontendUrl`, E POR QUE ELE NAO E OPCIONAL ───────────────────────────
|
|
|
|
`https://auth.athleticmap.com` — o host de autenticacao DOS TENANTS.
|
|
|
|
Sem ele o Keycloak monta os links (e o `iss` do token) com o `KC_HOSTNAME`
|
|
global, que e `auth-plataforma.athleticmap.com`. E os runtimes do tenant
|
|
validam contra `ATM_ISSUER`, que o molde consolidado define como
|
|
`https://auth.athleticmap.com/realms/{{REALM}}`.
|
|
|
|
Os dois TEM de bater. Quando nao batiam, em 2026-09-24, o login do primeiro
|
|
tenant provisionado morria antes de comecar: a SPA redirecionava para um host
|
|
sem certificado e sem rota, e mesmo passando por cima o token seria recusado
|
|
pelos runtimes.
|
|
|
|
Nao da para resolver so no `KC_HOSTNAME` porque ele e um so, e a plataforma
|
|
depende do valor antigo — os servicos dela estao configurados com
|
|
`auth-plataforma`. Dai o `frontendUrl` por realm, que e exatamente para isto.
|
|
|
|
── DUPLO FATOR DO DONO (07/10/2026) ────────────────────────────────────────
|
|
|
|
`browserFlow: browser-2fa-dono` e os quatro `authenticationFlows`: copia do
|
|
`browser` de fabrica do 26.7.5 com OTP OBRIGATORIO para `atm_admin` (quem nao
|
|
tem configura no primeiro login) e passkey dispensando o codigo. Politica OTP
|
|
TOTP/SHA1/6 digitos/30 s (Google e Microsoft Authenticator). Os outros fluxos
|
|
(`direct grant`, `clients`...) o Keycloak cria sozinho na importacao — provado
|
|
num 26.7.5 descartavel. Realms que ja existem: `scripts/dois_fatores_nos_realms.py`
|
|
(le ESTE arquivo). Recuperacao e saida de emergencia: docs/dois-fatores-do-dono.md.
|
|
|
|
ATENCAO ao testar este molde num Keycloak local: o `frontendUrl` aponta para
|
|
`https://auth.athleticmap.com` — o formulario de login POSTA EM PRODUCAO. Zere
|
|
`attributes.frontendUrl` no realm de teste.
|