Delen via

Overzicht van back-endverificatie en autorisatie

  • 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: Een gedelegeerd token dat de gebruiker vertegenwoordigt namens wie de bewerking wordt uitgevoerd.
  • appToken: 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 wordt uitgevoerd in de methode AuthenticateControlPlaneCall . 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/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"
}

  • 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/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"
}

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 appTokenFabric), controleert Fabric of 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"

Aanroepen die afkomstig zijn van de workload, bevatten de volgende tokens:

  • subjectToken: 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: Een token dat specifiek is voor de workloadtoepassing. Fabric controleert of dit token afkomstig is van de Microsoft 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

Als u openbare Fabric-API's wilt aanroepen, moet de workload een standaard Microsoft Entra OBO-token verkrijgen met de relevante API-bereiken 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 AuthenticateControlPlaneCall 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 workload van de Microsoft Entra-app.

  • Uitgever: valideert de uitgever van het token.

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

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.

Langlopende bewerkingen - Token vernieuwen

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.

Als uw workloads langdurige bewerkingen bevatten, bijvoorbeeld als onderdeel van JobScheduler, kunt u een situatie tegenkomen waarin de levensduur van het token niet voldoende is. Voor meer informatie over het verifiëren van langlopend proces, langlopende OBO-processen.