Configurazione dell'identità di Azure Active Directory per l'API di Azure per FHIR

  • Articolo

Quando si lavora con i dati del settore sanitario, è importante assicurarsi che i dati siano protetti e che non sia possibile accedervi da utenti o applicazioni non autorizzati. I server FHIR usano OAuth 2.0 per garantire la protezione dei dati. L'API di Azure per FHIR è protetta con Azure Active Directory, un esempio di provider di identità OAuth 2.0. Questo articolo offre una panoramica dell'autorizzazione del server FHIR e dei passaggi necessari per ottenere un token per accedere a un server FHIR. Anche se questi passaggi si applicano a qualsiasi server FHIR e a qualsiasi provider di identità, verrà illustrata l'API di Azure per FHIR come server FHIR e Azure Active Directory (Azure AD) come provider di identità in questo articolo.

Panoramica del controllo di accesso

Per consentire a un'applicazione client di accedere all'API di Azure per FHIR, deve presentare un token di accesso. Il token di accesso è una raccolta con codifica Base64 firmata di proprietà (attestazioni) che trasmettono informazioni sull'identità e i ruoli e i privilegi del client concessi al client.

Esistono molti modi per ottenere un token, ma l'API di Azure per FHIR non interessa il modo in cui il token viene ottenuto purché sia un token firmato in modo appropriato con le attestazioni corrette.

Ad esempio, quando si usa il flusso del codice di autorizzazione, l'accesso a un server FHIR esegue i quattro passaggi seguenti:

Autorizzazione FHIR

  1. Il client invia una richiesta all'endpoint /authorize di Azure AD. Azure AD reindirizzerà il client a una pagina di accesso in cui l'utente eseguirà l'autenticazione usando le credenziali appropriate, ad esempio nome utente e password o autenticazione a due fattori. Vedere i dettagli su come ottenere un codice di autorizzazione. Al termine dell'autenticazione, al client viene restituito un codice di autorizzazione . Azure AD consentirà di restituire questo codice di autorizzazione solo a un URL di risposta registrato configurato nella registrazione dell'applicazione client.
  2. L'applicazione client scambia il codice di autorizzazione per un token di accesso all'endpoint /token di Azure AD. Quando si richiede un token, l'applicazione client potrebbe dover fornire un segreto client (la password delle applicazioni). Vedere i dettagli su come ottenere un token di accesso.
  3. Il client effettua una richiesta all'API di Azure per FHIR, ad esempio GET /Patient, per cercare tutti i pazienti. Quando il client effettua la richiesta, include il token di accesso in un'intestazione di richiesta HTTP, ad esempio Authorization: Bearer eyJ0e..., dove eyJ0e... rappresenta il token di accesso con codifica Base64.
  4. L'API di Azure per FHIR convalida che il token contenga attestazioni appropriate (proprietà nel token). Se tutto viene estratto, completerà la richiesta e restituirà un bundle FHIR con i risultati al client.

È importante notare che l'API di Azure per FHIR non è coinvolta nella convalida delle credenziali utente e non rilascia il token. La creazione di autenticazione e token viene eseguita da Azure AD. L'API di Azure per FHIR verifica semplicemente che il token sia firmato correttamente (è autentico) e che abbia attestazioni appropriate.

Struttura di un token di accesso

Lo sviluppo di applicazioni FHIR® (Fast Healthcare Interoperability Resources) comporta spesso il debug dei problemi di accesso. Se un client ha negato l'accesso all'API di Azure per FHIR, è utile comprendere la struttura del token di accesso e come può essere decodificato per esaminare il contenuto (le attestazioni) del token.

I server FHIR in genere prevedono un token JSON Web (JWT, talvolta pronunciato "jot"). È costituito da tre parti:

Parte 1: Un'intestazione, che potrebbe essere simile alla seguente:

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

Parte 2: Payload (attestazioni), ad esempio:

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

Parte 3: Firma, calcolata concatenando il contenuto codificato Base64 dell'intestazione e il payload e calcolando un hash crittografico di essi in base all'algoritmo (alg) specificato nell'intestazione. Un server sarà in grado di ottenere chiavi pubbliche dal provider di identità e di verificare che il token sia stato emesso da un provider di identità specifico e non sia stato manomesso.

Il token completo è costituito dalle versioni con codifica Base64 (in realtà codificate con URL Base64) di questi tre segmenti. I tre segmenti sono concatenati e separati con un . (punto).

Un esempio di token viene visualizzato come segue:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJvaWQiOiIxMjMiLCAiaXNzIjoiaHR0cHM6Ly9pc3N1ZXJ1cmwiLCJpYXQiOjE0MjI3Nzk2MzgsInJvbGVzIjpbImFkbWluIl19.gzSraSYS8EXBxLN_oWnFSRgCzcmJmMjLiuyu5CSpyHI

Il token può essere decodificato ed esaminato con strumenti come https://jwt.ms. Il risultato della decodifica del token è:

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

Come ottenere un token di accesso

Come accennato, esistono diversi modi per ottenere un token da Azure AD. Sono descritti in dettaglio nella documentazione per sviluppatori di Azure AD.

Usare uno dei protocolli di autenticazione seguenti:

Esistono altre varianti (ad esempio a causa del flusso) per ottenere un token. Per informazioni dettagliate, vedere la documentazione di Azure AD . Quando si usa l'API di Azure per FHIR, sono disponibili alcuni collegamenti per ottenere un token di accesso ( ad esempio a scopo di debug) usando l'interfaccia della riga di comando di Azure.

Passaggi successivi

In questo documento sono stati illustrati alcuni concetti di base relativi alla protezione dell'accesso all'API di Azure per FHIR tramite Azure AD. Per informazioni su come distribuire il servizio API di Azure per FHIR, vedere

Distribuire l'API di Azure per FHIR

FHIR® è un marchio registrato di HL7 e viene usato con l'autorizzazione di HL7.