Acesso e Multi-tenant

Como o Portal controla quem entra (clientes e administradores), o que cada papel pode fazer e como os tenants são publicados pelo proxy.

Quem acessa o Portal

O Portal tem dois públicos com formas de acesso completamente separadas:

• Clientes externos — autenticam com a conta própria do Portal (e-mail e senha, login federado ou autocadastro). Não têm e não precisam de conta no Alfresco. Enxergam apenas os próprios chamados e tarefas.
• Administradores — autenticam com a conta do PRESTOBR (Alfresco), a mesma usada no Share e no Content App. O acesso administrativo é liberado por capacidades (veja abaixo). Na tela de login, basta usar o usuário do Alfresco (sem @) em vez de um e-mail de cliente.

Papéis e capacidades de administração

O acesso à administração do Portal é controlado pelo sistema de Perfis e Capacidades do PRESTOBR — o mesmo da página Perfis (Define Roles). Duas capacidades governam o Portal:

Capacidade	Nível	O que permite
PortalSuperAdmin	Super-administrador	Administrar todos os tenants, criar e editar tenants e gerenciar as delegações de administração.
PortalAdmin	Administrador de tenant	Administrar um tenant específico — desde que o usuário (ou um grupo/perfil dele) esteja listado nas delegações daquele tenant.

Regras de acesso:

• Quem não tem nenhuma das duas capacidades não acessa a administração — o login administrativo é recusado.
• PortalSuperAdmin dá acesso amplo, independentemente de delegação.
• PortalAdmin só vale para os tenants em que o usuário foi delegado (veja Administração → Delegações de administração).
• As duas capacidades já vêm no perfil de sistema admins. Assim, os administradores do PRESTOBR (o usuário admin e o grupo de administradores) tornam-se super-administradores do Portal automaticamente, sem configuração extra.

Propagação das mudanças

As capacidades são reavaliadas a cada renovação de sessão (em poucos minutos). Conceder ou remover acesso pela página de Perfis no Share passa a valer no Portal sem que o usuário precise sair e entrar de novo.

Como os tenants são resolvidos

Cada tenant corresponde a um endereço (subdomínio) próprio — por exemplo externo1.htfapps.com, externo2.htfapps.com. A mesma instalação serve todos eles, identificando o tenant pelo endereço acessado, na seguinte ordem:

1. Correspondência exata com o endereço (FQDN) configurado no tenant.
2. Correspondência pelo subdomínio (slug do tenant).
3. Tenant padrão (default), usado como destino para qualquer endereço não mapeado.

Uma instalação que atende uma só organização simplesmente usa o tenant default em um único endereço — não há nada a configurar em termos de multi-tenant.

Configuração do proxy

O Portal não tem proxy próprio: ele é publicado pelo mesmo proxy do toolkit do PRESTOBR (terminação TLS e roteamento). Para o multi-tenant por subdomínio funcionar, o proxy precisa:

• Encerrar TLS e atender o conjunto de endereços dos tenants, usando um server_name com curinga que cubra todos os subdomínios — assim novos tenants não exigem reconfiguração nem reemissão de certificado.
• Rotear as requisições:
  • /backend/* → serviço de backend do Portal.
  • todo o resto (/*) → serviço de frontend do Portal.
• Preservar o cabeçalho Host original ao encaminhar para o backend.

Encaminhamento do Host é obrigatório

O backend identifica o tenant pelo endereço acessado, lido do cabeçalho Host. Se o proxy não repassar o Host original (por exemplo, encaminhando como Host: backend:3000), todos os subdomínios cairão no tenant padrão e mostrarão o mesmo conteúdo. No proxy, a regra de roteamento do backend precisa repassar o Host da requisição.

As configurações relevantes do proxy compartilhado (do repositório do toolkit) são:

Configuração	Para quê
SERVER_NAME	Endereços atendidos, incluindo o curinga dos subdomínios — ex.: interno.htfapps.com *.htfapps.com.
AUTO_SELFSIGN_HOSTS	Hosts cobertos pelo certificado autoassinado em ambiente interno — ex.: DNS:interno.htfapps.com,DNS:*.htfapps.com.
FRONTEND_URL	Endereço interno do serviço de frontend do Portal.
BACKEND_URL	Endereço interno do serviço de backend do Portal.

Além disso, o DNS precisa apontar os subdomínios de cada tenant para o servidor (um registro curinga *.htfapps.com cobre todos de uma vez).