ORG-0020 — Identidade e acesso com Keycloak

Toda stack com usuários precisa de login, permissões e perfis. Se cada uma resolver do seu jeito, contas se duplicam, sessões de públicos diferentes se misturam, e um perfil novo exige mudar código porque o código conferia o perfil e não a permissão.

1. Toda área restrita autentica no Keycloak da plataforma (toolbox). Aplicação pública não tem client nem sessão, mas declara o que expõe (ORG-0017).
2. Realm por população, não por aplicação: colaboradores e clientes externos nunca no mesmo realm. Criar realm é decisão da plataforma.
3. Um client por aplicação, confidencial, Authorization Code com PKCE S256, sem direct access grants, com redirect e post-logout redirect exatos.
4. Permissões como client roles <recurso>:<ação>; perfis como client roles compostos perfil:<nome>. O código confere permissões, nunca perfis.
5. Atribuição só por grupo (ou pelos default roles do realm, quando toda a população tem o mesmo acesso, e isso também se declara). Ninguém recebe papel direto no usuário.
6. Sem senha nem sessão local; autenticado sem permissão vê uma página que diz qual perfil e qual grupo dão acesso.
7. Configuração como código em eng/auth/ (script idempotente que nunca regenera segredo); IdP externo por script, com credenciais do ambiente; realms de desenvolvimento versionados, com um usuário de exemplo por perfil; um documento de acesso por aplicação em docs/acesso/.
8. Realms, clients, permissões, perfis, grupos e IdPs ficam numa ADR da stack (a ADR-0008 pré-escrita).

• Um perfil novo é configuração (script + grupo), não código.
• O login local funciona sem script, com os realms de desenvolvimento importados.

O detalhe está na documentação da arquitetura.