Configuração de identidade do Azure Active Directory para a API do Azure para FHIR

Quando estiver a trabalhar com dados de cuidados de saúde, é importante garantir que os dados estão seguros e que não podem ser acedidos por utilizadores ou aplicações não autorizados. Os servidores FHIR utilizam o OAuth 2.0 para garantir esta segurança de dados. A API do Azure para FHIR é protegida com o Azure Active Directory, que é um exemplo de um fornecedor de identidade OAuth 2.0. Este artigo fornece uma descrição geral da autorização do servidor FHIR e os passos necessários para obter um token para aceder a um servidor FHIR. Embora estes passos se apliquem a qualquer servidor FHIR e a qualquer fornecedor de identidade, vamos percorrer a API do Azure para FHIR como o servidor FHIR e o Azure Active Directory (Azure AD) como o nosso fornecedor de identidade neste artigo.

Descrição geral do controlo de acesso

Para que uma aplicação cliente aceda à API do Azure para FHIR, tem de apresentar um token de acesso. O token de acesso é uma coleção com codificação Base64 assinada de propriedades (afirmações) que transmitem informações sobre a identidade e funções e privilégios do cliente concedidos ao cliente.

Existem várias formas de obter um token, mas a API do Azure para FHIR não se importa com a forma como o token é obtido, desde que seja um token devidamente assinado com as afirmações corretas.

Por exemplo, quando utiliza o fluxo de código de autorização, o acesso a um servidor FHIR passa pelos quatro passos seguintes:

1. O cliente envia um pedido para o /authorize ponto final de Azure AD. Azure AD redirecionará o cliente para uma página de início de sessão onde o utilizador se autenticará com as credenciais adequadas (por exemplo, nome de utilizador e palavra-passe ou autenticação de dois fatores). Veja os detalhes sobre como obter um código de autorização. Após a autenticação bem-sucedida, é devolvido um código de autorização ao cliente. Azure AD só permitirá que este código de autorização seja devolvido a um URL de resposta registado configurado no registo da aplicação cliente.
2. A aplicação cliente troca o código de autorização por um token de acesso no /token ponto final do Azure AD. Quando pede um token, a aplicação cliente poderá ter de fornecer um segredo do cliente (a palavra-passe das aplicações). Veja os detalhes sobre como obter um token de acesso.
3. O cliente faz um pedido à API do Azure para FHIR, por exemplo GET /Patient, para procurar todos os pacientes. Quando o cliente faz o pedido, inclui o token de acesso num cabeçalho de pedido HTTP, por exemplo Authorization: Bearer eyJ0e..., em eyJ0e... que representa o token de acesso codificado Base64.
4. A API do Azure para FHIR valida que o token contém afirmações adequadas (propriedades no token). Se tudo der saída, concluirá o pedido e devolverá um pacote FHIR com resultados ao cliente.

É importante ter em atenção que a API do Azure para FHIR não está envolvida na validação de credenciais de utilizador e não emite o token. A autenticação e a criação de tokens são efetuadas por Azure AD. A API do Azure para FHIR simplesmente valida que o token está assinado corretamente (é autêntico) e que tem afirmações adequadas.

Estrutura de um token de acesso

O desenvolvimento de aplicações de Fast Healthcare Interoperability Resources (FHIR®) envolve frequentemente a depuração de problemas de acesso. Se for negado acesso a um cliente à API do Azure para FHIR, é útil compreender a estrutura do token de acesso e como pode ser descodificado para inspecionar os conteúdos (as afirmações) do token.

Normalmente, os servidores FHIR esperam um JSON Web Token (JWT, por vezes pronunciado "jot"). Consiste em três partes:

Parte 1: um cabeçalho, que pode ter o seguinte aspeto:

    {
      "alg": "HS256",
      "typ": "JWT"
    }

Parte 2: o payload (as afirmações), por exemplo:

    {
     "oid": "123",
     "iss": "https://issuerurl",
     "iat": 1422779638,
     "roles": [
        "admin"
      ]
    }

Parte 3: uma assinatura, que é calculada concatenando os conteúdos codificados em Base64 do cabeçalho e o payload e calculando um hash criptográfico dos mesmos com base no algoritmo (alg) especificado no cabeçalho. Um servidor poderá obter chaves públicas do fornecedor de identidade e validar que este token foi emitido por um fornecedor de identidade específico e não foi adulterado.

O token completo consiste nas versões codificadas em Base64 (na verdade codificadas por URL Base64) desses três segmentos. Os três segmentos são concatenados e separados por um . (ponto).

Um exemplo de um token é apresentado como:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJvaWQiOiIxMjMiLCAiaXNzIjoiaHR0cHM6Ly9pc3N1ZXJ1cmwiLCJpYXQiOjE0MjI3Nzk2MzgsInJvbGVzIjpbImFkbWluIl19.gzSraSYS8EXBxLN_oWnFSRgCzcmJmMjLiuyu5CSpyHI

O token pode ser descodificado e inspecionado com ferramentas como https://jwt.ms. O resultado da descodificação do token é:

{
  "alg": "HS256",
  "typ": "JWT"
}.{
  "oid": "123",
  "iss": "https://issuerurl",
  "iat": 1422779638,
  "roles": [
    "admin"
  ]
}.[Signature]

Obter um token de acesso

Conforme mencionado, existem várias formas de obter um token a partir de Azure AD. São descritos em detalhe na documentação do programador Azure AD.

Utilize um dos seguintes protocolos de autenticação:

• Fluxo de código de autorização.
• Fluxo de credenciais de cliente.

Existem outras variações (por exemplo, devido ao fluxo) para obter um token. Veja a documentação do Azure AD para obter detalhes. Quando utiliza a API do Azure para FHIR, existem alguns atalhos para obter um token de acesso (por exemplo, para fins de depuração) com a CLI do Azure.

Passos seguintes

Neste documento, aprendeu alguns dos conceitos básicos envolvidos na proteção do acesso à API do Azure para FHIR com Azure AD. Para obter informações sobre como implementar a API do Azure para o serviço FHIR, veja

Implementar o Azure API for FHIR

FHIR® é uma marca registada do HL7 e é utilizada com a permissão de HL7.