Autentisering med Azure Maps

Artikel
09/25/2024

Azure Maps stöder tre sätt att autentisera begäranden: autentisering med delad nyckel, Microsoft Entra-ID-autentisering och SAS-tokenautentisering (Signatur för delad åtkomst). I den här artikeln beskrivs autentiseringsmetoder som hjälper dig att implementera Azure Maps-tjänster. Artikeln beskriver även andra kontokontroller, till exempel inaktivering av lokal autentisering för Azure Policy och resursdelning mellan ursprung (CORS).

Kommentar

För att förbättra säker kommunikation med Azure Maps har vi nu stöd för TLS (Transport Layer Security) 1.2 och vi drar tillbaka stödet för TLS 1.0 och 1.1. Om du för närvarande använder TLS 1.x utvärderar du din TLS 1.2-beredskap och utvecklar en migreringsplan med testningen som beskrivs i Lösa TLS 1.0-problemet.

Autentisering med delad nyckel

Information om hur du visar dina nycklar i Azure Portal finns i Visa autentiseringsinformation.

Primära och sekundära nycklar genereras när Azure Maps-kontot har skapats. Du uppmanas att använda primärnyckeln som prenumerationsnyckel när du anropar Azure Maps med autentisering med delad nyckel. Autentisering med delad nyckel skickar en nyckel som genereras av ett Azure Maps-konto till en Azure Maps-tjänst. För varje begäran till Azure Maps-tjänster lägger du till prenumerationsnyckeln som en parameter i URL:en. Den sekundära nyckeln kan användas i scenarier som rullande nyckeländringar.

Exempel med prenumerationsnyckeln som en parameter i url:en:

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

Viktigt!

Primära och sekundära nycklar ska behandlas som känsliga data. Den delade nyckeln används för att autentisera alla Azure Maps REST API. Användare som använder en delad nyckel bör abstrahera API-nyckeln, antingen via miljövariabler eller säker hemlig lagring, där den kan hanteras centralt.

Microsoft Entra-autentisering

Azure-prenumerationer tillhandahålls med en Microsoft Entra-klient för att aktivera detaljerad åtkomstkontroll. Azure Maps erbjuder autentisering för Azure Maps-tjänster med hjälp av Microsoft Entra-ID. Microsoft Entra ID tillhandahåller identitetsbaserad autentisering för användare och program som är registrerade i Microsoft Entra-klientorganisationen.

Azure Maps accepterar OAuth 2.0-åtkomsttoken för Microsoft Entra-klienter som är associerade med en Azure-prenumeration som innehåller ett Azure Maps-konto. Azure Maps accepterar även token för:

Microsoft Entra-användare
Partnerprogram som använder behörigheter som delegerats av användare
Hanterade identiteter för Azure-resurser

Azure Maps genererar en unik identifierare (klient-ID) för varje Azure Maps-konto. Du kan begära token från Microsoft Entra-ID när du kombinerar det här klient-ID:t med andra parametrar.

Mer information om hur du konfigurerar Microsoft Entra-ID och begärandetoken för Azure Maps finns i Hantera autentisering i Azure Maps.

Allmän information om autentisering med Microsoft Entra-ID finns i Autentisering kontra auktorisering.

Hanterade identiteter för Azure-resurser och Azure Maps

Hanterade identiteter för Azure-resurser tillhandahåller Azure-tjänster med ett automatiskt hanterat programbaserat säkerhetsobjekt som kan autentiseras med Microsoft Entra-ID. Med rollbaserad åtkomstkontroll i Azure (Azure RBAC) kan det hanterade identitetssäkerhetsobjektet ha behörighet att komma åt Azure Maps-tjänster. Några exempel på hanterade identiteter är: Azure App Service, Azure Functions och Azure Virtual Machines. En lista över hanterade identiteter finns i Azure-tjänster som kan använda hanterade identiteter för att få åtkomst till andra tjänster. Mer information om hanterade identiteter finns i Hantera autentisering i Azure Maps.

Konfigurera Microsoft Entra-autentisering för program

Program autentiseras med Microsoft Entra-klientorganisationen med ett eller flera scenarier som stöds av Microsoft Entra ID. Varje Microsoft Entra-programscenario representerar olika krav baserat på affärsbehov. Vissa program kan kräva användarinloggning och andra program kan kräva en programinloggning. Mer information finns i Autentiseringsflöden och programscenarier.

När programmet har fått en åtkomsttoken skickar SDK och/eller programmet en HTTPS-begäran med följande uppsättning nödvändiga HTTP-huvuden utöver andra REST API HTTP-huvuden:

Rubriknamn	Värde
x-ms-client-id	30d7cc... 9f55
Auktorisering	Bearer eyJ0e... HNIVN

Kommentar

x-ms-client-id är det Azure Maps-kontobaserade GUID som visas på autentiseringssidan för Azure Maps.

Här är ett exempel på en Azure Maps-routningsbegäran som använder en OAuth Bearer-token för 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

Information om hur du visar ditt klient-ID finns i Visa autentiseringsinformation.

Dricks

Hämta klient-ID:t programmatiskt

När du använder PowerShell lagras klient-ID:t som egenskapen UniqueId i IMapsAccount objektet. Du hämtar den här egenskapen med , Get-AzMapsAccounttill exempel:

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

När du använder Azure CLI använder du az maps account show kommandot med parametern --query , till exempel:

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

Auktorisering med rollbaserad åtkomstkontroll

Förutsättningar

Om du inte har använt Azure RBAC tidigare ger översikten över rollbaserad åtkomstkontroll i Azure (Azure RBAC) huvudtyper en uppsättning behörigheter, även kallade rolldefinitioner. En rolldefinition ger behörighet till REST API-åtgärder. Azure Maps har stöd för åtkomst till alla huvudtyper för rollbaserad åtkomstkontroll i Azure (Azure RBAC) inklusive: enskilda Microsoft Entra-användare, grupper, program, Azure-resurser och Azure-hanterade identiteter. Att använda åtkomst till ett eller flera Azure Maps-konton kallas för ett omfång. En rolltilldelning skapas när ett huvudnamn, en rolldefinition och ett omfång tillämpas.

Översikt

I nästa avsnitt beskrivs begrepp och komponenter i Azure Maps-integrering med Azure RBAC. Som en del av processen för att konfigurera ditt Azure Maps-konto är en Microsoft Entra-katalog associerad med Azure-prenumerationen, som Azure Maps-kontot finns i.

När du konfigurerar Azure RBAC väljer du ett säkerhetsobjekt och tillämpar det på en rolltilldelning. Information om hur du lägger till rolltilldelningar på Azure Portal finns i Tilldela Azure-roller med hjälp av Azure Portal.

Välja en rolldefinition

Följande rolldefinitionstyper finns som stöd för programscenarier.

Azure-rolldefinition	beskrivning
Azure Maps Search and Render Data Reader	Ger åtkomst till endast sökning och återgivning av REST-API:er för Azure Maps för att begränsa åtkomsten till grundläggande webbläsaranvändningsfall.
Azure Maps-dataläsare	Ger åtkomst till oföränderliga REST-API:er för Azure Maps.
Azure Maps-datadeltagare	Ger åtkomst till föränderliga REST-API:er för Azure Maps. Föränderlighet, definierad av åtgärderna: skriva och ta bort.
Läs- och Batch-roll för Azure Maps-data	Den här rollen kan användas för att tilldela läs- och batchåtgärder på Azure Maps.
Definition av anpassad roll	Skapa en skapad roll för att aktivera flexibel begränsad åtkomst till REST-API:er för Azure Maps.

Vissa Azure Maps-tjänster kan kräva utökade behörigheter för att utföra skriv- eller borttagningsåtgärder på REST-API:er för Azure Maps. Rollen Azure Maps-datadeltagare krävs för tjänster som tillhandahåller skriv- eller borttagningsåtgärder. I följande tabell beskrivs vilka tjänster Azure Maps Data Contributor är tillämpligt när du använder skriv- eller borttagningsåtgärder. När endast läsåtgärder krävs kan azure maps-dataläsarrollen användas i stället för rollen Azure Maps-datadeltagare.

Azure Maps-tjänsten	Rolldefinition för Azure Maps
Skapare (inaktuell¹)	Azure Maps-datadeltagare
Spatial (inaktuell¹)	Azure Maps-datadeltagare
Batch-sökning och -väg	Azure Maps-datadeltagare

¹ Azure Maps Creator och dataregistret och spatiala tjänster är nu inaktuella och kommer att dras tillbaka den 30/30/25.

Information om hur du visar dina Azure RBAC-inställningar finns i Så här konfigurerar du Azure RBAC för Azure Maps.

Anpassade rolldefinitioner

En aspekt av programsäkerhet är principen om minsta behörighet, praxis att begränsa åtkomsträttigheterna till de rättigheter som krävs för det aktuella jobbet. Att begränsa åtkomsträttigheterna uppnås genom att skapa anpassade rolldefinitioner som stöder användningsfall som kräver ytterligare kornighet för åtkomstkontroll. Om du vill skapa en anpassad rolldefinition väljer du specifika dataåtgärder som ska inkluderas eller exkluderas för definitionen.

Den anpassade rolldefinitionen kan sedan användas i en rolltilldelning för alla säkerhetsobjekt. Mer information om anpassade rolldefinitioner i Azure finns i Anpassade Azure-roller.

Här följer några exempelscenarier där anpassade roller kan förbättra programsäkerheten.

Scenario	Anpassade rolldataåtgärder
En offentlig eller interaktiv inloggningswebbsida med baskartpaneler och inga andra REST-API:er.	`Microsoft.Maps/accounts/services/render/read`
Ett program som endast kräver omvänd geokodning och inga andra REST-API:er.	`Microsoft.Maps/accounts/services/search/read`
En roll för ett säkerhetsobjekt som begär en läsning av Azure Maps Creator-baserade kartdata och rest-API:er för baskartan.	`Microsoft.Maps/accounts/services/data/read`, `Microsoft.Maps/accounts/services/render/read`
En roll för ett säkerhetsobjekt som kräver läsning, skrivning och borttagning av skaparbaserade kartdata. Definieras som en roll för kartdataredigeraren som inte tillåter åtkomst till andra REST-API:er som baskartpaneler.	`Microsoft.Maps/accounts/services/data/read`, , `Microsoft.Maps/accounts/services/data/writeMicrosoft.Maps/accounts/services/data/delete`

Förstå omfång

När du skapar en rolltilldelning definieras den i Azure-resurshierarkin. Överst i hierarkin finns en hanteringsgrupp och den lägsta är en Azure-resurs, till exempel ett Azure Maps-konto. Om du tilldelar en rolltilldelning till en resursgrupp kan du ge åtkomst till flera Azure Maps-konton eller resurser i gruppen.

Dricks

Microsofts allmänna rekommendation är att tilldela åtkomst till Azure Maps-kontoomfånget eftersom det förhindrar oavsiktlig åtkomst till andra Azure Maps-konton som finns i samma Azure-prenumeration.

Inaktivera lokal autentisering

Azure Maps-konton stöder azure-standardegenskapen i hanterings-API:et för Microsoft.Maps/accounts namnet disableLocalAuth. När trueinaktiveras all autentisering till Rest-API:et för Azure Maps-dataplanet, förutom Microsoft Entra-autentisering. Detta konfigureras med Azure Policy för att styra distribution och hantering av delade nycklar och SAS-token. Mer information finns i Vad är Azure Policy?.

Inaktivering av lokal autentisering börjar inte gälla omedelbart. Tillåt några minuter för tjänsten att blockera framtida autentiseringsbegäranden. Om du vill återaktivera lokal autentisering anger du egenskapen till false och efter några minuter att den lokala autentiseringen återupptas.

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

Tokenautentisering för signatur för delad åtkomst

SAS-token (Signatur för delad åtkomst) är autentiseringstoken som skapats med JSON-webbtokenformatet (JWT) och är kryptografiskt signerade för att bevisa autentisering för ett program till Azure Maps REST API. En SAS-token som skapats genom att integrera en användartilldelad hanterad identitet med ett Azure Maps-konto i din Azure-prenumeration. Den användartilldelade hanterade identiteten ges auktorisering till Azure Maps-kontot via Azure RBAC med hjälp av antingen inbyggda eller anpassade rolldefinitioner.

Funktionella viktiga skillnader i SAS-token från Microsoft Entra-åtkomsttoken:

Livslängd för en token för en maximal förfallotid på en dag (24 timmar).
Åtkomstkontroll för Azure-plats och geografi per token.
Frekvensgränser per token för cirka 1 till 500 begäranden per sekund.
Privata nycklar för token är de primära och sekundära nycklarna för en Azure Maps-kontoresurs.
Objektet Tjänstens huvudnamn för auktorisering tillhandahålls av en användartilldelad hanterad identitet.

SAS-token är oföränderliga. Det innebär att när en token har skapats är SAS-token giltig tills förfallotiden har uppfyllts och konfigurationen av de tillåtna regionerna, hastighetsbegränsningarna och den användartilldelade hanterade identiteten kan inte ändras. Läs mer nedan om att förstå åtkomstkontroll för SAS-tokenåterkallning och ändringar i åtkomstkontroll.

Förstå hastighetsbegränsningar för SAS-token

Högsta hastighetsgräns för SAS-token kan styra faktureringen för en Azure Maps-resurs

När du anger en maximal hastighetsgräns för token (maxRatePerSecond) debiteras inte överskjutande priser till kontot så att du kan ange en övre gräns för fakturerbara transaktioner för kontot när du använder token. Programmet får dock klientfelsvar med 429 (TooManyRequests) för alla transaktioner när den gränsen har nåtts. Det är programmets ansvar att hantera återförsök och distribution av SAS-token. Det finns ingen gräns för hur många SAS-token som kan skapas för ett konto. För att tillåta en ökning eller minskning av en befintlig tokens gräns; en ny SAS-token måste skapas. Den gamla SAS-token är fortfarande giltig tills den upphör att gälla.

Uppskattat exempel:

Ungefärlig högsta hastighet per sekund	Faktisk ränta per sekund	Varaktighet för ihållande hastighet i sekunder	Totalt antal fakturerbara transaktioner
10	20	600	6 000

Faktiska hastighetsgränser varierar beroende på Azure Maps förmåga att framtvinga konsekvens inom en tidsperiod. Detta möjliggör dock förebyggande kontroll av faktureringskostnader.

Hastighetsgränser tillämpas per Azure-plats, inte globalt eller geografiskt

Till exempel kan en enskild SAS-token med värdet maxRatePerSecond 10 användas för att begränsa dataflödet på East US platsen. Om samma token används i West US 2skapas en ny räknare för att begränsa dataflödet till 10 på den East US platsen, oberoende av platsen. Vi rekommenderar att du kontrollerar kostnaderna och förbättrar förutsägbarheten:

Skapa SAS-token med angivna tillåtna Azure-platser för målgeografi. Fortsätt läsa för att förstå hur du skapar SAS-token.
Använd rest-API-slutpunkter för geografiskt dataplan, https://us.atlas.microsoft.com eller https://eu.atlas.microsoft.com.

Överväg programtopologin där slutpunkten https://us.atlas.microsoft.com dirigeras till samma platser i USA som Azure Maps-tjänsterna finns på, till exempel East US, West Central USeller West US 2. Samma idé gäller för andra geografiska slutpunkter som https://eu.atlas.microsoft.com mellan West Europe och North Europe. Om du vill förhindra oväntade auktoriseringsnekanden använder du en SAS-token som använder samma Azure-platser som programmet använder. Slutpunktsplatsen definieras med hjälp av REST-API:et för Azure Maps Management.

Standardfrekvensgränser tar prejudikat över SAS-tokenhastighetsgränser

Enligt beskrivningen i Prisbegränsningar för Azure Maps har enskilda tjänsterbjudanden varierande hastighetsgränser som tillämpas som en aggregering av kontot.

Tänk på fallet med tjänsten Search – Omvänd från batch med en gräns på 250 frågor per sekund (QPS) för följande tabeller. Varje tabell representerar uppskattad total lyckad transaktion från exempelanvändning.

Den första tabellen visar en token som har en maximal begäran per sekund på 500, och den faktiska användningen av programmet är 500 begäranden per sekund under 60 sekunder. tjänsten Search – Omvänd icke-batch har en hastighetsgräns på 250, vilket innebär att de totalt 30 000 begäranden som görs under 60 sekunder. 15 000 av dessa begäranden är fakturerbara transaktioner. Återstående begäranden resulterar i statuskod 429 (TooManyRequests).

Name	Ungefärlig högsta hastighet per sekund	Faktisk ränta per sekund	Varaktighet för ihållande hastighet i sekunder	Ungefärliga totala lyckade transaktioner
token	500	500	60	~15 000

Om till exempel två SAS-token skapas i och använder samma plats som ett Azure Maps-konto, delar varje token nu standardhastighetsgränsen på 250 QPS. Om varje token används samtidigt med samma dataflödestoken 1 och token 2 skulle bevilja 7500 lyckade transaktioner vardera.

Name	Ungefärlig högsta hastighet per sekund	Faktisk ränta per sekund	Varaktighet för ihållande hastighet i sekunder	Ungefärliga totala lyckade transaktioner
token 1	250	250	60	~7500
token 2	250	250	60	~7500

Förstå åtkomstkontroll för SAS-token

SAS-token använder RBAC för att styra åtkomsten till REST-API:et. När du skapar en SAS-token tilldelas den nödvändiga hanterade identiteten på kartkontot en Azure RBAC-roll som ger åtkomst till specifika REST API-åtgärder. Se Välja en rolldefinition för att avgöra vilka API:er programmet tillåter.

Om du vill tilldela tillfällig åtkomst och ta bort åtkomst för innan SAS-token upphör att gälla återkallar du token. Andra orsaker till att återkalla åtkomst kan vara om token distribueras oavsiktligt med Azure Maps Data Contributor rolltilldelning och alla med SAS-token kan läsa och skriva data till Rest-API:er för Azure Maps som kan exponera känsliga data eller oväntade ekonomiska kostnader från användningen.

det finns två alternativ för att återkalla åtkomst för SAS-token:er:

Återskapa nyckeln som användes av SAS-token eller secondaryKey för kartkontot.
Ta bort rolltilldelningen för den hanterade identiteten på det associerade kartkontot.

Varning

Om du tar bort en hanterad identitet som används av en SAS-token eller återkallar åtkomstkontrollen för den hanterade identiteten kan instanser av ditt program med hjälp av SAS-token och hanterad identitet avsiktligt returnera 401 Unauthorized eller 403 Forbidden från Rest-API:er för Azure Maps som skapar programavbrott.

Så här undviker du avbrott:

Lägg till en andra hanterad identitet i kartkontot och ge den nya hanterade identiteten rätt rolltilldelning.
Skapa en SAS-token med , secondaryKeyeller en annan hanterad identitet än den tidigare, som signingKey och distribuera den nya SAS-token till programmet.
Återskapa primärnyckeln, ta bort den hanterade identiteten från kontot och ta bort rolltilldelningen för den hanterade identiteten.

Skapa SAS-token

Om du vill skapa SAS-token måste du ha Contributor rollåtkomst för att både hantera Azure Maps-konton och användartilldelade identiteter i Azure-prenumerationen.

Viktigt!

Befintliga Azure Maps-konton som skapats på Azure-platsen global stöder inte hanterade identiteter.

Först bör du skapa en användartilldelad hanterad identitet på samma plats som Azure Maps-kontot.

Dricks

Du bör använda samma plats för både den hanterade identiteten och Azure Maps-kontot.

När en hanterad identitet har skapats kan du skapa eller uppdatera Azure Maps-kontot och bifoga det. Mer information finns i Hantera ditt Azure Maps-konto.

När kontot har skapats eller uppdaterats med den hanterade identiteten. tilldela rollbaserad åtkomstkontroll för den hanterade identiteten till en Azure Maps-dataroll i kontoomfånget. På så sätt kan den hanterade identiteten ges åtkomst till Azure Maps REST API för ditt kartkonto.

Skapa sedan en SAS-token med hjälp av Azure Management SDK-verktyget, list-SAS-åtgärden i KONTOhanterings-API:et eller sidan Azure Portal signatur för delad åtkomst för map-kontoresursen.

SAS-tokenparametrar:

Parameternamn	Exempelvärde	beskrivning
signingKey	`primaryKey`	Obligatoriskt används stränguppräkningsvärdet för signingKey antingen `primaryKeysecondaryKey` eller hanterad identitet för att skapa signaturen för SAS.
principalId	`<GUID>`	Krävs, principalId är objekt-ID (huvudnamn) för den användartilldelade hanterade identiteten som är kopplad till kartkontot.
regioner	`[ "eastus", "westus2", "westcentralus" ]`	Valfritt är `null`standardvärdet . Regionerna styr vilka regioner SAS-token kan användas i AZURE Maps REST-dataplans-API :et . Om du utelämnar regionsparametern kan SAS-token användas utan några begränsningar. När det används i kombination med en geografisk slutpunkt för Azure Maps-dataplan som `us.atlas.microsoft.com` och `eu.atlas.microsoft.com` gör att programmet kan styra användningen inom det angivna geografiska området. Detta gör det möjligt att förhindra användning i andra geografiska områden.
maxRatePerSecond	500	Obligatoriskt, den angivna ungefärliga maximala begäran per sekund som SAS-token beviljas. När gränsen har nåtts begränsas mer dataflöde med HTTP-statuskoden `429 (TooManyRequests)`.
start	`2021-05-24T10:42:03.1567373Z`	Obligatoriskt, ett UTC-datum som anger datum och tid då token blir aktiv.
expiry	`2021-05-24T11:42:03.1567373Z`	Obligatoriskt, ett UTC-datum som anger datum och tid då token upphör att gälla. Varaktigheten mellan start och förfallotid får inte vara längre än 24 timmar.

Konfigurera program med SAS-token

När programmet har fått en SAS-token skickar Azure Maps SDK och/eller program en HTTPS-begäran med följande nödvändiga HTTP-huvud utöver andra REST API HTTP-huvuden:

Rubriknamn	Värde
Auktorisering	jwt-sas eyJ0e....HNIVN

Kommentar

jwt-sas är autentiseringsschemat som ska anges med hjälp av SAS-token. Inkludera inte x-ms-client-id eller andra auktoriseringshuvuden eller subscription-key frågesträngsparameter.

CORS är ett HTTP-protokoll som gör att ett webbprogram som körs under en domän kan komma åt resurser i en annan domän. Webbläsare implementerar en säkerhetsbegränsning som kallas samma ursprungsprincip som förhindrar att en webbsida anropar API:er i en annan domän. CORS är ett säkert sätt att tillåta att en domän (ursprungsdomänen) anropar API:er i en annan domän. Med hjälp av Azure Maps-kontoresursen kan du konfigurera vilka ursprung som tillåts komma åt Rest-API:et för Azure Maps från dina program.

Viktigt!

CORS är inte en auktoriseringsmekanism. Alla begäranden som görs till ett kartkonto med hjälp av REST API, när CORS är aktiverat, behöver också ett giltigt autentiseringsschema för kartkonton, till exempel delad nyckel, Microsoft Entra-ID eller SAS-token.

CORS stöds för alla prisnivåer för kartkonton, dataplansslutpunkter och platser.

Förutsättningar

För att förhindra körning av skadlig kod på klienten blockerar moderna webbläsare begäranden från webbprogram till resurser som körs i en separat domän.

Om du inte känner till CORS kan du läsa Resursdelning för korsande ursprung (CORS) och låter en Access-Control-Allow-Origin rubrik deklarera vilka ursprung som tillåts anropa slutpunkter för ett Azure Maps-konto. CORS-protokollet är inte specifikt för Azure Maps.

CORS-begäranden

En CORS-begäran från en ursprungsdomän kan bestå av två separata begäranden:

En preflight-begäran som frågar cors-begränsningarna som införts av tjänsten. Förhandsbegäran krävs om inte begäran är standardmetoden GET, HEAD, POST eller begäranden som innehåller Authorization begärandehuvudet.
Den faktiska begäran som görs mot den önskade resursen.

Preflight-begäran

Preflight-begäran görs inte bara som en säkerhetsåtgärd för att säkerställa att servern förstår metoden och huvudena som skickas i den faktiska begäran och att servern känner till och litar på källan till begäran, utan även frågar cors-begränsningarna som har upprättats för kartkontot. Webbläsaren (eller annan användaragent) skickar en OPTIONS-begäran som innehåller begärandehuvuden, metod och ursprungsdomän. Kartkontotjänsten försöker hämta eventuella CORS-regler om kontoautentisering är möjligt via CORS-protokollet preflight.

Om autentisering inte är möjligt utvärderar maps-tjänsten en förkonfigurerad uppsättning CORS-regler som anger vilka ursprungsdomäner, begärandemetoder och begärandehuvuden som kan anges för en faktisk begäran mot maps-tjänsten. Som standard konfigureras ett maps-konto så att alla ursprung möjliggör sömlös integrering i webbläsare.

Tjänsten svarar på preflight-begäran med de nödvändiga åtkomstkontrollrubrikerna om följande villkor uppfylls:

OPTIONS-begäran innehåller nödvändiga CORS-huvuden (rubrikerna Origin och Access-Control-Request-Method)
Autentiseringen lyckades och en CORS-regel är aktiverad för det konto som matchar förhandsbegäran.
Autentiseringen hoppades över på grund av nödvändiga Authorization begärandehuvuden som inte kan anges för förhandsbegäran.

När preflight-begäran lyckas svarar tjänsten med statuskoden 200 (OK)och innehåller de nödvändiga åtkomstkontrollrubrikerna i svaret.

Tjänsten avvisar preflight-begäranden om följande villkor inträffar:

Om OPTIONS-begäran inte innehåller nödvändiga CORS-huvuden (rubrikerna Origin och Access-Control-Request-Method) svarar tjänsten med statuskoden 400 (Bad request).
Om autentiseringen lyckades på begäran före start och ingen CORS-regel matchar förbegäran svarar tjänsten med statuskoden 403 (Forbidden). Detta kan inträffa om CORS-regeln är konfigurerad för att acceptera ett ursprung som inte matchar den aktuella webbläsarklientens begäranderubrik.

Kommentar

En förhandsbegäran utvärderas mot tjänsten och inte mot den begärda resursen. Kontoägaren måste ha aktiverat CORS genom att ange lämpliga kontoegenskaper för att begäran ska lyckas.

Faktisk begäran

När förhandsbegäran har godkänts och svaret returneras skickar webbläsaren den faktiska begäran mot karttjänsten. Webbläsaren nekar den faktiska begäran omedelbart om preflight-begäran avvisas.

Den faktiska begäran behandlas som en vanlig begäran mot karttjänsten. Förekomsten av Origin huvudet anger att begäran är en CORS-begäran och att tjänsten sedan validerar mot CORS-reglerna. Om en matchning hittas läggs åtkomstkontrollhuvudena till i svaret och skickas tillbaka till klienten. Om en matchning inte hittas returnerar svaret ett 403 (Forbidden) som anger ett CORS-ursprungsfel.

Aktivera CORS-princip

När ett kartkonto skapas eller uppdateras anger dess egenskaper vilka tillåtna ursprung som ska konfigureras. Du kan ange en CORS-regel för Azure Maps-kontoegenskaper via Azure Maps Management SDK, Azure Maps Management REST API och portalen. När du har angett CORS-regeln för tjänsten utvärderas en korrekt auktoriserad begäran som görs till tjänsten från en annan domän för att avgöra om den tillåts enligt den regel som du har angett. Till exempel:

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

Endast en CORS-regel med sin lista över tillåtna ursprung kan anges. Varje ursprung gör att HTTP-begäran kan göras till Azure Maps REST API i webbläsaren för det angivna ursprunget.

Ta bort CORS-princip

Du kan ta bort CORS:

Manuellt i Azure Portal
Programmatiskt med hjälp av:
- The Azure Maps SDK
- REST API för Azure Maps-hantering
- En ARM-mall

Dricks

Om du använder REST API:et för Azure Maps-hantering kan du använda PUT eller PATCH med en tom corsRule lista i begärandetexten.

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

Förstå faktureringstransaktioner

Azure Maps räknar inte faktureringstransaktioner för:

5xx HTTP-statuskoder
401 (behörighet saknas)
403 (Förbjudet)
408 (tidsgräns)
429 (TooManyRequests)
CORS-förhandsbegäranden

Mer information om faktureringstransaktioner och annan prisinformation för Azure Maps finns i Priser för Azure Maps.

Nästa steg

Mer information om metodtips för säkerhet finns i:

Metodtips för autentisering och auktorisering

Mer information om hur du autentiserar ett program med Microsoft Entra-ID och Azure Maps finns i:

Hantera autentisering i Azure Maps

Mer information om hur du autentiserar Azure Maps Control med Microsoft Entra-ID finns i:

Använda kartkontrollen i Azure Maps

Dela via

Autentisering med Azure Maps

Autentisering med delad nyckel

Microsoft Entra-autentisering

Hanterade identiteter för Azure-resurser och Azure Maps

Konfigurera Microsoft Entra-autentisering för program

Auktorisering med rollbaserad åtkomstkontroll

Förutsättningar

Översikt

Välja en rolldefinition

Anpassade rolldefinitioner

Förstå omfång

Inaktivera lokal autentisering

Tokenautentisering för signatur för delad åtkomst

Förstå hastighetsbegränsningar för SAS-token

Högsta hastighetsgräns för SAS-token kan styra faktureringen för en Azure Maps-resurs

Hastighetsgränser tillämpas per Azure-plats, inte globalt eller geografiskt

Standardfrekvensgränser tar prejudikat över SAS-tokenhastighetsgränser

Förstå åtkomstkontroll för SAS-token

Skapa SAS-token

Konfigurera program med SAS-token

Förutsättningar

CORS-begäranden

Preflight-begäran

Faktisk begäran

Aktivera CORS-princip

Ta bort CORS-princip

Förstå faktureringstransaktioner

Nästa steg

Feedback

Ytterligare resurser

Dela via

Autentisering med Azure Maps

Autentisering med delad nyckel

Microsoft Entra-autentisering

Hanterade identiteter för Azure-resurser och Azure Maps

Konfigurera Microsoft Entra-autentisering för program

Auktorisering med rollbaserad åtkomstkontroll

Förutsättningar

Översikt

Välja en rolldefinition

Anpassade rolldefinitioner

Förstå omfång

Inaktivera lokal autentisering

Tokenautentisering för signatur för delad åtkomst

Förstå hastighetsbegränsningar för SAS-token

Högsta hastighetsgräns för SAS-token kan styra faktureringen för en Azure Maps-resurs

Hastighetsgränser tillämpas per Azure-plats, inte globalt eller geografiskt

Standardfrekvensgränser tar prejudikat över SAS-tokenhastighetsgränser

Förstå åtkomstkontroll för SAS-token

Skapa SAS-token

Konfigurera program med SAS-token

Resursdelning mellan ursprung (CORS)

Förutsättningar

CORS-begäranden

Preflight-begäran

Faktisk begäran

Aktivera CORS-princip

Ta bort CORS-princip

Förstå faktureringstransaktioner

Nästa steg

Feedback

Ytterligare resurser