Protokół personifikacji użytkownika agenta

Personifikacja użytkownika agenta umożliwia tożsamościom agenta działanie z kontekstem użytkownika za pośrednictwem użytkowników agenta, łącząc uprawnienia użytkownika z operacją autonomiczną. W tym scenariuszu szablon tożsamości agenta (aktor 1) podszywa się pod tożsamość agenta (aktor 2), która podszywa się pod użytkownika agenta (podmiot) przy użyciu FIC. Dostęp jest uzależniony od delegacji przypisanych do tożsamości agenta. Użytkownik agentowy może być udawany tylko przez jedną tożsamość agenta.

Integracja tożsamości zarządzanych

Tożsamości zarządzane są preferowanym typem poświadczeń. W tej konfiguracji token tożsamości zarządzanej służy jako poświadczenie szablonu tożsamości agenta nadrzędnego, podczas gdy standardowe protokoły MSI mają zastosowanie do pozyskiwania poświadczeń. Ta integracja umożliwia identyfikatorowi agenta uzyskanie pełnych korzyści związanych z zabezpieczeniami i zarządzaniem MSI, w tym automatyczną rotacją poświadczeń i bezpiecznym przechowywaniem.

Kroki protokołu

Następnie poniżej przedstawiono kroki protokołu.

1. Strategia tożsamości agenta żąda tokenu wymiany (T1), który jest używany do personifikacji tożsamości agenta. Szablon tożsamości agenta przedstawia poświadczenia klienta, które mogą być sekretem, certyfikatem lub tokenem tożsamości zarządzanej używanym jako FIC.

   Ostrzeżenie

   Tajne klucze klienta nie powinny być używane jako poświadczenia klienta w środowiskach produkcyjnych dla szablonów tożsamości agenta ze względu na zagrożenia bezpieczeństwa. Zamiast tego należy użyć bezpieczniejszych metod uwierzytelniania, takich jak poświadczenia tożsamości federacyjnej (FIC) z tożsamościami zarządzanymi lub certyfikatami klienta. Te metody zapewniają zwiększone zabezpieczenia, eliminując konieczność przechowywania poufnych wpisów tajnych bezpośrednio w ramach konfiguracji aplikacji.

   POST /oauth2/v2.0/token
   Content-Type: application/x-www-form-urlencoded
   
   client_id=AgentBlueprint
   &scope=api://AzureADTokenExchange/.default
   &fmi_path=AgentIdentity
   &client_assertion_type=urn:ietf:params:oauth:client-assertion-type:jwt-bearer
   &client_assertion=TUAMI
   &grant_type=client_credentials
   

   Gdzie TUAMI to token MSI dla tożsamości zarządzanej przypisanej przez użytkownika (UAMI). Spowoduje to zwrócenie tokenu T1.

2. Tożsamość agenta żąda tokenu (T2), który jest używany do personifikacji użytkownika agenta. Tożsamość agenta przedstawia T1 jako deklarację klienta. Microsoft Entra ID zwraca T2 do tożsamości agenta po zweryfikowaniu, że T1 (aud) == Aplikacja nadrzędna tożsamości agenta == Projekt tożsamości agenta.

   POST /oauth2/v2.0/token
   Content-Type: application/x-www-form-urlencoded
   
   client_id=AgentIdentity
   &scope=api://AzureADTokenExchange/.default
   &client_assertion_type=urn:ietf:params:oauth:client-assertion-type:jwt-bearer
   &client_assertion={T1}
   &grant_type=client_credentials
   

   Spowoduje to zwrócenie tokenu T2.

3. Następnie tożsamość agenta wysyła żądanie wymiany tokenów OBO do Microsoft Entra ID, obejmujące zarówno T1, jak i T2. Microsoft Entra ID sprawdza, czy T2 (aud) jest równe tożsamości agenta.

   POST /oauth2/v2.0/token
   Content-Type: application/x-www-form-urlencoded
   
   client_id=AgentIdentity
   &scope=https://resource.example.com/scope1
   &client_assertion_type=urn:ietf:params:oauth:client-assertion-type:jwt-bearer
   &client_assertion={T1}
   &assertion={T2}
   &username=agentuser@contoso.com
   &grant_type=urn:ietf:params:oauth:grant-type:jwt-bearer
   &requested_token_use=on_behalf_of
   

4. Następnie Microsoft Entra ID wystawia token zasobu.

Diagram sekwencji

Na poniższym diagramie sekwencji przedstawiono przepływ personifikacji użytkownika agenta

Personifikacja użytkownika agenta wymaga konstruowania łańcucha poświadczeń zgodnie z planem tożsamości agenta -> tożsamość agenta -> użytkownik agenta. Każdy krok w tym łańcuchu używa tokenu z poprzedniego kroku jako poświadczenia, tworząc bezpieczną ścieżkę delegowania. Ten sam identyfikator klienta musi być używany dla obu faz, aby zapobiec atakom eskalacji uprawnień.