Autenticare gli utenti per Zero Trust

Questo articolo consente agli sviluppatori di apprendere le procedure consigliate per autenticare gli utenti dell'applicazione nello sviluppo di applicazioni Zero Trust. Migliorare sempre la sicurezza dell'applicazione con i principi Zero Trust dei privilegi minimi e verificare in modo esplicito.

Token ID nell'autenticazione utente

Quando è necessario che un utente esegua l'autenticazione all'app, anziché raccogliere un nome utente e una password, l'applicazione può richiedere un token di identità (ID). L'autenticazione degli utenti tramite Microsoft Identity Platform evita rischi per la sicurezza che si verificano quando l'applicazione mantiene le credenziali utente. Quando si richiedono token ID, se un attore non valido viola o compromette l'applicazione, non sono presenti nomi utente e password corrispondenti nell'app.

Il token ID di Microsoft Identity Platform fa parte dello standard OpenID Connessione (OIDC) che specifica i token ID come token WEB JSON (JWT). La stringa lunga JWT comprende tre componenti:

1. Attestazioni di intestazione. Le attestazioni di intestazione presenti nei token ID includono typ (attestazione di tipo), alg (algoritmo per la firma del token) e kid (identificazione personale per la chiave pubblica per convalidare la firma del token).
2. Attestazioni di payload. Il payload o il corpo (la parte centrale di un token Web JSON) contiene una serie di coppie di attributi nome. Lo standard richiede che sia presente un'attestazione con il (nome dell'autorità iss emittente) che passa all'applicazione che ha emesso il token (attestazione auddel gruppo di destinatari o ).
3. Signature. Microsoft Entra ID genera la firma del token che le app possono usare per verificare che il token non sia modificato ed è possibile considerarlo attendibile.

L'esempio seguente di un token ID mostra informazioni sull'utente e conferma l'autenticazione per l'uso dell'applicazione.

{
  "typ": "JWT",
  "alg": "RS256",
  "kid": "1LTMzakihiRla_8z2BEJVXeWMqo"
}.
{
  "ver": "2.0",
  "iss": "https://login.microsoftonline.com/3338040d-6c67-4c5b-b112-36a304b66dad/v2.0",
  "aud": "6cb04018-a3f5-46a7-b995-940c78f5aef3",
  "exp": 1536361411,
  "iat": 1536274711,
  "nbf": 1536274711,
  "sub": "AAAAAAAAAAAAAAAAAAAAAIkzqFVrSaSaFHy782bbtaQ",
  "name": "Abe Lincoln",
  "preferred_username": "AbeLi@microsoft.com",
  "oid": "00000000-0000-0000-66f3-3332eca7ea81",
  "tid": "3338040d-6c67-4c5b-b112-36a304b66dad",
}.
.[Signature]

Token ID nella gestione degli accessi

Per ricevere l'ID applicazione (client), registrare l'app con Microsoft Identity Platform. Quando si riceve un token con un'attestazione del gruppo di destinatari (aud) che corrisponde all'ID client dell'app, l'utente identificato nel token autenticato nell'app. Gli amministratori IT potrebbero consentire a tutti gli utenti del tenant di usare l'app. Potrebbero consentire a un gruppo di cui l'utente è membro di usare l'app.

Se si riceve un token la cui attestazione del gruppo di destinatari è diversa dall'ID client dell'app, rifiutare immediatamente il token. L'utente non è autenticato nell'app perché ha eseguito l'accesso a un'altra app. Assicurarsi sempre che l'utente abbia l'autorizzazione per usare l'app.

Questi dettagli sulle attestazioni sono importanti nell'autenticazione utente:

• Un token Web JSON è valido fino alla scadenza. L'attestazione exp (scadenza) indica quando scade il token. Se l'ora corrente è precedente all'ora nell'attestazione exp , il token è valido.
• Non considerare l'utente come autenticato prima dell'ora specificata nell'attestazione (non prima del nbf tempo). I nbf tempi e exp del token definiscono la durata valida del token. Quando l'ora di scadenza è imminente, assicurarsi di ottenere un nuovo token ID.
• L'attestazione sub (attestazione oggetto) è un identificatore univoco per un utente dell'applicazione. Lo stesso utente ha un'attestazione diversa sub per altre app. Se si desidera archiviare i dati da associare a un utente e impedire a un utente malintenzionato di effettuare tale associazione, usare l'attestazione dell'oggetto. Poiché non espone l'identità di Microsoft Entra dell'utente, è il modo più privato per associare i dati a un utente. L'attestazione sub non è modificabile.
• Se si desidera condividere informazioni tra più applicazioni, usare la combinazione di attestazioni ID tenant (tid) e ID oggetto (oid) univoche per l'utente. L'ID tenant combinato e l'ID oggetto non sono modificabili.
• Indipendentemente da ciò che accade all'identità di un individuo, le subattestazioni , oide tid rimangono immutabili. Tutto ciò che riguarda l'utente può cambiare ed è comunque possibile chiavere i dati non identificando l'utente in base all'oggetto o alle attestazioni combinate tid e oid .

Autenticazione con OIDC

Per illustrare l'autenticazione utente, verranno esaminate le applicazioni che usano OIDC per autenticare un utente. Gli stessi principi si applicano alle app che usano SAML (Security Assertion Markup Language) o WS-Federation.

Un'app autentica l'utente quando l'applicazione richiede un token ID da Microsoft Identity Platform. I carichi di lavoro (applicazioni che non dispongono di utenti presenti, ma piuttosto vengono eseguiti come servizi, processi in background, daemon) ignorano questo passaggio.

È consigliabile richiedere sempre prima di tutto questo token. Per acquisire automaticamente un token in Microsoft Authentication Libraries (MSAL), l'app può iniziare con il AcquireTokenSilent metodo . Se l'app può eseguire l'autenticazione senza disturbare l'utente, riceve il token ID richiesto.

Se Microsoft Identity Platform non riesce a completare la richiesta senza interagire con l'utente, l'app deve eseguire il fallback al metodo MSAL AcquireTokenInteractive . Per acquisire in modo interattivo un token, eseguire la richiesta aprendo una superficie Web a un indirizzo nel https://login.microsoftonline.com dominio.

Da questa superficie Web, l'utente ha una conversazione privata con Microsoft Identity Platform. L'app non ha alcuna visualizzazione in questa conversazione, né ha alcun controllo della conversazione. Microsoft Identity Platform può richiedere un ID utente e una password, l'autenticazione a più fattori (MFA), l'autenticazione senza password o altre interazioni di autenticazione configurate dall'amministratore IT o dall'utente.

L'applicazione riceverà un token ID dopo che l'utente ha eseguito i passaggi di autenticazione necessari. Quando l'app riceve il token, è possibile assicurarsi che Microsoft Identity Platform abbia autenticato l'utente. Se l'app non riceve un token ID, Microsoft Identity Platform non autentica l'utente. Non consentire agli utenti non autenticati di continuare in aree protette dell'app.

È consigliabile che le applicazioni creino una sessione per un utente dopo che riceve un token ID da Microsoft Entra ID. Nel token ID ricevuto da un'app, un'attestazione di scadenza (exp) con un timestamp Unix. Questo timestamp specifica il valore on o after expiration time per il quale l'app non deve accettare il token JWT per l'elaborazione. Usare questo tempo di scadenza del token per determinare la durata delle sessioni utente. L'attestazione exp svolge un ruolo fondamentale nel mantenere un utente verificato in modo esplicito davanti all'app con il privilegio giusto e per la quantità di tempo giusta.

Supporto per l'accesso Single Sign-On

L'autenticazione Single Sign-On (SSO) consente agli utenti di accedere con un set di credenziali a più sistemi software indipendenti. SSO consente agli sviluppatori di applicazioni di non richiedere a un utente di accedere a ogni applicazione separatamente e ripetutamente. Al centro dell'accesso Single Sign-On, gli sviluppatori assicurano che tutte le applicazioni nel dispositivo dell'utente condividono la superficie Web che autentica l'utente. Artefatti sulla superficie Web (ad esempio lo stato della sessione e i cookie) dopo l'autenticazione riuscita dell'accesso SSO.

Come illustrato nel diagramma seguente, il caso d'uso più semplice di una superficie Web condivisa è un'app in esecuzione in un Web browser (ad esempio Microsoft Edge, Google Chrome, Firefox, Safari). Le schede del browser condividono lo stato SSO.

Titolo diagramma: Web browser - caso più semplice. La visualizzazione nella parte superiore centrale del diagramma è una forma cloud contenente un'icona microsoft Entra ID. Sotto la forma della nuvola è presente una scatola. Connessione forma della nuvola e la casella è una linea con una freccia su ogni estremità. L'etichetta della casella è "Mantieni l'accesso, salva i cookie di stato SSO tra le chiamate". All'interno della casella, sul lato sinistro, è un'icona simile a un cookie. Sotto il cookie, il didascalia è "Conversazione privata con l'utente". Sotto il didascalia è presente un'icona che rappresenta l'utente. A sinistra di questi tre componenti, all'interno della scatola, è un'altra scatola. L'etichetta interna della casella è "Tabulazioni". Sotto l'etichetta sono presenti quattro caselle quadrate che rappresentano le finestre del browser nelle schede.

Microsoft Identity Platform gestisce lo stato SSO in qualsiasi browser specifico, a meno che l'utente non abbia browser diversi aperti nello stesso dispositivo. In Windows 10 e versioni successive, Microsoft Identity Platform supporta in modo nativo l'accesso SSO del browser Microsoft Edge. Quando l'utente ha eseguito l'accesso a Windows, le sistemazioni in Google Chrome (tramite l'estensione account di Windows 10) e in Mozilla Firefox v91+ (tramite un'impostazione del browser) consentono a ogni browser di condividere lo stato SSO di Windows stesso.

Come illustrato nel diagramma seguente, il caso d'uso dell'applicazione nativa è più complesso.

Titolo diagramma: applicazioni native - browser incorporati - nessun accesso SSO. La visualizzazione nella parte superiore centrale del diagramma è una forma cloud contenente un'icona microsoft Entra ID. Nella parte inferiore del diagramma sono presenti quattro caselle distribuite orizzontalmente. Nell'angolo inferiore destro di ogni casella è presente un'icona che rappresenta un utente. All'interno di ognuna delle caselle è presente una rappresentazione delle finestre del browser, tra cui un'icona a forma di cookie e un'icona a forma di globo. Connessione ognuna delle quattro caselle alla forma cloud è una linea con una freccia su ogni estremità.

Approccio del broker di autenticazione

Un modello comune è che ogni app nativa abbia un webView incorporato che impedisce la partecipazione all'accesso SSO. Per risolvere questo scenario, Microsoft Entra ID usa un approccio del broker di autenticazione (broker di autenticazione) per le applicazioni native, come illustrato nel diagramma seguente.

Titolo diagramma: approccio del broker di autenticazione. La visualizzazione nella parte superiore centrale del diagramma è una forma cloud contenente un'icona microsoft Entra ID. Sotto la forma cloud è presente una forma rettangolo con l'etichetta Auth Broker. La forma rettangolo contiene un'icona a forma di cookie e un'icona a forma di globo. Connessione forma cloud e la forma rettangolo è una linea con una freccia su ogni estremità. Nella parte inferiore del diagramma sono presenti quattro caselle distribuite orizzontalmente. Nell'angolo inferiore destro di ogni casella è presente un'icona che rappresenta un utente. Le icone in ogni casella rappresentano le finestre del browser. Connessione ognuna delle quattro caselle alla forma rettangolo è una linea con una freccia su ogni estremità.

Con un broker di autenticazione sul posto, le applicazioni inviano richieste di autenticazione al broker anziché direttamente a Microsoft Identity Platform. In questo modo, il broker diventa la superficie condivisa per tutte le autenticazioni nel dispositivo.

Oltre a fornire una superficie condivisa, il broker di autenticazione offre altri vantaggi. Quando si adotta Zero Trust, le aziende potrebbero voler eseguire applicazioni solo da dispositivi gestiti aziendali. Esempi di gestione dei dispositivi aziendali includono la gestione completa di Gestione dispositivi dispositivi mobili (MDM) e scenari in cui gli utenti portano i propri dispositivi che partecipano a Gestione applicazioni mobili (MAM).

Per impostazione predefinita, i sistemi operativi sottostanti isolano i browser. Gli sviluppatori hanno bisogno di una connessione più stretta con il sistema operativo per avere accesso completo ai dettagli del dispositivo. In Windows, il broker di autenticazione è Gestione account Web Windows (WAM). In altri dispositivi, il broker di autenticazione è l'app Microsoft Authenticator (per i dispositivi che eseguono iOS o Android) o l'app Portale aziendale (per i dispositivi che eseguono Android). Le applicazioni accedono al broker di autenticazione con MSAL. In Windows un'app può accedere a WAM senza MSAL. TUTTAVIA, MSAL è il modo più semplice per consentire alle app di accedere al broker di autenticazione (in particolare le app che non sono piattaforma UWP (Universal Windows Platform) app).

I broker di autenticazione funzionano in combinazione con Microsoft Entra ID per usare i token di aggiornamento primario (PRT) che riducono la necessità di autenticare più volte gli utenti. Le richieste pull possono determinare se l'utente si trova in un dispositivo gestito. Microsoft Entra ID richiede broker di autenticazione perché introduce token di prova di possesso, un'opzione più sicura sui token di connessione che sono oggi prevalenti.

Passaggi successivi

• Risolvere i problemi relativi ai token di accesso di Microsoft Entra: convalidare un token di accesso descrive come, quando si dispone di un token di accesso Microsoft Entra, verificare che determinati campi corrispondano al record.
• Aumentare la resilienza delle applicazioni di autenticazione e autorizzazione sviluppate da app serie che usano Microsoft Identity Platform e Microsoft Entra ID. Includono indicazioni per le applicazioni client e di servizio che funzionano per conto di un utente connesso e di applicazioni daemon che funzionano per proprio conto. Contengono procedure consigliate per l'uso di token e chiamate alle risorse.
• Personalizzare i token descrive le informazioni che è possibile ricevere nei token di Microsoft Entra e come personalizzare i token.
• Configurare le attestazioni di gruppo e i ruoli dell'app nei token illustra come configurare le app con definizioni di ruolo dell'app e assegnare gruppi di sicurezza ai ruoli dell'app.
• Creare app che proteggono l'identità tramite autorizzazioni e consenso offre una panoramica delle autorizzazioni e delle procedure consigliate per l'accesso.