Share via

Overzicht van back-endverificatie en autorisatie (preview)

  • Artikel

Het voorbeeld van een infrastructuurontwikkelaarsworkload bevat de volgende verificatiestromen aan de back-endzijde.

Verificatie en autorisatie van aanvragen van Fabric naar de workload

Structuur van autorisatieheader

De autorisatieheader maakt gebruik van een specifieke tokenindeling:

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

Deze indeling bevat twee afzonderlijke tokens:

  • subjectToken: Dit is een gedelegeerd token dat de gebruiker vertegenwoordigt namens wie de bewerking wordt uitgevoerd.
  • appToken: Dit is een token dat specifiek is voor de Fabric-toepassing.

De logica achter het gebruik van een header met twee tokens is drievoudig:

  • Validatie: De workload kan controleren of de aanvraag afkomstig is van Fabric door het appTokente valideren.

  • Gebruikerscontext: De subjectToken context van de gebruiker biedt een gebruikerscontext voor de actie die wordt uitgevoerd.

  • Communicatie tussen services: de workload kan een OBO-token (On-Behalf-Of) verkrijgen met behulp van het subjectToken, zodat het andere services kan aanroepen met een gebruikerstoken.

Verificatie

De belangrijkste verificatiecontroles die worden uitgevoerd voor het SubjectAndAppToken zijn:

  • Validatie en parsering van de waarde van de autorisatieheader: dit gebeurt in de methode FetchSubjectAndAppTokenTokenFromHeader . Het token moet beginnen met het voorvoegsel SubjectAndAppToken1.0 en moet twee tokens bevatten , subjectToken en appToken.

  • Validatie van entra-tokeneigenschappen: Beide subjectToken en appToken worden gevalideerd voor algemene Eigenschappen van Microsoft Entra-token in de methode ValidateAadTokenCommon . Deze eigenschappen omvatten tokenhandtekening, levensduur van tokens, tokendoelgroep (workload-app-doelgroep) en tokenversie (1.0) en verlener.

  • validatie van appToken-eigenschappen: de appToken claim mag geen claim hebben scp , maar moet een idtyp claim met de app hebben als waarde. We controleren ook de tid claim in de tenant-id van de workloaduitgever.

    Voorbeeld van appTokenclaims:

    {
"aud": "api://localdevinstance/12345678-77f3-4fcc-bdaa-487b920cb7ee/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": "00000009-0000-0000-c000-000000000000",
"appidacr": "2",
"idp": "https://sts.windows.net/12345678-77f3-4fcc-bdaa-487b920cb7ee/",
"idtyp": "app",
"oid": "87654321-727a-403d-b7d4-8e4a48865158",
"rh": "0.ACgAGX-u-vN3zE-9qkh7kgy37hQbaU7-v2xFr59O_foS7VLZAAA.",
"sub": "87654321-727a-403d-b7d4-8e4a48865158",
"tid": "12345678-77f3-4fcc-bdaa-487b920cb7ee",
"uti": "5bgMXs3uMUSAHCruRjACAA",
"ver": "1.0"
}

  • validatie van subjectToken-eigenschappen: Zorg ervoor dat het subjectToken een scp claim bevat met het FabricWorkloadControl bereik, dat er geen idtyp claim aanwezig is in het token en dat het hetzelfde appid heeft als in het appToken.

    Voorbeeld van subjectTokenclaims:

    {
"aud": "api://localdevinstance/12345678-77f3-4fcc-bdaa-487b920cb7ee/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": "00000009-0000-0000-c000-000000000000",
"appidacr": "2",
"ipaddr": "46.117.19.50",
"name": "john doe",
"oid": "abacabac-f91e-41db-b997-699f17146275",
"rh": "0.ASgAGX-u-vN3zE-9qkh7kgy37hQbaU7-v2xFr59O_foS7VLZANQ.",
"scp": "FabricWorkloadControl",
"sub": "X0Wl85UA-uOmdkQz5MoT-hEgYZXDq9FYdS8g2bFUaZA",
"tid": "12345678-77f3-4fcc-bdaa-487b920cb7ee",
"unique_name": "user1@constso.com",
"upn": "user1@constso.com",
"uti": "_llZwmJoSUiHv-kw6tfDAA",
"ver": "1.0"
}

Zie IAuthenticationService.

Notitie

Alle validaties in onze voorbeeldcode zijn voor versie 1.0-tokens.

Autorisatie

Zodra is bevestigd dat de aanvraag afkomstig is van de Fabric-service (via de appToken), wordt begrepen dat Fabric al heeft geverifieerd dat de gebruiker over de benodigde machtigingen beschikt om de actie uit te voeren, op basis van de metagegevens van de machtigingen van Fabric.

Verificatie en autorisatie van aanvragen van werkbelasting naar Fabric

Aanvragen voor workloadbeheer

Workloadbeheer-API's zijn speciale Fabric-API's die workloads ondersteunen met het levenscyclusbeheer van fabric-items. Deze API's maken gebruik van dezelfde indeling van de subjectAndAppToken1.0-autorisatieheader.

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

Wanneer u afkomstig bent van de workload, zijn de opgenomen tokens:

  • subjectToken: Dit is een door de gebruiker gedelegeerd token (verkregen via de OBO-stroom) die de gebruiker vertegenwoordigt namens wie de bewerking wordt uitgevoerd. Fabric controleert of de gebruiker over de vereiste machtigingen beschikt om de benodigde actie uit te voeren.

  • appToken: Dit is een token dat specifiek is voor de workloadtoepassing. Infrastructuur controleert of dit token afkomstig is van de Entra-app van de workload waartoe het relevante Fabric-item behoort en dat zich in de tenant van de uitgever van de workload bevindt.

Zie de ValidatePermissions methode in AuthorizationHandler.

Openbare API's

Voor het aanroepen van openbare Fabric-API's moet de workload een standaard Microsoft Entra OBO-token met de relevante API-bereiken verkrijgen en deze doorgeven als een bearer-token in de autorisatieheader van de aanvraag.

Zie FabricExtensionController.

Verificatie en autorisatie van aanvragen van workload FE naar workload BE

Autorisatieheader

De autorisatieheader in een aanvraag die is verzonden van de workload FE naar de workload BE maakt gebruik van een standaard bearer-token.

Verificatie

De methode ValidateDelegatedAADToken in de workload BE is verantwoordelijk voor het valideren van het token. De primaire controles die worden uitgevoerd, zijn:

  • Levensduur van token: zorgt ervoor dat het token binnen de geldige gebruiksperiode valt.

  • Handtekening: Verifieert de echtheid van het token.

  • Doelgroep: Controleert of de doelgroep van het token overeenkomt met de Entra-workload-app.

  • Uitgever: valideert de uitgever van het token.

  • Toegestane bereiken: valideert de bereiken waartoe het token toegang heeft.

Autorisatie

Autorisatie wordt bereikt door de methode ValidatePermissions aan te roepen. Met deze methode wordt de resolvePermissions API aangeroepen in het eindpunt voor workloadbeheer van fabric voor het relevante Fabric-item en wordt gecontroleerd of de gebruiker over de benodigde machtigingen voor de bewerking beschikt.