Pular para conteúdo

Autorização #OAuth 2.0 para sistemas #credenciados

O protocolo OAuth 2.0 é o mecanismo padrão de autenticação e autorização para acesso aos serviços de saúde da plataforma iPeS, que já conta com uma infraestrutura de gerenciamento de APIs e gestão de identidades.

Em geral, as validações internas de segurança cruzam os dados do usuário ativo com atribuições e permissões provenientes de bases de dados e cadastros oficiais para obter informação contextual afim de garantir a legitimidade do acesso. Todavia, para sistemas credenciados cuja gestão de usuários não esteja integrada, são aceitos tokens com comportamento implícito assumindo confiabilidade na informação aferida.

Habilitando um novo sistema credenciado

  1. Atribuir a role RL_PORTAL_EMBEDDED ao usuário
  2. Gerar aplicação
  3. Subscrever nas respectivas APIs (sem introspecção de token, quando aplicável)
    • ConsentimentoCredenciadoService
    • EHRRunnerCredenciado
  4. Gerar as chaves (client ID e client secret) de produção

Emitindo tokens e invocando o portal iPeS on behalf of

Na perspectiva do sistema credenciado, o portal iPeS é um front-end embarcado ou invocado sob demanda para facilitar as interações com a plataforma. Neste sentido, a autorização é dita on behalf of quando o sistema, de posse de suas credenciais, emite seus próprios tokens e repassa ao portal iPeS para qualificar o acesso. Assim, no back-end o acesso ocorre pelo sistema através da iPeS.

Na prática, a emissão de tokens no sistema credenciado segue a recomendação do protocolo OAuth 2.0 para autorização entre sistemas (client credentials):

Atenção ao domínio, caso seja de desenvolvimento, utilizar dev.ipes.tech.

curl -H "Authorization: Basic `echo $CLIENT_ID:$CLIENT_SECRET | base64`" -d "grant_type=client_credentials&validity_period=3600" https://ipes.tech:/token

Na URL acima, $CLIENT_ID e $CLIENT_SECRET são as chaves geradas para o sistema no credenciamento. O parâmetro validity_period é opcional e representa a duração em segundos até a expiração do token. Note que caso já exista um token compatível e válido ele será reciclado. A resposta é do tipo:

{"access_token":"8357bf57-2d07-4604-a5ad-f137b82836c3","scope":"am_application_scope default","token_type":"Bearer","expires_in":3600}

E o consumo do portal iPeS, além dos parâmetros usuais, passa a transacionar o token:

https://ipes.tech/portal/#/credenciado?X-Organization=9911936&purposeofuse=Emergencia&X-Professional=60678666172&X-Patient=60678666172&access_token=8357bf57-2d07-4604-a5ad-f137b82836c3

Em maiores detalhes, os parâmetros são:

  • X-Organization: CNES do estabelecimento de saúde
  • purposeofuse: motivo do acesso declarado pelo profissional (Atendimento, Emergencia ou Legal)
  • X-Professional: CPF do profissional responsável pelo acesso
  • X-Patient: CNS/CPF do paciente cujos dados estão sendo acessados
  • access_token: token emitido com as credenciais do sistema credenciado

Exemplo: fluxo de credenciamento do SISUPA

sequenceDiagram
    Administrador->>Gateway: Cadastrar/acessar usuário
    Gateway-->>Administrador: OK
    Administrador->>Gateway: Atribuir role<br>RL_VISUALIZADOR_EMBARCADO
    Gateway-->>Administrador: OK
    Usuário->>Gateway: Criar aplicação
    Gateway-->>Usuário: OK
    Usuário->>Gateway: Subscrever nas APIs<br>ConsentimentoCredenciadoService<br>EHRRunnerCredenciado
    Gateway-->>Usuário: OK
    Usuário->>Gateway: Gerar chaves de produção
    Gateway-->>Usuário: <client ID e client secret>

Exemplo: fluxo de autorização do SISUPA

sequenceDiagram
    loop antes de expirar
        SISUPA->>Gateway: Authorization: Basic <credenciais><br/>POST /token
        Gateway-->>SISUPA: <token>
    end
    SISUPA->>Visualizador: GET /portal/credenciado?access_token=<token>
    Visualizador->>iPeS: Authorization: Bearer <token><br/>...
    alt token válido
        iPeS-->>Visualizador: HTTP 2xx
        Visualizador-->>SISUPA: Portal iPeS
    else token inválido
        iPeS-->>Visualizador: HTTP 4xx
        Visualizador-->>SISUPA: Erro ao carregar registros
    end