Verificatie met Azure Maps

Azure Kaarten ondersteunt drie manieren om aanvragen te verifiëren: Verificatie met gedeelde sleutels, Verificatie met Microsoft Entra-id en SAS-tokenverificatie (Shared Access Signature). In dit artikel worden verificatiemethoden uitgelegd om u te helpen bij de implementatie van Azure Kaarten-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 Kaarten ondersteunen we nu TLS (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 Kaarten-account is gemaakt. U wordt aangeraden om de primaire sleutel als abonnementssleutel te gebruiken bij het aanroepen van Azure Kaarten met verificatie met gedeelde sleutels. Verificatie met gedeelde sleutels geeft een sleutel die wordt gegenereerd door een Azure Kaarten-account door aan een Azure Kaarten-service. Voeg voor elke aanvraag aan Azure Kaarten-services 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/mapData/upload?api-version=1.0&dataFormat=zip&subscription-key={Your-Azure-Maps-Subscription-key}

Belangrijk

Primaire en secundaire sleutels moeten worden behandeld als gevoelige gegevens. De gedeelde sleutel wordt gebruikt om alle Azure Kaarten REST API 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 Kaarten biedt verificatie voor Azure Kaarten-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 Kaarten accepteert OAuth 2.0-toegangstokens voor Microsoft Entra-tenants die zijn gekoppeld aan een Azure-abonnement dat een Azure Kaarten-account bevat. Azure Kaarten accepteert ook tokens voor:

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

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

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

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

Beheerde identiteiten voor Azure-resources en Azure Kaarten

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 Kaarten-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 Kaarten 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-idis de op accounts gebaseerde GUID van Azure Kaarten die wordt weergegeven op de verificatiepagina van Azure Kaarten.

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

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 Kaarten 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 Kaarten-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 Kaarten-integratie met Azure RBAC besproken. Als onderdeel van het proces voor het instellen van uw Azure Kaarten-account is een Microsoft Entra-directory gekoppeld aan het Azure-abonnement, dat het Azure Kaarten-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 Kaarten Search and Render Data Reader	Biedt alleen toegang tot azure Kaarten REST API's voor zoeken en weergeven om de toegang tot eenvoudige gebruiksvoorbeelden van webbrowsers te beperken.
Azure Kaarten-gegevenslezer	Biedt toegang tot onveranderbare Azure Kaarten REST API's.
Inzender voor Azure Kaarten-gegevens	Biedt toegang tot veranderlijke Azure Kaarten REST API's. Dempbaarheid, gedefinieerd door de acties: schrijven en verwijderen.
Azure Kaarten-gegevens lezen en batchrol	Deze rol kan worden gebruikt om lees- en batchacties toe te wijzen in Azure Kaarten.
Aangepaste roldefinitie	Maak een gemaakte rol om flexibele beperkte toegang tot Azure Kaarten REST API's mogelijk te maken.

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

Azure Kaarten-service	Azure Kaarten-roldefinitie
Data	Inzender voor Azure Kaarten-gegevens
Maker	Inzender voor Azure Kaarten-gegevens
Ruimtelijk	Inzender voor Azure Kaarten-gegevens
Batch zoeken en routeren	Inzender voor Azure Kaarten-gegevens

Zie Azure RBAC configureren voor Azure Kaarten 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 Kaarten Creator en REST API's voor basistoewijzingen.	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 Kaarten-account. Als u een roltoewijzing toewijst aan een resourcegroep, kunt u toegang tot meerdere Azure Kaarten-accounts of -resources in de groep inschakelen.

Tip

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

Lokale verificatie uitschakelen

Azure Kaarten-accounts ondersteunen de standaardeigenschap van Azure in de Management-API voor Microsoft.Maps/accounts aangeroependisableLocalAuth. Wanneer truealle verificatie voor de Azure Kaarten REST API voor het gegevensvlak 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 verificatie voor een toepassing aan de Azure Kaarten REST API te bewijzen. Een SAS-token dat is gemaakt door een door de gebruiker toegewezen beheerde identiteit te integreren met een Azure Kaarten-account in uw Azure-abonnement. De door de gebruiker toegewezen beheerde identiteit krijgt autorisatie voor het Azure Kaarten-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 Kaarten-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 Kaarten-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 Kaarten 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.comhttps://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 Kaarten-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 Kaarten Management REST API.

Standaardfrequentielimieten nemen precedent over sas-tokenfrequentielimieten

Zoals beschreven in Azure Kaarten 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 Kaarten-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 Kaarten 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 403 Forbidden vanuit Azure Kaarten REST API's te retourneren401 Unauthorized, 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 Kaarten-accounts en door de gebruiker toegewezen identiteiten in het Azure-abonnement.

Belangrijk

Bestaande Azure Kaarten-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 Kaarten-account.

Tip

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

Zodra een beheerde identiteit is gemaakt, kunt u het Azure Kaarten-account maken of bijwerken en koppelen. Zie Uw Azure Kaarten-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 Kaarten gegevensrol binnen het accountbereik. Hierdoor kan de beheerde identiteit toegang krijgen tot de Azure Kaarten REST API 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 AZURE Kaarten REST-gegevensvlak-API. Door de parameter regio's weg te laten, kan het SAS-token zonder beperkingen worden gebruikt. Wanneer deze wordt gebruikt in combinatie met een Geografisch eindpunt van Azure Kaarten gegevensvlak, zodat us.atlas.microsoft.comeu.atlas.microsoft.com de toepassing het gebruik kan beheren met de opgegeven geografie. 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 Kaarten 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 Kaarten-accountresource kunt u configureren welke origins toegang hebben tot de Azure Kaarten REST API 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 Kaarten-account mogen aanroepen. HET CORS-protocol is niet specifiek voor Azure Kaarten.

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 Kaarten-account via azure Kaarten Management SDK, Azure Kaarten 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 origin kan de HTTP-aanvraag worden gedaan naar Azure Kaarten 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 Kaarten SDK
  • REST API voor Azure Kaarten-beheer
  • Een ARM-sjabloon

Tip

Als u de REST API van Azure Kaarten 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 Kaarten telt geen factureringstransacties voor:

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

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

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 Kaarten:

Verificatie in Azure Maps beheren

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

Azure Maps Map Control gebruiken