Resolver problemas de configuração do fornecedor de identidade para o serviço FHIR

A API versão 2023-12-01 do serviço FHIR® nos Serviços de Dados de Saúde do Azure dá suporte a dois provedores de identidade, além da ID do Microsoft Entra. Para fornecer acesso com escopo aos usuários, configure os dois provedores de identidade preenchendo a smartIdentityProviders authenticationConfiguration seção do objeto.

Mensagens de erro

Aqui estão as mensagens de erro que ocorrem se os provedores de identidade SMART do serviço FHIR falharem, com ações recomendadas a serem tomadas para resolver o problema.

Erros de pedido de API FHIR

Quando utiliza um token emitido por um fornecedor de identidade SMART para fazer pedidos para o serviço FHIR, pode encontrar dois códigos de erro comuns: 401 Unauthorized ou 403 Forbidden. Para iniciar a resolução de problemas, verifique a configuração do elemento smartIdentityProviders, especialmente se o serviço FHIR for novo.

Siga estas etapas para verificar a configuração correta do elemento smartIdentityProviders.

1. Verifique se o elemento smartIdentityProviders está configurado corretamente.

2. Verifique se a cadeia authority está correta. Verifique se a cadeia authority é a autoridade de token para o fornecedor de identidade que emitiu o token de acesso.

3. Verifique se a cadeia authority é uma autoridade de token válida. Faça um pedido para a configuração openID connect. Anexe /.well-known/openid-configuration no final da cadeia aubrowser navigatesthority e cole-a no browser. Se o valor estiver correto, o browser navegará até ao openid-connect configuration. Se isso não acontecer, há um problema com a cadeia.

   Exemplo:

   https://<YOUR_IDENTITY_PROVIDER_AUTHORITY>/authority/v2.0/.well-known/openid-configuration
   
   

4. Verifique se a cadeia clientId está correta. Verifique se a cadeia clientId corresponde à ID de cliente (ou ID da aplicação) da aplicação de recurso definida no fornecedor de identidade.

5. Verifique se o método de pedido é GET. O único tipo de solicitação suportado é GET, porque os allowedDataActions valores suportam apenas Read.

6. Verifique as reclamações de JSON Web Token (JWT). Se o token de acesso estiver disponível, descodifique-o utilizando ferramentas online como jwt.ms. Depois que o token é descodificado, as reclamações podem ser inspecionadas quanto à sua correção.

   

7. Verifique o iss (reclamação do emissor). Certifique-se de que a reclamação iss corresponde exatamente ao valor issuer na sua configuração OpenID de fornecedores de identidade.

   Pegue no valor authority da configuração do fornecedor de identidade smartIdentityProvider, anexe-o com /.well-known/openid-configuration e cole-o no seu browser. Se o valor estiver correto, o browser navegará até à configuração do OpenID Connect.

   Exemplo:

   https://<YOUR_IDENTITY_PROVIDER_AUTHORITY>/authority/v2.0/.well-known/openid-configuration
   

8. Verifique o azp ou appid (parte autorizada ou reivindicação appid). A reclamação azp ou appid deve corresponder exatamente ao valor clientId fornecido na configuração do fornecedor de identidade smartIdentityProvider.

9. Verifique o aud (reclamação de audiência). A reclamação aud tem de corresponder exatamente ao valor audience fornecido na configuração do fornecedor de identidade smartIdentityProvider.

10. Verifique o scp (reclamação de âmbito). A reclamação scp é necessária. Se estiver em falta, o pedido falhará. O formato da reclamação scp tem de estar em conformidade com os Âmbitos SMART on FHIR v1. É importante notar que, atualmente, o serviço FHIR suporta apenas âmbitos de leitura. Uma variação aceitável de Âmbitos SMART on FHIR v1 substitui qualquer barra (/) por um ponto (.) e um asterisco (*) por all. Por exemplo, uma versão aceitável do âmbito patient/*.read SMART on FHIR é patient.all.read.

11. Verifique o fhirUser ou extension_fhirUser (reclamação de utilizador FHIR). A reclamação fhirUser ou extension_fhirUser é necessária. Se estiver em falta, o pedido falhará. Esta reclamação vincula o utilizador no fornecedor de identidade a um recurso de utilizador no serviço FHIR. O valor tem de ser o URL totalmente qualificado de um recurso no serviço FHIR que representa o indivíduo para o qual o token de acesso é emitido. Por exemplo, o token de acesso emitido para um paciente que fez iniciou sessão deve ter uma reclamação fhirUser ou extension_fhirUser que tenha o URL totalmente qualificado de um recurso de paciente no serviço FHIR.

Esquema para configurar fornecedores de identidade

O elemento smartIdentityProviders é uma matriz JSON que contém um ou dois identity provider configurations. Um identity provider configuration consiste em

• Um valor de cadeia authority que deve ser o URL totalmente qualificado da autoridade de token dos fornecedores de identidade.

• Uma matriz applications que contém o recurso application configurations do fornecedor de identidade.

{
  "properties": {
    "authenticationConfiguration": {
      "authority": "string",
      "audience": "string",
      "smartProxyEnabled": "bool",
      "smartIdentityProviders": [
        {
          "authority": "string",
          "applications": [
            {
              "clientId": "string",
              "allowedDataActions": "array",
              "audience": "string"
            }
          ]
        }
      ]
    }
  }
}

O elemento applications é uma matriz JSON que contém um ou dois application configurations.

Os application configuration são constituídos por:

• Um valor de cadeia clientId para a ID de cliente (também conhecida como ID da aplicação) da aplicação de recurso do fornecedor de identidade.

• Uma cadeia audience utilizada para validar a reclamação aud em tokens de acesso.

• Uma matriz de allowedDataActions. A matriz allowedDataActions só pode conter o valor da cadeia Read.

{
  "authority": "string",
  "applications": [
    {
      "clientId": "string",
      "allowedDataActions": "array",
      "audience": "string"
    }
  ]
}

{
  "clientId": "string",
  "allowedDataActions": "array",
  "audience": "string"
}

Próximos passos

Usar o Azure Ative Directory B2C para conceder acesso ao serviço FHIR

Configurar vários fornecedores de identidades