Udostępnij za pośrednictwem


Omówienie uwierzytelniania i autoryzacji zaplecza

Przykład obciążenia dla deweloperów sieci szkieletowej zawiera następujące przepływy uwierzytelniania po stronie zaplecza.

Uwierzytelnianie i autoryzacja żądań z sieci szkieletowej do obciążenia

Struktura nagłówka autoryzacji

Nagłówek autoryzacji używa określonego formatu tokenu:

SubjectAndAppToken1.0 subjectToken="delegated token", appToken="S2S token"

Ten format zawiera dwa odrębne tokeny:

  • subjectToken: token delegowany reprezentujący użytkownika, którego imieniu jest wykonywana operacja.
  • appToken: token specyficzny dla aplikacji sieci szkieletowej.

Uzasadnienie użycia nagłówka podwójnego tokenu jest trzykrotne:

  • Walidacja: obciążenie może sprawdzić, czy żądanie pochodzi z sieci szkieletowej, weryfikując element appToken.

  • Kontekst użytkownika: element subjectToken udostępnia kontekst użytkownika dla wykonywanej akcji.

  • Komunikacja między usługami: obciążenie może uzyskać token On-Behalf-Of (OBO) przy użyciu elementu , co umożliwia wywołanie innych usług za pomocą subjectTokentokenu użytkownika.

Uwierzytelnianie

Główne testy uwierzytelniania wykonywane dla obiektu SubjectAndAppToken to:

  • Walidacja i analizowanie wartości nagłówka autoryzacji odbywa się w metodzie AuthenticateControlPlaneCall . Token musi zaczynać się od prefiksu "SubjectAndAppToken1.0" i zawierać dwa tokeny — subjectToken i appToken.

  • Weryfikacja właściwości tokenu entra: zarówno subjectToken , jak i appToken są weryfikowane pod kątem typowych właściwości tokenu Entra firmy Microsoft w metodzie ValidateAadTokenCommon . Te właściwości obejmują podpis tokenu, okres istnienia tokenu, odbiorców tokenu (odbiorców aplikacji obciążenia) i wersję tokenu (1.0) i wystawcę.

  • weryfikacja właściwości appToken: nie appToken powinien mieć scp oświadczenia, ale powinien mieć idtyp oświadczenie z aplikacją jako wartość. Sprawdzamy również, czy tid oświadczenie ma identyfikator dzierżawy wydawcy obciążenia.

    Przykładowe oświadczenia appToken:

    {
    "aud": "api://localdevinstance/00001111-aaaa-2222-bbbb-3333cccc4444/Fabric.WorkloadSample/123",
    "iss": "https://sts.windows.net/12345678-77f3-4fcc-bdaa-487b920cb7ee/",
    "iat": 1700047232,
    "nbf": 1700047232,
    "exp": 1700133932,
    "aio": "E2VgYLjBuv2l+c6cmm/iP/bnL2v+AQA=",
    "appid": "11112222-bbbb-3333-cccc-4444dddd5555"
    "appidacr": "2",
    "idp": "https://sts.windows.net/12345678-77f3-4fcc-bdaa-487b920cb7ee/",
    "idtyp": "app",
    "oid": "aaaaaaaa-0000-1111-2222-bbbbbbbbbbbb",
    "rh": "0.ACgAGX-u-vN3zE-9qkh7kgy37hQbaU7-v2xFr59O_foS7VLZAAA.",
    "sub": "aaaaaaaa-0000-1111-2222-bbbbbbbbbbbb",
    "tid": "bbbbcccc-1111-dddd-2222-eeee3333ffff",
    "uti": "5bgMXs3uMUSAHCruRjACAA",
    "ver": "1.0"
    }
    
  • weryfikacja właściwości subjectToken: upewnij się, że subjectToken zawiera scp oświadczenie z zakresem FabricWorkloadControl , że w tokenie nie idtyp ma oświadczenia i że ma to samo co appid w appTokenobiekcie .

    Przykładowe oświadczenia subjectToken:

    {
    "aud": "api://localdevinstance/00001111-aaaa-2222-bbbb-3333cccc4444/Fabric.WorkloadSample/123",
    "iss": "https://sts.windows.net/12345678-77f3-4fcc-bdaa-487b920cb7ee/",
    "iat": 1700050446,
    "nbf": 1700050446,
    "exp": 1700054558,
    "acr": "1",
    "aio": "ATQAy/8VAAAAUgWRMRnBo4VGHvrKRykUXOXBNKS1cHnBxLrYkZJJGSjAVyJGBecbLdSud1GUakER",
    "amr": [
        "pwd"
    ],
    "appid": "11112222-bbbb-3333-cccc-4444dddd5555"
    "appidacr": "2",
    "ipaddr": "46.117.19.50",
    "name": "john doe",
    "oid": "bbbbbbbb-1111-2222-3333-cccccccccccc",
    "rh": "0.ASgAGX-u-vN3zE-9qkh7kgy37hQbaU7-v2xFr59O_foS7VLZANQ.",
    "scp": "FabricWorkloadControl",
    "sub": "X0Wl85UA-uOmdkQz5MoT-hEgYZXDq9FYdS8g2bFUaZA",
    "tid": "bbbbcccc-1111-dddd-2222-eeee3333ffff",
    "unique_name": "user1@constso.com",
    "upn": "user1@constso.com",
    "uti": "_llZwmJoSUiHv-kw6tfDAA",
    "ver": "1.0"
    }
    

Zobacz IAuthenticationService.

Uwaga

Wszystkie weryfikacje w naszym przykładowym kodzie dotyczą tokenów w wersji 1.0.

Autoryzacja

Po potwierdzeniu, że żądanie pochodzi z usługi Fabric (za pośrednictwem appTokenusługi ), sieć szkieletowa zweryfikowała, że użytkownik ma uprawnienia niezbędne do wykonania akcji na podstawie metadanych uprawnień sieci szkieletowej.

Uwierzytelnianie i autoryzacja żądań z obciążenia do sieci szkieletowej

Żądania kontroli obciążenia

Interfejsy API sterowania obciążeniami to specjalne interfejsy API sieci szkieletowej, które obsługują obciążenia przy użyciu zarządzania cyklem życia elementów sieci szkieletowej. Te interfejsy API używają tego samego formatu nagłówka autoryzacji SubjectAndAppToken1.0.

SubjectAndAppToken1.0 subjectToken="delegated token", appToken="S2S token"

Wywołania pochodzące z obciążenia obejmowały następujące tokeny:

  • subjectToken: token delegowany przez użytkownika (uzyskany za pośrednictwem przepływu OBO) reprezentujący użytkownika, którego imieniu jest wykonywana operacja. Sieć szkieletowa sprawdza, czy użytkownik ma wymagane uprawnienia do wykonania wymaganej akcji.

  • appToken: token specyficzny dla aplikacji obciążenia. Sieć szkieletowa sprawdza, czy ten token pochodzi z aplikacji Microsoft Entra obciążenia, do którego należy odpowiedni element sieci szkieletowej, i znajduje się on w dzierżawie wydawcy obciążenia.

Zobacz metodę ValidatePermissions w programie AuthorizationHandler.

Publiczne interfejsy API

Aby wywoływać publiczne interfejsy API sieci Szkieletowej, obciążenie powinno uzyskać standardowy token Microsoft Entra OBO z odpowiednimi zakresami interfejsu API i przekazać go jako token elementu nośnego w nagłówku autoryzacji żądania.

Zobacz FabricExtensionController.

Uwierzytelnianie i autoryzacja żądań z obciążenia FE do obciążenia BE

Nagłówek autoryzacji

Nagłówek autoryzacji w żądaniu wysłanym z obciążenia FE do obciążenia BE używa standardowego tokenu elementu nośnego.

Uwierzytelnianie

Metoda AuthenticateControlPlaneCall w obciążeniu BE jest odpowiedzialna za weryfikowanie tokenu. Wykonywane są podstawowe testy:

  • Okres istnienia tokenu: zapewnia, że token mieści się w prawidłowym okresie użycia.

  • Podpis: weryfikuje autentyczność tokenu.

  • Odbiorcy: sprawdza, czy odbiorcy tokenu są zgodni z obciążeniem aplikacji Microsoft Entra.

  • Wystawca: weryfikuje wystawcę tokenu.

  • Dozwolone zakresy: weryfikuje zakresy, do których token ma dostęp.

Autoryzacja jest osiągana przez wywołanie metody ValidatePermissions . Ta metoda wywołuje resolvePermissions interfejs API w punkcie końcowym kontroli obciążenia sieci szkieletowej dla odpowiedniego elementu sieci szkieletowej i sprawdza, czy użytkownik ma niezbędne uprawnienia do operacji.

Długotrwałe operacje — token odświeżania

Autoryzacja jest osiągana przez wywołanie metody ValidatePermissions . Ta metoda wywołuje resolvePermissions interfejs API w punkcie końcowym kontroli obciążenia sieci szkieletowej dla odpowiedniego elementu sieci szkieletowej i sprawdza, czy użytkownik ma niezbędne uprawnienia do operacji.

Jeśli obciążenia obejmują długotrwałe operacje, na przykład w ramach elementu JobScheduler , może wystąpić sytuacja, w której okres istnienia tokenu nie jest wystarczający. Aby uzyskać więcej informacji na temat uwierzytelniania długotrwałego procesu, długotrwałych procesów OBO.