Semion Vasilevitzky e Jonathan Elkabas

Nota dell’editore: Benvenuti al secondo “Practice Checkpoint” della guida completa “Comprendere e prevenire gli attacchi all’identità dell’agente Entra ID”. Nel corso della serie, queste brevi guide pratiche illustrano gli oggetti e i comportamenti esatti di cui abbiamo appena parlato. Se siete qui per acquisire il modello concettuale, potete tranquillamente darci un’occhiata veloce; se state effettuando delle verifiche nel vostro tenant, rappresentano il modo più veloce per seguire il percorso. Ogni "Practice Checkpoint" è autonomo e mantiene un elenco aggiornato di ID (blueprint, principal, identità dell’agente, utente dell’agente) in modo che le sezioni successive possano fare riferimento agli stessi oggetti. Per rivedere i capitoli precedenti e le lezioni pratiche, inizia da qui.


Nel nostro primo" Practice Checkpoint" hai imparato come generare l'ID agente e creare il tuo primo utente agente.

Ora che gli oggetti principali sono stati creati, configureremo il modello di autorizzazioni proprio come avviene nelle implementazioni reali: autorizzazioni dirette, limitate all’app, sull’identità dell’agente e autorizzazioni delegate concesse a livello di blueprint e contrassegnate come ereditabili.

Questo checkpoint definisce gli input esatti che verificheremo in seguito nei token durante i flussi di autenticazione.

Assegnare l'autorizzazione all'identità dell'agente

Per illustrare le autorizzazioni “dirette” riservate alle app a livello di identità dell’agente, assegnare un ruolo di app a <agent-identity-id> utilizzando lo stesso appRoleAssignments secondo lo schema di prima.

In questa demo, il appRoleId rappresenta User.Read.All. Lo useremo in seguito per l'autenticazione con l'identità dell'agente e per elencare gli utenti.

Figura 1. Assegnazione di un ruolo di app all'identità dell'agente

Configurare le autorizzazioni ereditabili

Configurare le autorizzazioni ereditabili in modo che l'agente possa ereditare gli ambiti delegati nei flussi delegati.


Fase 1: Concedere l'autorizzazione delegata

Crea un oauth2PermissionGrants registro delle concessioni Group.Read.All al modello di identità dell'agente (flusso standard di consenso delegato).

Figura 2. Assegnazione del diritto “Group.Read.All” all’identità dell’agente

Fase 2: Contrassegnarlo come ereditabile

Chiama il /applications/microsoft.graph.agentIdentityBlueprint /<agent identity blueprint id>/inheritablePermissions endpoint e includere l'ID dell'app della risorsa di Graph. Utilizzare un ambito enumerato in modo che l'identità dell'agente erediti solo il Group.Read.All autorizzazioni.

Figura 3. Limitazione dei permessi di lettura ereditati dall’identità dell’agente con un ambito enumerato

In uno scenario di autenticazione delegata, vedremo e utilizzeremo tali autorizzazioni per elencare i gruppi di tenant. Se si desidera che tutte le autorizzazioni vengano ereditate, è sufficiente impostare tipo a allAllowed anziché enumerated e rimuovere la proprietà "scopes".

Sebbene non sia documentato, è possibile ereditare le autorizzazioni enumerate specifiche dell’app. Anziché gli ambiti, useremo appRoleIds, che richiedono il GUID del ruolo dell'app. La richiesta avrà quindi il seguente aspetto:

Figura 4. Abilitazione dell'ereditarietà delle autorizzazioni enumerate riservate alle app

È anche possibile impostare entrambe contemporaneamente. Per aggiornare le autorizzazioni ereditabili esistenti, inviare una richiesta Patch alla risorsa pertinente che si desidera aggiornare.

Patch: /applications/microsoft.graph.agentIdentityBlueprint/<agent-identity-blueprint>/inheritablePermissions/<resource-app-id>

Prossimo argomento: scopriremo come l'identità del tuo agente si autentica e funziona in Entra ID.


Scopri la guida