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ą
subjectToken
tokenu 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
iappToken
.Weryfikacja właściwości tokenu entra: zarówno
subjectToken
, jak iappToken
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ż, czytid
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 zakresemFabricWorkloadControl
, że w tokenie nieidtyp
ma oświadczenia i że ma to samo coappid
wappToken
obiekcie .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 appToken
usł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.