Prova de conceito da API LEC

O README da POC descreve endpoints REST adicionados ao próprio WAR da LEC, com autenticação por login e token armazenado em memória.

ElementoComportamento documentado
LoginValida usuário no AGHU e LDAP/AD, com exceções condicionadas ao ambiente.
TokenGerado pelo backend, mantido em memória e enviado como Bearer.
ValidadeUma hora no exemplo da POC.
ReinícioTokens deixam de valer quando o WildFly reinicia.
ClusterCada nó teria seu próprio store; seria necessário armazenamento distribuído ou outro desenho.
Endpoint demonstrativoConsulta filas ativas e retorna identificador, nome, situação, observação e especialidade.
Contrato sanitizado da POC
POST /lec/api/auth/login
Content-Type: application/json

{
  "usuario": "<USUARIO_CORPORATIVO>",
  "senha": "<SEGREDO_NAO_PUBLICADO>"
}

GET /lec/api/filas/ativas
Authorization: Bearer <TOKEN_EFEMERO>

Fluxos previstos com Regula +

  • A LEC envia uma solicitação de leito originada na indicação cirúrgica.
  • O Regula + atualiza a situação da solicitação — atendida, efetuada ou cancelada — e a LEC registra o histórico.
  • O Regula + consulta informações complementares na LEC para apoiar a operação.
  • As chamadas ocorrem backend a backend, sem segundo login do usuário final.
  • O login humano continua via LDAP/AGHU; a autenticação de sistemas é uma preocupação diferente.

Fluxo proposto com Microsoft Entra ID

Usuário ──login LDAP/AGHU──→ LEC
                              │ ação exige Regula +
                              ↓
LEC ──Client Credentials──→ Microsoft Entra ID
LEC ←──── access token JWT assinado ──────────
LEC ──HTTPS + Bearer JWT──→ Regula +
                              ↓
       valida assinatura JWKS + issuer + audience + expiração
  1. 1
    Registrar cada aplicação

    LEC e Regula + recebem identidades técnicas separadas no tenant corporativo.

  2. 2
    Solicitar token

    O backend chamador usa Client Credentials e mantém o token em cache até próximo da expiração.

  3. 3
    Chamar a API

    A requisição usa HTTPS, Bearer JWT e, quando necessário, um identificador auditável do usuário da sessão.

  4. 4
    Validar no serviço

    O backend chamado valida assinatura por JWKS, issuer, audience e expiração.

  5. 5
    Autorizar a operação

    Mesmo com token válido, regras funcionais e permissões da ação continuam no serviço.

O que o provedor de identidade não resolve

  • Autorização funcional para criar, cancelar ou consultar solicitações.
  • Idempotência de criação e atualização de status.
  • Timeout, retry, circuit breaker e degradação controlada.
  • Validação de campos e versionamento de contrato.
  • Auditoria de negócio e correlação ponta a ponta.
  • Proteção e rotação das credenciais técnicas fora do código.