Delen via

Verificatie met Azure Maps

  • Artikel

Azure Maps ondersteunt drie manieren om aanvragen te verifiëren: Verificatie met gedeelde sleutels, Verificatie via Microsoft Entra-id en SAS-tokenverificatie (Shared Access Signature). In dit artikel worden verificatiemethoden uitgelegd om u te helpen bij de implementatie van Azure Maps-services. In het artikel worden ook andere accountbesturingselementen beschreven, zoals het uitschakelen van lokale verificatie voor Azure Policy en Cross-Origin Resource Sharing (CORS).

Notitie

Ter verbetering van beveiligde communicatie met Azure Maps ondersteunen we nu Tls 1.2 (Transport Layer Security) 1.2 en wordt de ondersteuning voor TLS 1.0 en 1.1 buiten gebruik gesteld. Als u momenteel TLS 1.x gebruikt, evalueert u de gereedheid van TLS 1.2 en ontwikkelt u een migratieplan met de tests die worden beschreven in Het oplossen van het TLS 1.0-probleem.

Verificatie met gedeelde sleutels

Zie Verificatiedetails weergeven voor meer informatie over het weergeven van uw sleutels in Azure Portal.

Primaire en secundaire sleutels worden gegenereerd nadat het Azure Maps-account is gemaakt. U wordt aangeraden om de primaire sleutel als abonnementssleutel te gebruiken bij het aanroepen van Azure Maps met verificatie met gedeelde sleutels. Verificatie met gedeelde sleutels geeft een sleutel die door een Azure Maps-account wordt gegenereerd door aan een Azure Maps-service. Voor elke aanvraag bij Azure Maps-services voegt u de abonnementssleutel toe als parameter aan de URL. De secundaire sleutel kan worden gebruikt in scenario's zoals wijzigingen in rollende sleutels.

Voorbeeld van het gebruik van de abonnementssleutel als een parameter in uw URL:

https://atlas.microsoft.com/map/tile?subscription-key={Your-Azure-Maps-Subscription-key}&api-version=2024-04-01&tilesetId=microsoft.base.road&zoom=15&x=5236&y=12665&tileSize=256

Belangrijk

Primaire en secundaire sleutels moeten worden behandeld als gevoelige gegevens. De gedeelde sleutel wordt gebruikt om alle Rest API van Azure Maps te verifiëren. Gebruikers die een gedeelde sleutel gebruiken, moeten de API-sleutel abstraheren, via omgevingsvariabelen of beveiligde geheime opslag, waar deze centraal kan worden beheerd.

Microsoft Entra-verificatie

Azure-abonnementen worden geleverd met een Microsoft Entra-tenant om gedetailleerd toegangsbeheer mogelijk te maken. Azure Maps biedt verificatie voor Azure Maps-services met behulp van Microsoft Entra ID. Microsoft Entra ID biedt verificatie op basis van identiteiten voor gebruikers en toepassingen die zijn geregistreerd in de Microsoft Entra-tenant.

Azure Maps accepteert OAuth 2.0-toegangstokens voor Microsoft Entra-tenants die zijn gekoppeld aan een Azure-abonnement dat een Azure Maps-account bevat. Azure Maps accepteert ook tokens voor:

  • Microsoft Entra-gebruikers
  • Partnertoepassingen die gebruikmaken van machtigingen die zijn gedelegeerd door gebruikers
  • Beheerde identiteiten voor Azure-resources

Azure Maps genereert een unieke id (client-id ) voor elk Azure Maps-account. U kunt tokens aanvragen bij Microsoft Entra ID wanneer u deze client-id combineert met andere parameters.

Zie Verificatie beheren in Azure Maps voor meer informatie over het configureren van Microsoft Entra-id en aanvraagtokens voor Azure Maps.

Zie Verificatie versus autorisatie voor algemene informatie over verificatie met Microsoft Entra-id.

Beheerde identiteiten voor Azure-resources en Azure Maps

Beheerde identiteiten voor Azure-resources bieden Azure-services met een automatisch beheerde beveiligingsprincipaal op basis van toepassingen die kunnen worden geverifieerd met Microsoft Entra-id. Met op rollen gebaseerd toegangsbeheer van Azure (Azure RBAC) kan de principal voor beveiliging van beheerde identiteiten worden geautoriseerd voor toegang tot Azure Maps-services. Enkele voorbeelden van beheerde identiteiten zijn: Azure-app Service, Azure Functions en Azure Virtual Machines. Zie Azure-services die beheerde identiteiten kunnen gebruiken voor toegang tot andere services voor een lijst met beheerde identiteiten. Zie Verificatie beheren in Azure Maps voor meer informatie over beheerde identiteiten.

Microsoft Entra-verificatie voor toepassingen configureren

Toepassingen worden geverifieerd met de Microsoft Entra-tenant met behulp van een of meer ondersteunde scenario's van Microsoft Entra ID. Elk Microsoft Entra-toepassingsscenario vertegenwoordigt verschillende vereisten op basis van bedrijfsbehoeften. Sommige toepassingen vereisen mogelijk aanmeldingservaringen van gebruikers en andere toepassingen vereisen mogelijk een aanmeldingservaring voor toepassingen. Zie Verificatiestromen en toepassingsscenario's voor meer informatie.

Nadat de toepassing een toegangstoken heeft ontvangen, verzendt de SDK en/of toepassing een HTTPS-aanvraag met de volgende set vereiste HTTP-headers, naast andere HTTP-headers van de REST API:

Koptekstnaam Weergegeven als
x-ms-client-id 30d7cc... 9f55
Autorisatie Bearer eyJ0e... HNIVN

Notitie

x-ms-client-id is de guid op basis van een Azure Maps-account die wordt weergegeven op de azure Maps-verificatiepagina.

Hier volgt een voorbeeld van een Azure Maps-routeaanvraag die gebruikmaakt van een Microsoft Entra ID OAuth Bearer-token:

GET /route/directions/json?api-version=1.0&query=52.50931,13.42936:52.50274,13.43872
Host: atlas.microsoft.com
x-ms-client-id: 30d7cc….9f55
Authorization: Bearer eyJ0e…HNIVN

Zie Verificatiedetails weergeven voor meer informatie over het weergeven van uw client-id.

Tip

De client-id programmatisch ophalen

Wanneer u PowerShell gebruikt, wordt de client-id opgeslagen als de UniqueId eigenschap in het IMapsAccount object. U haalt deze eigenschap op met Get-AzMapsAccountbijvoorbeeld:

$maps = Get-AzMapsAccount -Name {Azure-Maps_Account-Name} -ResourceGroupName {Resource-Group-Name} -SubscriptionId {SubscriptionId}
$ClientId = $maps.UniqueId

Wanneer u de Azure CLI gebruikt, gebruikt u de az maps account show opdracht met de --query parameter, bijvoorbeeld:

$ClientId = az maps account show --name {Azure-Maps_Account-Name} --resource-group {Resource-Group-Name} --subscription {SubscriptionId} --query properties.uniqueId

Autorisatie met op rollen gebaseerd toegangsbeheer

Vereisten

Als u niet bekend bent met Azure RBAC, biedt het overzicht van op rollen gebaseerd toegangsbeheer van Azure (Azure RBAC) principal-typen een set machtigingen, ook wel roldefinitie genoemd. Een roldefinitie biedt machtigingen voor REST API-acties. Azure Maps ondersteunt toegang tot alle principaltypen voor op rollen gebaseerd toegangsbeheer van Azure (Azure RBAC), waaronder afzonderlijke Microsoft Entra-gebruikers, groepen, toepassingen, Azure-resources en door Azure beheerde identiteiten. Het toepassen van toegang tot een of meer Azure Maps-accounts wordt een bereik genoemd. Er wordt een roltoewijzing gemaakt wanneer een principal, roldefinitie en bereik worden toegepast.

Overzicht

In de volgende secties worden concepten en onderdelen van Azure Maps-integratie met Azure RBAC besproken. Als onderdeel van het proces voor het instellen van uw Azure Maps-account is een Microsoft Entra-directory gekoppeld aan het Azure-abonnement, dat het Azure Maps-account zich bevindt.

Wanneer u Azure RBAC configureert, kiest u een beveiligingsprincipaal en past u deze toe op een roltoewijzing. Zie Azure-rollen toewijzen met behulp van Azure Portal voor meer informatie over het toevoegen van roltoewijzingen in Azure Portal.

Een roldefinitie kiezen

De volgende roldefinitietypen bestaan ter ondersteuning van toepassingsscenario's.

Azure-roldefinitie Beschrijving
Azure Maps Search and Render Data Reader Biedt alleen toegang tot azure Maps REST API's voor zoeken en weergeven om de toegang tot eenvoudige gebruiksvoorbeelden van webbrowsers te beperken.
Azure Maps-gegevenslezer Biedt toegang tot onveranderbare Azure Maps REST API's.
Azure Maps-gegevensbijdrager Biedt toegang tot onveranderbare REST API's van Azure Maps. Dempbaarheid, gedefinieerd door de acties: schrijven en verwijderen.
Azure Maps-gegevens lezen en batchrol Deze rol kan worden gebruikt om lees- en batchacties toe te wijzen in Azure Maps.
Aangepaste roldefinitie Maak een gemaakte rol om flexibele beperkte toegang tot Azure Maps REST API's mogelijk te maken.

Voor sommige Azure Maps-services zijn mogelijk verhoogde bevoegdheden vereist voor het uitvoeren van schrijf- of verwijderacties op Azure Maps REST API's. De rol Azure Maps Data Contributor is vereist voor services die schrijf- of verwijderacties bieden. In de volgende tabel wordt beschreven welke services Azure Maps Data Contributor van toepassing is bij het gebruik van schrijf- of verwijderacties. Wanneer alleen leesacties vereist zijn, kan de rol Gegevenslezer van Azure Maps worden gebruikt in plaats van de rol Inzender voor Azure Maps-gegevens.

Azure Maps-service Azure Maps-roldefinitie
Maker (afgeschaft1) Azure Maps-gegevensbijdrager
Ruimtelijk (afgeschaft1) Azure Maps-gegevensbijdrager
Batch zoeken en routeren Azure Maps-gegevensbijdrager

1 Azure Maps Creator, en het gegevensregister en ruimtelijke services zijn nu afgeschaft en worden buiten gebruik gesteld op 30-9-25.

Zie Azure RBAC configureren voor Azure Maps voor informatie over het weergeven van uw Azure RBAC-instellingen.

Aangepaste roldefinities

Een aspect van toepassingsbeveiliging is het principe van minimale bevoegdheden, de praktijk van het beperken van toegangsrechten tot de rechten die vereist zijn voor de huidige taak. Het beperken van toegangsrechten wordt bereikt door aangepaste roldefinities te maken die ondersteuning bieden voor use cases waarvoor verdere granulariteit nodig is voor toegangsbeheer. Als u een aangepaste roldefinitie wilt maken, selecteert u specifieke gegevensacties die u wilt opnemen of uitsluiten voor de definitie.

De aangepaste roldefinitie kan vervolgens worden gebruikt in een roltoewijzing voor elke beveiligingsprincipaal. Zie aangepaste Azure-rollen voor meer informatie over aangepaste Azure-roldefinities.

Hier volgen enkele voorbeeldscenario's waarin aangepaste rollen de beveiliging van toepassingen kunnen verbeteren.

Scenario Actie(s) voor aangepaste rolgegevens
Een openbare of interactieve aanmeldingswebpagina met basiskaarttegels en geen andere REST API's. Microsoft.Maps/accounts/services/render/read
Een toepassing die alleen reverse geocodering en geen andere REST API's vereist. Microsoft.Maps/accounts/services/search/read
Een rol voor een beveiligingsprincipaal, die vraagt om het lezen van kaartgegevens op basis van Azure Maps Creator en REST API's voor basistoewijzingstegels. Microsoft.Maps/accounts/services/data/read, Microsoft.Maps/accounts/services/render/read
Een rol voor een beveiligingsprincipaal, waarvoor het lezen, schrijven en verwijderen van kaartgegevens op basis van Creator is vereist. Gedefinieerd als een rol van kaartgegevenseditor die geen toegang tot andere REST API's toestaat, zoals tegels voor basistoewijzingen. Microsoft.Maps/accounts/services/data/read, , Microsoft.Maps/accounts/services/data/writeMicrosoft.Maps/accounts/services/data/delete

Bereik

Wanneer u een roltoewijzing maakt, wordt deze gedefinieerd in de Azure-resourcehiërarchie. De bovenkant van de hiërarchie is een beheergroep en het laagste is een Azure-resource, zoals een Azure Maps-account. Het toewijzen van een roltoewijzing aan een resourcegroep kan toegang tot meerdere Azure Maps-accounts of -resources in de groep inschakelen.

Tip

De algemene aanbeveling van Microsoft is het toewijzen van toegang tot het Azure Maps-accountbereik, omdat hiermee onbedoelde toegang tot andere Azure Maps-accounts die in hetzelfde Azure-abonnement aanwezig zijn, wordt voorkomen.

Lokale verificatie uitschakelen

Azure Maps-accounts ondersteunen de standaardeigenschap van Azure in de Management-API voor Microsoft.Maps/accounts aangeroepen disableLocalAuth. Wanneer true, alle verificatie voor de Azure Maps-gegevensvlak REST API is uitgeschakeld, met uitzondering van Microsoft Entra-verificatie. Dit wordt geconfigureerd met behulp van Azure Policy om distributie en beheer van gedeelde sleutels en SAS-tokens te beheren. Zie Wat is Azure Policy? voor meer informatie.

Het uitschakelen van lokale verificatie wordt niet onmiddellijk van kracht. Wacht enkele minuten voordat de service toekomstige verificatieaanvragen blokkeert. Als u lokale verificatie opnieuw wilt inschakelen, stelt u de eigenschap false in op en na een paar minuten wordt de lokale verificatie hervat.

{
  // omitted other properties for brevity.
  "properties": {
    "disableLocalAuth": true
  }
}

Shared Access Signature-tokenverificatie

Sas-tokens (Shared Access Signature) zijn verificatietokens die zijn gemaakt met de JSON-webtokenindeling (JWT) en zijn cryptografisch ondertekend om te bewijzen dat een toepassing is geverifieerd bij de REST API van Azure Maps. Een SAS-token dat is gemaakt door een door de gebruiker toegewezen beheerde identiteit te integreren met een Azure Maps-account in uw Azure-abonnement. De door de gebruiker toegewezen beheerde identiteit krijgt autorisatie voor het Azure Maps-account via Azure RBAC met behulp van ingebouwde of aangepaste roldefinities.

Functionele sleutelverschillen van SAS-token van Microsoft Entra-toegangstokens:

  • Levensduur van een token voor een maximale vervaldatum van één dag (24 uur).
  • Azure-locatie en geografietoegangsbeheer per token.
  • Frequentielimieten per token voor ongeveer 1 tot 500 aanvragen per seconde.
  • Persoonlijke sleutels van het token zijn de primaire en secundaire sleutels van een Azure Maps-accountresource.
  • Service-principalobject voor autorisatie wordt geleverd door een door de gebruiker toegewezen beheerde identiteit.

SAS-tokens zijn onveranderbaar. Dit betekent dat nadat een token is gemaakt, het SAS-token geldig is totdat aan de vervaldatum is voldaan en de configuratie van de toegestane regio's, frequentielimieten en door de gebruiker toegewezen beheerde identiteit niet kan worden gewijzigd. Lees hieronder meer over toegangsbeheer voor het intrekken van SAS-token en wijzigingen in toegangsbeheer.

Inzicht in frequentielimieten voor SAS-tokens

Maximale frequentielimiet voor SAS-token kan de facturering voor een Azure Maps-resource beheren

Wanneer u een maximale frequentielimiet opgeeft voor het token (maxRatePerSecond), worden de overtollige tarieven niet in rekening gebracht voor het account, zodat u een bovengrens voor factureerbare transacties voor het account kunt instellen wanneer u het token gebruikt. De toepassing ontvangt echter clientfoutreacties met 429 (TooManyRequests) voor alle transacties zodra deze limiet is bereikt. Het is de verantwoordelijkheid van de toepassing om nieuwe pogingen en distributie van SAS-tokens te beheren. Er is geen limiet voor het aantal SAS-tokens dat kan worden gemaakt voor een account. Om een verhoging of afname van de limiet van een bestaand token mogelijk te maken; er moet een nieuw SAS-token worden gemaakt. Het oude SAS-token is nog steeds geldig totdat het is verlopen.

Geschat voorbeeld:

Geschatte maximumsnelheid per seconde Werkelijk tarief per seconde Duur van aanhoudende snelheid in seconden Totaal factureerbare transacties
10 20 600 6.000

De werkelijke frequentielimieten variëren op basis van de mogelijkheid van Azure Maps om consistentie binnen een bepaalde tijd af te dwingen. Dit biedt echter preventieve controle over de factureringskosten.

Frequentielimieten worden afgedwongen per Azure-locatie, niet globaal of geografisch

Eén SAS-token met een maxRatePerSecond van de 10 kan bijvoorbeeld worden gebruikt om de doorvoer op de East US locatie te beperken. Als hetzelfde token wordt gebruikt, West US 2wordt er een nieuwe teller gemaakt om de doorvoer te beperken tot 10 op die locatie, onafhankelijk van de East US locatie. Als u de kosten wilt beheren en de voorspelbaarheid wilt verbeteren, raden we het volgende aan:

  1. Sas-tokens maken met toegewezen toegestane Azure-locaties voor doelgeografie. Lees verder om inzicht te hebben in het maken van SAS-tokens.
  2. Gebruik rest API-eindpunten voor geografische gegevensvlakken of https://us.atlas.microsoft.com https://eu.atlas.microsoft.com.

Houd rekening met de toepassingstopologie waarbij het eindpunt https://us.atlas.microsoft.com wordt gerouteerd naar dezelfde Amerikaanse locaties waarop de Azure Maps-services worden gehost, zoals East US, West Central USof West US 2. Hetzelfde idee is van toepassing op andere geografische eindpunten, zoals https://eu.atlas.microsoft.com tussen West Europe en North Europe. Gebruik een SAS-token dat gebruikmaakt van dezelfde Azure-locaties die door de toepassing worden gebruikt om onverwachte autorisaties te voorkomen. De eindpuntlocatie wordt gedefinieerd met behulp van de AZURE Maps Management REST API.

Standaardfrequentielimieten nemen precedent over sas-tokenfrequentielimieten

Zoals beschreven in Azure Maps-frequentielimieten, hebben afzonderlijke serviceaanbiedingen verschillende frequentielimieten die worden afgedwongen als een aggregaties van het account.

Overweeg het geval van Search-service - Niet-Batch Reverse, met de limiet van 250 query's per seconde (QPS) voor de volgende tabellen. Elke tabel vertegenwoordigt geschatte totale geslaagde transacties uit voorbeeldgebruik.

In de eerste tabel ziet u één token met een maximumaanvraag per seconde van 500 en het werkelijke gebruik van de toepassing is 500 aanvraag per seconde voor een duur van 60 seconden. Search-service - Niet-Batch Reverse heeft een snelheidslimiet van 250, wat betekent dat het totale aantal aanvragen van 30.000 aanvragen in de 60 seconden is; 15.000 van deze aanvragen zijn factureerbare transacties. De resterende aanvragen resulteren in statuscode 429 (TooManyRequests).

Naam Geschatte maximumsnelheid per seconde Werkelijk tarief per seconde Duur van aanhoudende snelheid in seconden Totaal aantal geslaagde transacties bij benadering
token 500 500 60 ~15.000

Als er bijvoorbeeld twee SAS-tokens worden gemaakt en dezelfde locatie gebruiken als een Azure Maps-account, deelt elk token nu de standaardfrequentielimiet van 250 QPS. Als elk token tegelijkertijd wordt gebruikt met hetzelfde doorvoertoken 1 en token 2, verleent elk 7500 geslaagde transacties.

Naam Geschatte maximumsnelheid per seconde Werkelijk tarief per seconde Duur van aanhoudende snelheid in seconden Totaal aantal geslaagde transacties bij benadering
token 1 250 250 60 ~7500
token 2 250 250 60 ~7500

Toegangsbeheer voor SAS-token begrijpen

SAS-tokens gebruiken RBAC om de toegang tot de REST API te beheren. Wanneer u een SAS-token maakt, wordt aan de vereiste beheerde identiteit voor het toewijzingsaccount een Azure RBAC-rol toegewezen die toegang verleent tot specifieke REST API-acties. Zie Een roldefinitie kiezen om te bepalen welke API's de toepassing toestaat.

Als u tijdelijke toegang wilt toewijzen en de toegang wilt verwijderen voordat het SAS-token verloopt, trekt u het token in. Andere redenen om de toegang in te trekken, kunnen zijn als het token onbedoeld wordt gedistribueerd met Azure Maps Data Contributor roltoewijzing en iedereen met het SAS-token mogelijk gegevens kan lezen en schrijven naar Azure Maps REST API's die gevoelige gegevens of onverwachte financiële kosten van gebruik kunnen blootstellen.

er zijn twee opties om de toegang voor SAS-token(en) in te trekken:

  1. Genereer de sleutel die is gebruikt door het SAS-token of secondaryKey van het kaartaccount opnieuw.
  2. Verwijder de roltoewijzing voor de beheerde identiteit in het gekoppelde kaartaccount.

Waarschuwing

Als u een beheerde identiteit verwijdert die wordt gebruikt door een SAS-token of het intrekken van toegangsbeheer van de beheerde identiteit, worden exemplaren van uw toepassing veroorzaakt door het SAS-token en de beheerde identiteit om opzettelijk of vanuit Azure Maps REST API's te retourneren 401 Unauthorized , 403 Forbidden waardoor toepassingsonderbreking wordt veroorzaakt.

Om onderbrekingen te voorkomen:

  1. Voeg een tweede beheerde identiteit toe aan het toewijzingsaccount en verdeel de nieuwe beheerde identiteit de juiste roltoewijzing.
  2. Maak een SAS-token met behulp van secondaryKey, of een andere beheerde identiteit dan de vorige, als de signingKey en distribueer het nieuwe SAS-token naar de toepassing.
  3. Genereer de primaire sleutel opnieuw, verwijder de beheerde identiteit uit het account en verwijder de roltoewijzing voor de beheerde identiteit.

SAS-tokens maken

Als u SAS-tokens wilt maken, moet u roltoegang hebben Contributor voor het beheren van Azure Maps-accounts en door de gebruiker toegewezen identiteiten in het Azure-abonnement.

Belangrijk

Bestaande Azure Maps-accounts die zijn gemaakt op de Azure-locatie global bieden geen ondersteuning voor beheerde identiteiten.

Eerst moet u een door de gebruiker toegewezen beheerde identiteit maken op dezelfde locatie als het Azure Maps-account.

Tip

U moet dezelfde locatie gebruiken voor zowel de beheerde identiteit als het Azure Maps-account.

Zodra een beheerde identiteit is gemaakt, kunt u het Azure Maps-account maken of bijwerken en koppelen. Zie Uw Azure Maps-account beheren voor meer informatie.

Zodra het account is gemaakt of bijgewerkt met de beheerde identiteit; wijs op rollen gebaseerd toegangsbeheer voor de beheerde identiteit toe aan een Azure Maps-gegevensrol binnen het accountbereik. Hierdoor kan de beheerde identiteit toegang krijgen tot de Rest API van Azure Maps voor uw kaartaccount.

Maak vervolgens een SAS-token met behulp van de Azure Management SDK-hulpprogramma's, een LIJST met SAS-bewerkingen op accountbeheer-API of de pagina Shared Access Signature van de mapaccountresource in Azure Portal.

SAS-tokenparameters:

Parameternaam Voorbeeldwaarde Beschrijving
signingKey primaryKey Vereist, de tekenreeks-enumwaarde voor de ondertekeningssleutel of primaryKeysecondaryKey beheerde identiteit wordt gebruikt om de handtekening van de SAS te maken.
principalId <GUID> Vereist, de principalId is de object-id (principal) van de door de gebruiker toegewezen beheerde identiteit die is gekoppeld aan het kaartaccount.
regio's [ "eastus", "westus2", "westcentralus" ] Optioneel, de standaardwaarde is null. De regio's bepalen welke regio's het SAS-token kunnen worden gebruikt in de REST-gegevensvlak-API van Azure Maps. Door de parameter regio's weg te laten, kan het SAS-token zonder beperkingen worden gebruikt. Wanneer de toepassing wordt gebruikt in combinatie met een geografisch eindpunt in het gegevensvlak van Azure Maps, zoals us.atlas.microsoft.com en eu.atlas.microsoft.com kan de toepassing het gebruik binnen de opgegeven geografie beheren. Dit maakt preventie van gebruik in andere geografische gebieden mogelijk.
maxRatePerSecond 500 Vereist, de opgegeven geschatte maximumaanvraag per seconde waaraan het SAS-token wordt verleend. Zodra de limiet is bereikt, is meer doorvoer beperkt met HTTP-statuscode 429 (TooManyRequests).
starten 2021-05-24T10:42:03.1567373Z Vereist, een UTC-datum die de datum en tijd aangeeft waarop het token actief wordt.
expiry 2021-05-24T11:42:03.1567373Z Vereist, een UTC-datum die de datum en tijd aangeeft waarop het token verloopt. De duur tussen begin en vervaldatum mag niet langer zijn dan 24 uur.

Toepassing configureren met SAS-token

Nadat de toepassing een SAS-token heeft ontvangen, verzenden de Azure Maps SDK en/of toepassingen een HTTPS-aanvraag met de volgende vereiste HTTP-header naast andere REST API HTTP-headers:

Koptekstnaam Weergegeven als
Autorisatie jwt-sas eyJ0e....HNIVN

Notitie

jwt-sas is het verificatieschema dat moet worden aangegeven met behulp van een SAS-token. Neem geen x-ms-client-id headers of andere autorisatieheaders of subscription-key queryreeksparameter op.

Cors (Cross Origin Resource Sharing)

CORS is een HTTP-protocol waarmee een webtoepassing die onder het ene domein wordt uitgevoerd, toegang heeft tot resources in een ander domein. Webbrowsers implementeren een beveiligingsbeperking die bekend staat als beleid voor dezelfde oorsprong waarmee wordt voorkomen dat een webpagina API's in een ander domein aanroept; CORS biedt een veilige manier om toe te staan dat één domein (het oorspronkelijke domein) API's in een ander domein aanroept. Met behulp van de Azure Maps-accountresource kunt u configureren welke origins toegang hebben tot de Rest API van Azure Maps vanuit uw toepassingen.

Belangrijk

CORS is geen autorisatiemechanisme. Elke aanvraag voor een kaartaccount met behulp van REST API, wanneer CORS is ingeschakeld, heeft ook een geldig verificatieschema voor het kaartaccount nodig, zoals gedeelde sleutel, Microsoft Entra-id of SAS-token.

CORS wordt ondersteund voor alle prijscategorieën voor kaartaccounts, gegevensvlakeindpunten en locaties.

Vereisten

Om te voorkomen dat schadelijke code wordt uitgevoerd op de client, blokkeren moderne browsers aanvragen van webtoepassingen naar resources die in een afzonderlijk domein worden uitgevoerd.

  • Als u niet bekend bent met CORS, raadpleegt u CORS (Cross-Origin Resource Sharing), wordt met een Access-Control-Allow-Origin header opgegeven welke origins eindpunten van een Azure Maps-account mogen aanroepen. HET CORS-protocol is niet specifiek voor Azure Maps.

CORS-aanvragen

Een CORS-aanvraag van een oorspronkelijk domein kan bestaan uit twee afzonderlijke aanvragen:

  • Een voorbereidende aanvraag, die de CORS-beperkingen opvraagt die door de service worden opgelegd. De voorbereidende aanvraag is vereist, tenzij de aanvraag de standaardmethode GET, HEAD, POST of aanvragen is die aanvraagheader bevatten Authorization .

  • De werkelijke aanvraag, gemaakt op basis van de gewenste resource.

Voorbereidende aanvraag

De voorbereidende aanvraag wordt niet alleen uitgevoerd als een beveiligingsmaatregel om ervoor te zorgen dat de server de methode en headers begrijpt die in de werkelijke aanvraag worden verzonden en dat de server de bron van de aanvraag kent en vertrouwt, maar ook de CORS-beperkingen opvraagt die zijn vastgesteld voor het kaartaccount. De webbrowser (of een andere gebruikersagent) verzendt een OPTIONS-aanvraag met de aanvraagheaders, de methode en het oorspronkelijke domein. De kaartaccountservice probeert CORS-regels op te halen als accountverificatie mogelijk is via het preflight-protocol van CORS.

Als verificatie niet mogelijk is, evalueert de maps-service een vooraf geconfigureerde set CORS-regels waarmee wordt opgegeven welke oorspronkelijke domeinen, aanvraagmethoden en aanvraagheaders kunnen worden opgegeven voor een werkelijke aanvraag voor de maps-service. Standaard is een maps-account zo geconfigureerd dat alle origins naadloze integratie in webbrowsers mogelijk maken.

De service reageert op de voorbereidende aanvraag met de vereiste headers voor toegangsbeheer als aan de volgende criteria wordt voldaan:

  1. De OPTIONS-aanvraag bevat de vereiste CORS-headers (de headers Origin en Access-Control-Request-Method)
  2. Verificatie is geslaagd en een CORS-regel is ingeschakeld voor het account dat overeenkomt met de voorbereidende aanvraag.
  3. Verificatie is overgeslagen vanwege vereiste Authorization aanvraagheaders die niet kunnen worden opgegeven bij de voorbereidende aanvraag.

Wanneer de voorbereidende aanvraag is geslaagd, reageert de service met statuscode 200 (OK)en bevat de vereiste Access-Control-headers in het antwoord.

De service weigert voorbereidende aanvragen als de volgende voorwaarden optreden:

  1. Als de OPTIONS-aanvraag niet de vereiste CORS-headers bevat (de headers Origin en Access-Control-Request-Method), reageert de service met statuscode 400 (Bad request).
  2. Als de verificatie is geslaagd bij de voorbereidende aanvraag en er geen CORS-regel overeenkomt met de voorbereidende aanvraag, reageert de service met statuscode 403 (Forbidden). Dit kan gebeuren als de CORS-regel is geconfigureerd voor het accepteren van een oorsprong die niet overeenkomt met de aanvraagheader van de huidige browserclient.

Notitie

Een voorbereidende aanvraag wordt geëvalueerd op basis van de service en niet op basis van de aangevraagde resource. De accounteigenaar moet CORS hebben ingeschakeld door de juiste accounteigenschappen in te stellen om de aanvraag te laten slagen.

Werkelijke aanvraag

Zodra de voorbereidende aanvraag is geaccepteerd en het antwoord wordt geretourneerd, verzendt de browser de daadwerkelijke aanvraag op basis van de kaartservice. De browser weigert de werkelijke aanvraag onmiddellijk als de voorbereidende aanvraag wordt geweigerd.

De werkelijke aanvraag wordt behandeld als een normale aanvraag voor de kaartservice. De aanwezigheid van de Origin header geeft aan dat de aanvraag een CORS-aanvraag is en dat de service vervolgens wordt gevalideerd op basis van de CORS-regels. Als er een overeenkomst wordt gevonden, worden de access-control-headers toegevoegd aan het antwoord en teruggestuurd naar de client. Als er geen overeenkomst wordt gevonden, retourneert het antwoord een 403 (Forbidden) cors-oorsprongsfout.

CORS-beleid inschakelen

Wanneer een kaartaccount wordt gemaakt of bijgewerkt, geven de eigenschappen ervan de toegestane oorsprongen op die moeten worden geconfigureerd. U kunt een CORS-regel instellen voor de eigenschappen van het Azure Maps-account via azure Maps Management SDK, Azure Maps Management REST API en portal. Zodra u de CORS-regel voor de service hebt ingesteld, wordt een correct geautoriseerde aanvraag voor de service vanuit een ander domein geëvalueerd om te bepalen of deze is toegestaan volgens de regel die u hebt opgegeven. Voorbeeld:

{
  "location": "eastus",
  "sku": {
    "name": "G2"
  },
  "kind": "Gen2",
  "properties": {
    "cors": {
      "corsRules": [
        {
          "allowedOrigins": [
            "https://www.azure.com",
            "https://www.microsoft.com"
          ]
        }
      ]
    }
  }
}

Er kan slechts één CORS-regel met de lijst met toegestane oorsprongen worden opgegeven. Met elke oorsprong kan de HTTP-aanvraag worden gedaan naar azure Maps REST API in de webbrowser van de opgegeven oorsprong.

CORS-beleid verwijderen

U kunt CORS verwijderen:

  • Handmatig in de Azure-portal
  • Programmatisch met behulp van:
    • De Azure Maps SDK
    • REST API voor Azure Maps-beheer
    • Een ARM-sjabloon

Tip

Als u de REST API van Azure Maps Management gebruikt, gebruikt PUT u of PATCH met een lege corsRule lijst in de aanvraagbody.

{
  "location": "eastus",
  "sku": {
    "name": "G2"
  },
  "kind": "Gen2",
  "properties": {
        "cors": {
          "corsRules": []
        }
    }
  }
}

Inzicht in factureringstransacties

Azure Maps telt geen factureringstransacties voor:

  • HTTP-statuscodes van 5xx
  • 401 (Niet geautoriseerd)
  • 403 (verboden)
  • 408 (time-out)
  • 429 (TooManyRequests)
  • VOORBEREIDENDe CORS-aanvragen

Zie Prijzen van Azure Maps voor meer informatie over factureringstransacties en andere prijzen van Azure Maps.

Volgende stappen

Zie voor meer informatie over aanbevolen beveiligingsprocedures:

Best practices voor verificatie en autorisatie

Zie voor meer informatie over het verifiëren van een toepassing met Microsoft Entra ID en Azure Maps:

Verificatie in Azure Maps beheren

Zie voor meer informatie over het verifiëren van Azure Maps Control met Microsoft Entra ID:

Azure Maps Map Control gebruiken