Aanvragen voor Azure Batch verifiëren

Elke aanvraag die wordt gedaan op basis van de Batch-service, moet worden geverifieerd. De Batch-service ondersteunt verificatie via gedeelde sleutel of Microsoft Entra ID.

Verificatie via gedeelde sleutel

Voor een geverifieerde aanvraag zijn twee headers vereist: de datum - of ocp-date-header en de autorisatieheader . In de volgende secties wordt beschreven hoe u deze headers maakt.

De datumkoptekst opgeven

Alle geverifieerde aanvragen moeten de UTC-tijdstempel (Coordinated Universal Time) voor de aanvraag bevatten. U kunt de tijdstempel opgeven in de ocp-date-header of in de standaard HTTP/ HTTPS-datumheader . Als beide headers zijn opgegeven voor de aanvraag, wordt de waarde van ocp-date gebruikt als de aanmaaktijd van de aanvraag.

De Batch-service moet een aanvraag ontvangen binnen 15 minuten nadat deze is gemaakt. Door dit te doen, wordt de service beschermd tegen beveiligingsaanvallen, zoals replay-aanvallen. De ocp-date-header wordt opgegeven omdat sommige HTTP-clientbibliotheken en -proxy's automatisch de datumheader instellen en u niet de mogelijkheid bieden om de waarde ervan te lezen om deze op te nemen in de geverifieerde aanvraag. Als u ocp-date instelt, maakt u de handtekening met een lege waarde voor de datumkoptekst .

De autorisatieheader opgeven

Een geverifieerde aanvraag moet de autorisatieheader bevatten. Als u een aanvraag wilt verifiëren, moet u de aanvraag ondertekenen met de sleutel voor het account dat de aanvraag doet en die handtekening doorgeven als onderdeel van de aanvraag.

De indeling voor de autorisatieheader is als volgt:

Authorization="SharedKey <AccountName>:<Signature>"  

SharedKey is de naam van het autorisatieschema, AccountName is de naam van het account dat de resource aanvraagt en Signature is een HMAC (Hash-based Message Authentication Code) die is samengesteld op basis van de aanvraag, wordt berekend met behulp van het SHA256-algoritme en vervolgens wordt gecodeerd met behulp van Base64-codering.

In de volgende secties wordt beschreven hoe u de autorisatieheader maakt.

De handtekeningtekenreeks maken

Houd bij het samenstellen van de handtekeningtekenreeks rekening met het volgende:

• Het VERB-gedeelte van de tekenreeks is het HTTP-werkwoord, zoals GET of POST, en moet hoofdletters zijn.

• Elke koptekst die is opgenomen in de handtekeningtekenreeks, wordt mogelijk slechts één keer weergegeven.

• De waarden van alle standaard HTTP-headers moeten in de tekenreeks worden opgenomen in de volgorde die wordt weergegeven in de handtekeningindeling, zonder de headernamen. Deze headers kunnen leeg zijn als ze niet worden opgegeven als onderdeel van de aanvraag; in dat geval is alleen het nieuwe regelteken vereist.

• Wanneer het werkwoord POST is, zijn de waarden Content-Type en Content-Length vereist als aanvraagheaders en als waarden in de handtekeningtekenreeks. Content-Type moet worden ingesteld op application/json; odata=minimalmetadata.

• Als de koptekst ocp-date is opgegeven, is de datumkoptekst niet vereist. Geef gewoon een lege regel op voor het gedeelte Datum van de handtekeningtekenreeks. Volg in dit geval de instructies in de sectie De canonicalized headers-tekenreeks maken voor het toevoegen van de ocp-date-header .

• Alle nieuwe regeltekens (\n) die worden weergegeven, zijn vereist in de handtekeningtekenreeks.

• Zie de CanonicalizedHeaders desbetreffende secties verderop in dit onderwerp voor gedetailleerde informatie over het samenstellen van tekenreeksen en CanonicalizedResource die deel uitmaken van de handtekeningtekenreeks.

Als u de handtekeningtekenreeks voor een aanvraag voor de Batch-service wilt coderen, gebruikt u de volgende indeling:

  
StringToSign = VERB + "\n" +  
  Content-Encoding + "\n"  
  Content-Language + "\n"  
  Content-Length + "\n"  
  Content-MD5 + "\n"  
  Content-Type + "\n" +  
  Date + "\n" +  
  If-Modified-Since + "\n"  
  If-Match + "\n"  
  If-None-Match + "\n"  
  If-Unmodified-Since + "\n"  
  Range + "\n"  
  CanonicalizedHeaders +   
  CanonicalizedResource;  

In het volgende voorbeeld ziet u een handtekeningtekenreeks voor een aanvraag om de taken in een account weer te geven met een time-out van 20 seconden. Als er geen headerwaarde bestaat, wordt alleen het nieuwe regelteken opgegeven.

GET\n\n\n\n\n\n\n\n\n\n\n\nocp-date:Tue, 29 Jul 2014 21:49:13 GMT\n /myaccount/jobs\napi-version:2014-01-01.1.0\ntimeout:20  

Als u dit per regel opsplitst, ziet u elk gedeelte van dezelfde tekenreeks:

  
GET\n /*HTTP Verb*/  
\n    /*Content-Encoding*/  
\n    /*Content-Language*/  
\n    /*Content-Length*/  
\n    /*Content-MD5*/  
\n    /*Content-Type*/  
\n    /*Date*/  
\n    /*If-Modified-Since */  
\n    /*If-Match */  
\n    /*If-None-Match */  
\n    /*If-Unmodified-Since*/  
\n    /* Range */  
ocp-date:Tue, 29 Jul 2014 21:49:13 GMT\n    /*CanonicalizedHeaders*/  
/myaccount/jobs\napi-version:2014-04-01.1.0\ntimeout:20    /*CanonicalizedResource*/  

Vervolgens codeert u deze tekenreeks met behulp van het algoritme HMAC-SHA256 via de UTF-8-gecodeerde handtekeningtekenreeks, maakt u de autorisatieheader en voegt u de header toe aan de aanvraag. In het volgende voorbeeld ziet u de autorisatieheader voor dezelfde bewerking:

Authorization: SharedKey myaccount:ctzMq410TV3wS7upTBcunJTDLEJwMAZuFPfr0mrrA08=  

De canonieke tekenreeks voor kopteksten maken

Voer de volgende stappen uit om het CanonicalizedHeaders gedeelte van de handtekeningtekenreeks samen te stellen:

1. Haal alle headers voor de resource op die beginnen met ocp-, inclusief de ocp-date-header .

2. Converteer elke HTTP-headernaam naar kleine letters.

3. Sorteer de kopteksten lexicografisch op kopnaam, in oplopende volgorde. Elke koptekst kan slechts eenmaal in de tekenreeks worden weergegeven.

4. Vervang eventuele spaties die breken door één spatie.

5. Eventuele spaties rond de dubbele punt in de koptekst knippen.

6. Voeg een nieuw regelteken toe aan elke canonieke koptekst in de resulterende lijst. Maak de CanonicalizedHeaders tekenreeks door alle kopteksten in deze lijst samen te voegen tot één tekenreeks.

De canonieke resourcetekenreeks maken

Het CanonicalizedResource deel van de handtekeningtekenreeks vertegenwoordigt de resource van de Batch-service waarop de aanvraag is gericht. Elk deel van de CanonicalizedResource tekenreeks dat is afgeleid van de URI van de resource, moet precies zo worden gecodeerd als in de URI.

Houd rekening met de volgende regels voor het samenstellen van de canonicaliseerde resourcetekenreeks:

• Vermijd het gebruik van het nieuwe regelteken (\n) in waarden voor queryparameters. Als deze moet worden gebruikt, moet u ervoor zorgen dat dit geen invloed heeft op de indeling van de canonicaliseerde resourcetekenreeks.

• Vermijd het gebruik van komma's in queryparameterwaarden.

U kunt de CanonicalizedResource tekenreeks als volgt samenstellen:

1. Beginnend met een slash ("/"), gevolgd door de naam van het account dat eigenaar is van de resource die wordt geopend.

2. Voeg het gecodeerde URI-pad van de resource toe, zonder queryparameters.

3. Haal alle queryparameters op de resource-URI op, inclusief de parameter api-version .

4. Converteer alle parameternamen naar kleine letters.

5. Sorteer de queryparameters lexicografisch op parameternaam, in oplopende volgorde.

6. URL-decodeer elke queryparameternaam en -waarde.

7. Voeg de naam en waarde van elke queryparameter toe aan de tekenreeks in de volgende indeling, waarbij u de dubbele punt (:) tussen de naam en de waarde opneemt:

   parameter-name:parameter-value  
   

8. Als een queryparameter meer dan één waarde heeft, sorteert u alle waarden lexicografisch en neemt u deze op in een door komma's gescheiden lijst:

   parameter-name:parameter-value-1,parameter-value-2,parameter-value-n  
   

9. Voeg een nieuw regelteken (\n) toe na elk naam-waardepaar.

De handtekening coderen

Als u de handtekening wilt coderen, roept u het algoritme HMAC-SHA256 op de UTF-8-gecodeerde handtekeningtekenreeks aan en codeert u het resultaat als Base64. Gebruik de volgende indeling (weergegeven als pseudocode):

Signature=Base64(HMAC-SHA256(UTF8(StringToSign)))  

Verificatie via Microsoft Entra ID

Azure Batch ondersteunt verificatie met Microsoft Entra ID, de directory- en identiteitsbeheerservice van Microsoft in de cloud met meerdere tenants. Azure gebruikt Microsoft Entra ID om eigen klanten, servicebeheerders en organisatiegebruikers te verifiëren.

Notitie

Verificatie met Microsoft Entra ID is optioneel, maar wordt aanbevolen. Dit is alleen vereist als uw Batch-account is ingesteld om pools toe te wijzen in een gebruikersabonnement. De pooltoewijzingsoptie is beschikbaar wanneer u een nieuw Batch-account maakt. Als uw account is ingesteld om pools toe te wijzen in een abonnement dat wordt beheerd door Batch, is het gebruik van Microsoft Entra ID voor verificatie optioneel. Zie Batch – VNet and Custom Image Support for Virtual Machine Pools (Ondersteuning voor aangepaste installatiekopieën voor virtuele-machinepools) voor meer informatie.

Zie Naslaginformatie over Azure REST API voor algemene informatie over het verifiëren van een aanvraag met Azure AD. Als u Azure AD wilt gebruiken met de Batch-service, hebt u de volgende eindpunten nodig.

Het Azure AD eindpunt 'algemeen' eindpunt is:

https://login.microsoftonline.com/common

Het resource-eindpunt voor de Batch-service is:

https://batch.core.windows.net/

Zie Azure Batch-services verifiëren met Microsoft Entra ID voor meer informatie over het registreren van uw Batch-toepassing bij Microsoft Entra ID.