Gestire l'assegnazione delle identità dell'agente a un'applicazione (anteprima)

Questo articolo illustra come assegnare identità agente a un'applicazione aziendale in Microsoft Entra ID per gli agenti che pianificano l'interazione con un'applicazione. I passaggi di configurazione di Microsoft Entra dipendono dalle funzionalità dell'agente e dall'applicazione aziendale.

Le organizzazioni possono controllare quali dipendenti e utenti guest aziendali possono interagire con le applicazioni aziendali dell'organizzazione, configurando ogni applicazione in modo che si basi su Microsoft Entra per l'autenticazione unica o il provisioning e richiedendo che tali utenti siano assegnati all'applicazione. Se un'applicazione espone più ruoli dell'app, è anche possibile assegnare un ruolo app specifico a ogni utente. Per altre informazioni, vedere Gestire l'assegnazione di utenti e gruppi a un'applicazione.

Quando un agente di intelligenza artificiale ha uno strumento (o può essere definito nella piattaforma come competenza o connettore) per comunicare con un'applicazione aziendale nel tenant, è possibile assegnare l'identità di tale strumento all'applicazione. Lo strumento può usare un principale del servizio, un'identità dell'agente o un utente agente per l'autenticazione. Assegnando queste identità ai ruoli e alle autorizzazioni dell'applicazione aziendale, è possibile consentire alle applicazioni di supporto dell'agente di riconoscere l'identità dell'agente e consentire all'agente di ottenere i token appropriati dall'ID Microsoft Entra per l'accesso alle applicazioni.

Questo articolo illustra come selezionare tre opzioni, in base alle funzionalità dell'applicazione.

Funzionalità dell'applicazione	Sezione
L'applicazione espone le API con ambiti di autorizzazione OAuth2	concedere il consenso all'identità agente o al principale del servizio per un'area di autorizzazione per le applicazioni
L'applicazione riconosce le attestazioni di ruolo per i principal di servizio	assegnare un'identità agente o un servizio principale a un ruolo dell'applicazione
L'applicazione supporta solo SAML per gli utenti	assegnare un utente agente a un ruolo applicativo da usare con SCIM

Consenso a un ambito di autorizzazione dell'applicazione

Le applicazioni che utilizzano Microsoft Entra Identity Platform possono esporre API accessibili da altre applicazioni client. L'applicazione con l'API può esporre gli ambiti OAuth per tali chiamate API. L'entità principale del servizio dello strumento può ricevere i permessi per tali ambiti, permettendogli di chiamare le API.

Per altre informazioni sul consenso di un'identità agente o un'entità servizio, vedere Consenso amministratore per le autorizzazioni dell'applicazione.

Assegnazione di un'identità agente a un ruolo applicativo

Per le applicazioni che riconoscono le dichiarazioni di ruolo nei principali di servizio, è possibile assegnare il principale di servizio o l'identità di un agente al ruolo dell'app di un'applicazione. Quando si assegnano ruoli all'app, ciò comporta autorizzazioni dell'applicazione. Le autorizzazioni dell'applicazione vengono in genere usate da app daemon, servizi back-end o agenti autonomi, che devono autenticarsi e effettuare chiamate API autorizzate come se stesse, senza l'interazione di un utente. Per ulteriori informazioni, consultare Aggiungere ruoli dell'applicazione all'applicazione e riceverli nel token.

Annotazioni

Il provisioning in uscita di Microsoft Entra SCIM supporta solo utenti e gruppi; I principali di servizio e le identità dell'agente assegnate ai ruoli dell'app direttamente o come membri di gruppi non vengono sottoposte a provisioning nelle applicazioni.

Prima di tutto, conferma che il ruolo dell'app nel manifesto dell'applicazione abbia un allowedMemberTypes di Application, indicando che il ruolo è disponibile per altre applicazioni. Se il ruolo consente solo agli utenti, le identità degli agenti e i principali del servizio non sono supportati dall'applicazione per tale ruolo. È quindi possibile assegnare un ruolo app a un'identità agente o a un'entità servizio usando l'interfaccia di amministrazione di Microsoft Entra, Microsoft Graph o Microsoft Graph PowerShell.

• Se si utilizza il portale di amministrazione di Microsoft Entra, seguire le istruzioni su come assegnare i ruoli applicativi.

• Se si usa Microsoft Graph o Microsoft Graph PowerShell, l'assegnazione di un'identità agente o un'entità servizio a un ruolo applicazione è simile all'assegnazione di utenti e gruppi a un'applicazione. È possibile utilizzare list app role assignment per verificare se l'identità agente o il principal del servizio ha già un'assegnazione di ruolo e usare add app role assignment per creare una nuova assegnazione di ruolo dell'app. Ad esempio, per creare un'assegnazione di ruolo dell'applicazione per un'identità dell'agente usando PowerShell, impostare $PrincipalId su id dell'identità dell'agente, impostare $ResourceId sul principale del servizio dell'applicazione di destinazione e id sull'ID del ruolo dell'applicazione del ruolo dell'app di destinazione. Creare quindi un payload per l'aggiunta di un'assegnazione di ruolo dell'applicazione:

  
  $Body = @{
    principalId = $PrincipalId
    resourceId = $ResourceId
    appRoleId = $AppRoleId
  } | ConvertTo-Json
  
  Invoke-MgGraphRequest -Method POST -Uri "https://graph.microsoft.com/v1.0/servicePrincipals/$ResourceId/appRoleAssignedTo" -Body $Body
  

Assegnazione ad applicazioni basate su SAML

Se hai applicazioni che supportano solo SAML per consentire a un utente di ottenere un token e desideri che l'agente possa interagire autonomamente con la sua identità con quella applicazione, è possibile integrare l'identità dell'agente con utenti agenti. Dopo aver aggiunto il supporto per gli utenti SAML e agent all'agente, l'agente può ottenere un token per l'applicazione. A differenza delle identità degli agenti, gli utenti degli agenti possono essere anche sottoposti a provisioning in tali applicazioni tramite SCIM, se richiesto dall'applicazione.

Annotazioni

Verificare con lo sviluppatore dell'applicazione se l'applicazione supporta il modello di interazione dell'agente.

Per consentire a un agente di interagire con un'applicazione che accetta asserzioni SAML, è necessaria una registrazione aggiuntiva dell'applicazione per partecipare al flusso affinché l'ID di Microsoft Entra fornisca un'asserzione SAML in risposta a un flusso per conto di. Oltre all'agente stesso e all'applicazione, è necessario creare una registrazione dell'applicazione di supporto SAML per qualsiasi applicazione nel tenant basata su SAML. Se si sviluppa l'agente internamente, questo helper potrebbe far parte dell'agente.

Nel tenant di Microsoft Entra gli elementi seguenti devono esistere:

• lo schema di identità dell'agente e il principale dello schema di identità dell'agente
• Registrazione dell'applicazione helper SAML
• l'applicazione aziendale come risorsa di destinazione
• un oggetto OAuth2PermissionGrant, con
  • registrazione come client dell'applicazione assistente SAML
  • l'applicazione aziendale come risorsa
  • valore dell'ambito risultante dalla concatenazione dell'ID entità dell'applicazione aziendale con /.default aggiunto

Quindi, per ogni identità dell'agente, creare:

• un utente agente
• un'assegnazione di ruolo per l'applicazione, destinata all'utente agente, per uno dei ruoli dell'applicazione aziendale
• un OAuth2PermissionGrant, per l'identità dell'agente, con
  • l'identità dell'agente in qualità di cliente
  • registrazione dell'applicazione di supporto SAML come risorsa
  • valore del campo di applicazione della concatenazione di api://', l'ID dell'applicazione helper SAML e /.default

Se l'agente ha più identità, l'ereditarietà delle autorizzazioni può essere utilizzata per concedere il consenso una volta al modello di identità dell'agente e poi ereditarlo per le identità dell'agente.

Dopo che queste applicazioni, utenti, assegnazioni di ruolo e concessioni sono presenti nel tenant, un agente che necessita di un'asserzione SAML per l'autenticazione all'applicazione aziendale può:

• Ottieni un token come modello di identità dell'agente.

• Usare tale token per effettuare una richiesta di token all'endpoint https://login.microsoftonline.com/<tenantid>/oauth2/v2.0/token e ottenere un token FIC (Federated Identity Credential) come identità dell'agente.

  In tale richiesta, client_id è l'ID identità dell'agente, scope è api://AzureADTokenExchange/.default, grant_type è client_credentials, client_assertion_type è urn:ietf:params:oauth:client-assertion-type:jwt-bearer, e client_assertion è il token del progetto di identità dell'agente dal passaggio 1.

• Usare questi due token per richiedere un token come utente agente con l'ambito dell'applicazione di supporto.

  In questa richiesta, client_id è l'ID identità agente, scope è la concatenazione di api://', l'ID applicazione dell'helper SAML, e /.default; grant_type è user_fic; client_assertion_type è urn:ietf:params:oauth:client-assertion-type:jwt-bearer; client_assertion è il token blueprint dell'identità dell'agente; user_id è l'ID oggetto utente agente; e user_federated_identity_credential è il token di identità dell'agente.

• Effettuare la richiesta di un token on-behalf-of-call presso https://login.microsoftonline.com/<tenantid>/oauth2/v2.0/token per ottenere un token SAML.

  In questa richiesta, fornire le credenziali della registrazione dell'applicazione helper SAML, il token restituito da user_fic come l'asserzione, il tipo di concessione urn:ietf:params:oauth:grant-type:jwt-bearer, lo scope dell'ID dell'applicazione aziendale con /.default accodato, il requested_token_use di on_behalf_of e il requested_token_type di urn:ietf:params:oauth:token-type:saml2. La risposta contiene un'asserzione SAML codificata in Base64URL.

Contenuti correlati

• Assegnare utenti e gruppi ai ruoli dell'applicazione