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:
- 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. - 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. - 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 exemploAuthorization: Bearer eyJ0e...
, emeyJ0e...
que representa o token de acesso codificado Base64. - 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:
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
FHIR® é uma marca registada do HL7 e é utilizada com a permissão de HL7.