A gestão de identidades e acessos deixou de ser uma preocupação restrita às grandes aplicações corporativas.

Mesmo ambientes menores normalmente precisam lidar com autenticação, recuperação de senha, políticas de acesso, encerramento de sessões, integração com diretórios, autenticação multifator e diferentes níveis de permissão.

Quando cada aplicação implementa esses recursos de forma independente, o resultado tende a ser uma arquitetura fragmentada, com regras duplicadas, experiências diferentes para o usuário e maior esforço de manutenção.

É nesse cenário que entra o Red Hat build of Keycloak, ou RHBK.

O RHBK permite centralizar autenticação, autorização e gestão de identidades, utilizando padrões como OpenID Connect, OAuth 2.0 e SAML. A aplicação deixa de validar diretamente a senha do usuário e passa a confiar em tokens emitidos por um provedor de identidade centralizado.

Para demonstrar esse funcionamento na prática, disponibilizei um projeto no GitHub com um laboratório completo utilizando:

• Red Hat Enterprise Linux;
• Red Hat build of Keycloak;
• Podman;
• Nginx;
• uma aplicação SPA em JavaScript;
• OpenID Connect;
• autorização baseada em roles;
• MFA com TOTP;
• certificados TLS emitidos pela ZeroSSL.

O repositório foi criado para estudo, treinamento e demonstrações. Ele não representa uma arquitetura de produção.

O problema que o RHBK ajuda a resolver

Em uma aplicação tradicional, é comum encontrar componentes responsáveis por:

• receber usuário e senha;
• armazenar hashes de credenciais;
• criar e invalidar sessões;
• recuperar senhas;
• implementar MFA;
• controlar tentativas de login;
• decidir quais telas e operações cada usuário pode acessar;
• integrar contas internas com Active Directory, LDAP ou outros provedores.

Essas funções não fazem parte diretamente da regra de negócio da maioria das aplicações. Ainda assim, precisam ser implementadas corretamente, atualizadas e auditadas.

Com o RHBK, a aplicação delega a autenticação a uma plataforma especializada.

O fluxo passa a funcionar da seguinte maneira:

1. o usuário acessa a aplicação;
2. a aplicação redireciona o navegador para o RHBK;
3. o RHBK solicita as credenciais;
4. quando configurado, o RHBK também solicita o segundo fator;
5. após a autenticação, o RHBK devolve um código de autorização;
6. a aplicação obtém os tokens;
7. os recursos são apresentados de acordo com as roles do usuário.

Nesse modelo, a aplicação demonstrativa não armazena senhas e não mantém uma base própria de usuários. A identidade é gerenciada pelo RHBK.

Arquitetura do laboratório

O laboratório foi intencionalmente mantido simples para facilitar a compreensão do fluxo.

Usuário
   |
   | HTTPS
   v
Portal demonstrativo
Nginx + SPA em Podman
   |
   | Redirecionamento OpenID Connect
   v
Red Hat build of Keycloak
   |
   | Login, MFA, emissão de tokens e roles
   v
Portal demonstrativo

Os componentes possuem as seguintes responsabilidades:

A aplicação demonstra autenticação centralizada, login e logout, leitura de claims, renovação do token, acesso ao Account Console e apresentação condicional de uma área administrativa.

Autenticação e autorização são controles diferentes

Um dos pontos mais importantes desse laboratório é mostrar que autenticação e autorização não são a mesma coisa.

Autenticação responde:

Quem é o usuário?

Autorização responde:

O que esse usuário pode acessar?

Para demonstrar essa separação, foram criadas duas realm roles:

usuario
gestor

Também foram criados dois perfis:

Os dois usuários conseguem se autenticar. Entretanto, somente o usuário que recebe a role gestor visualiza a área administrativa.

A aplicação verifica as roles presentes no token emitido pelo RHBK. Portanto, a decisão não depende de um texto fixo no frontend ou do nome do usuário.

É importante destacar que ocultar um menu no navegador não substitui o controle no backend. Em uma aplicação real, APIs e serviços também precisam validar o token, o emissor, o público, a expiração e as permissões antes de executar qualquer operação protegida.

Publicação do RHBK com Podman

No ambiente demonstrativo, o próprio RHBK é executado em um container Podman.

Primeiro, são criados os diretórios persistentes:

mkdir -p /opt/rhbk-demo/{data,certs}
chmod 750 /opt/rhbk-demo/data /opt/rhbk-demo/certs

A estrutura esperada é:

/opt/rhbk-demo/
├── certs/
│   ├── fullchain.pem
│   └── private.key
└── data/

A imagem do RHBK é obtida do registry da Red Hat:

podman login registry.redhat.io

Depois, o container pode ser iniciado com um comando semelhante ao utilizado no laboratório:

export RHBK_ADMIN_PASSWORD='ALTERE-ESTA-SENHA'
podman run -d \
  --name rhbk-demo \
  --restart=always \
  -p 443:8443 \
  -e KC_BOOTSTRAP_ADMIN_USERNAME=admin \
  -e KC_BOOTSTRAP_ADMIN_PASSWORD="${RHBK_ADMIN_PASSWORD}" \
  -v /opt/rhbk-demo/data:/opt/keycloak/data:Z \
  -v /opt/rhbk-demo/certs/fullchain.pem:/opt/keycloak/conf/fullchain.pem:ro,Z \
  -v /opt/rhbk-demo/certs/private.key:/opt/keycloak/conf/private.key:ro,Z \
  registry.redhat.io/rhbk/keycloak-rhel9:26.4 \
  start-dev \
  --https-port=8443 \
  --https-certificate-file=/opt/keycloak/conf/fullchain.pem \
  --https-certificate-key-file=/opt/keycloak/conf/private.key \
  --hostname=rhbk-demo.pensandolinux.com.br

O mapeamento:

443:8443

faz com que a porta HTTPS da VM seja encaminhada para a porta HTTPS configurada dentro do container.

Os sufixos :Z nos volumes são relevantes em sistemas com SELinux, porque ajustam o contexto dos arquivos montados para permitir o acesso pelo container.

Após criar e validar um administrador permanente, a variável utilizada no shell pode ser removida:

unset RHBK_ADMIN_PASSWORD

O exemplo utiliza start-dev e o banco local dev-file. Isso facilita o laboratório, mas não é apropriado para produção.

Certificados ZeroSSL

O laboratório utiliza certificados emitidos pela ZeroSSL.

Normalmente, são fornecidos arquivos semelhantes a:

certificate.crt
ca_bundle.crt
private.key

Para servidores que precisam apresentar a cadeia completa, o certificado do domínio e o bundle da autoridade certificadora são combinados:

cat certificate.crt ca_bundle.crt > fullchain.pem

O repositório também contém um script para organizar esses arquivos:

./scripts/prepare-zerossl-cert.sh \
  /root/portal-cert-source \
  /opt/rhbk-demo/portal-certs

A validação pode ser feita com:

openssl x509 \
  -in /opt/rhbk-demo/portal-certs/fullchain.pem \
  -noout \
  -subject \
  -issuer \
  -dates \
  -ext subjectAltName

Esse comando permite conferir:

• domínio presente no SAN;
• emissor do certificado;
• início da validade;
• data de expiração.

Nenhuma chave privada, certificado real, senha ou token deve ser enviado ao GitHub. O repositório inclui regras de .gitignore e orientações específicas para reduzir esse risco.

Configuração do realm

Depois que o RHBK está disponível, o primeiro passo é criar um realm.

No laboratório foi utilizado:

cliente-demo

Um realm representa um domínio isolado de identidades. Ele possui seus próprios:

• usuários;
• grupos;
• roles;
• clientes;
• sessões;
• políticas;
• fluxos de autenticação.

Os usuários da aplicação devem ser criados dentro desse realm, e não no realm administrativo master.

Criação das roles

Dentro do realm cliente-demo, foram criadas:

usuario
gestor

Essas são realm roles, portanto podem ser utilizadas por diferentes clientes dentro do mesmo realm.

Para ambientes maiores, também é possível utilizar client roles, grupos e composite roles. A escolha depende do modelo de autorização da organização.

Criação dos usuários

Os usuários demonstrativos foram configurados desta forma:

usuario.demo → usuario
gestor.demo  → usuario, gestor

As senhas foram definidas como permanentes para que o laboratório não solicite alteração no primeiro login.

Para uma demonstração, o e-mail pode permanecer vazio. Entretanto, recursos como recuperação de senha, verificação de endereço e envio de ações exigirão configuração adequada de e-mail no realm.

Criação do cliente OpenID Connect

A aplicação precisa ser representada no RHBK por um cliente.

No laboratório:

Client type: OpenID Connect
Client ID: portal-demo
Client authentication: Off
Standard flow: On
Direct access grants: Off
Implicit flow: Off

Como se trata de uma SPA executada no navegador, o cliente é público. Isso significa que não existe um client secret que possa ser mantido de forma segura dentro do JavaScript entregue ao usuário.

O fluxo utilizado é o Authorization Code Flow, por meio da opção Standard flow.

As URLs precisam ser definidas com atenção:

Root URL:
https://portal-lab.pensandolinux.com.br:9443
Home URL:
https://portal-lab.pensandolinux.com.br:9443/
Valid redirect URIs:
https://portal-lab.pensandolinux.com.br:9443/*
Valid post logout redirect URIs:
https://portal-lab.pensandolinux.com.br:9443/*
Web origins:
https://portal-lab.pensandolinux.com.br:9443

Um erro comum nessa etapa é configurar incorretamente Valid redirect URIs, resultando em bloqueio do retorno após o login.

Em produção, é recomendável restringir ao máximo os padrões de redirecionamento e evitar curingas excessivamente amplos.

A configuração usada no laboratório está documentada no repositório.

Configuração da aplicação

A aplicação possui um arquivo config.js com os dados necessários para localizar o provedor de identidade:

window.PORTAL_CONFIG = {
  keycloakUrl: "https://rhbk-demo.pensandolinux.com.br",
  realm: "cliente-demo",
  clientId: "portal-demo",
  portalUrl: "https://portal-lab.pensandolinux.com.br:9443",
  accountUrl:
    "https://rhbk-demo.pensandolinux.com.br/realms/cliente-demo/account/"
};

A aplicação usa o adaptador JavaScript do Keycloak para:

• inicializar a sessão;
• redirecionar para o login;
• obter o token;
• renovar o token;
• acessar claims;
• encerrar a sessão.

O arquivo nginx.conf também precisa ser revisado, especialmente em relação a:

• server_name;
• caminhos dos certificados;
• Content Security Policy;
• cabeçalhos de segurança;
• cache dos arquivos estáticos.

A configuração utilizada no exemplo está disponível no próprio projeto.

Deploy do portal

Com os certificados preparados e o cliente configurado, a aplicação pode ser publicada.

Primeiro, libere a porta utilizada pelo laboratório:

firewall-cmd --permanent --add-port=9443/tcp
firewall-cmd --reload
firewall-cmd --query-port=9443/tcp

Também é necessário liberar a porta no firewall do provedor de nuvem.

Depois, execute:

chmod +x scripts/*.sh
./scripts/deploy-portal.sh

O script:

1. valida os certificados;
2. copia os arquivos da SPA;
3. baixa o adaptador keycloak.js;
4. ajusta as permissões;
5. remove um container anterior, quando existente;
6. inicia o Nginx com Podman;
7. apresenta o status final.

O container é publicado desta forma:

host:9443 → container:443

Essa porta foi utilizada porque, no laboratório, o RHBK já ocupa a porta 443 do mesmo IP.

Validação do ambiente

Depois do deploy, alguns testes ajudam a separar problemas de aplicação, container, rede e certificado.

Verificar o container

podman ps
podman logs --tail=100 rhbk-demo-app

Validar o Nginx

podman exec rhbk-demo-app nginx -t

Verificar a porta

ss -lntp | grep 9443

Testar localmente preservando o hostname

curl -vk \
  --resolve portal-lab.pensandolinux.com.br:9443:127.0.0.1 \
  https://portal-lab.pensandolinux.com.br:9443/

O resultado esperado é:

HTTP/1.1 200 OK

O uso de --resolve é útil porque direciona o hostname para 127.0.0.1 sem alterar o arquivo /etc/hosts, preservando o nome utilizado no TLS e no virtual host.

Demonstração de MFA

Para demonstrar autenticação multifator, o usuário gestor.demo pode receber a ação obrigatória:

Configure OTP

No próximo acesso:

1. o usuário informa login e senha;
2. o RHBK apresenta um QR Code;
3. o QR Code é lido por um aplicativo autenticador;
4. o usuário confirma o código temporário;
5. nos próximos logins, senha e TOTP são solicitados.

Uma boa forma de apresentar o cenário é manter:

usuario.demo → somente senha
gestor.demo  → senha e MFA

Isso permite explicar que o MFA reforça a autenticação, enquanto a role gestor determina a autorização.

O segundo fator não concede acesso administrativo por si só. Da mesma forma, possuir a role gestor não substitui a necessidade de autenticação forte para uma conta privilegiada.

O que observar no token

Após a autenticação, a aplicação permite visualizar informações presentes no token, como:

• emissor;
• usuário;
• realm;
• client ID;
• roles;
• data de emissão;
• expiração;
• identificador da sessão.

Esse ponto é importante porque, em uma arquitetura baseada em tokens, os serviços não precisam consultar a senha nem necessariamente consultar o servidor de identidade a cada requisição.

A API recebe o access token e deve validar, entre outros itens:

• assinatura;
• algoritmo;
• emissor;
• audiência;
• validade;
• escopos ou roles.

A autenticação centralizada não elimina a responsabilidade de autorização dos serviços. Cada API continua responsável por proteger corretamente seus próprios recursos.

O que precisa mudar em produção

O objetivo deste projeto é tornar os conceitos visíveis. Por isso, algumas decisões foram deliberadamente simplificadas.

Também devem ser considerados:

• proteção e rotação de segredos;
• políticas de senha;
• proteção contra força bruta;
• configuração de cookies;
• timeouts de sessão;
• headers HTTP;
• eventos administrativos;
• auditoria;
• integração com SIEM;
• backups testados;
• atualização e gestão de vulnerabilidades;
• integração com LDAP ou Active Directory;
• ciclo de vida de contas;
• segregação entre administração e uso da aplicação.

O próprio repositório deixa explícito que não implementa alta disponibilidade, banco externo, cofre de segredos, renovação automática de certificados, observabilidade completa ou hardening de produção.

Considerações finais

A principal vantagem de uma plataforma de identidade não está apenas em centralizar uma tela de autenticação.

O valor aparece quando diferentes aplicações passam a utilizar políticas consistentes de acesso, sessões, autenticação forte e integração com provedores corporativos.

Com o RHBK, uma organização pode desacoplar a identidade da regra de negócio das aplicações e estabelecer uma camada central para:

• autenticação;
• Single Sign-On;
• MFA;
• federação de identidades;
• gestão de sessões;
• emissão de tokens;
• autorização baseada em roles;
• integração com aplicações legadas e modernas.

O laboratório publicado no GitHub apresenta um caminho prático para entender esses conceitos com Podman, RHEL, Nginx, OpenID Connect e certificados ZeroSSL.

Ele não deve ser reproduzido diretamente como arquitetura de produção, mas pode servir como ponto de partida para estudos, provas de conceito, capacitação e demonstrações técnicas.

Repositório do projeto

O código, os scripts, a documentação da arquitetura, o guia de demonstração, a configuração do RHBK e o troubleshooting estão disponíveis no repositório BktechBrazil/rhbk-podman-demo.

Para organizações que precisam modernizar a gestão de identidades, centralizar autenticação, implementar MFA ou integrar aplicações por OpenID Connect, o RHBK pode representar uma base consistente para estruturar essa camada.

Caso queira avaliar como essa solução pode ser aplicada ao seu ambiente, integrar aplicações existentes ou apoiar uma estratégia corporativa de identidade e acesso, entre em contato comigo.