Ověřování s využitím Azure Maps

Azure Maps podporuje tři metody ověřování: sdílený klíč, ID Microsoft Entra a token sdíleného přístupového podpisu (SAS). Tento článek vysvětluje tyto metody ověřování, včetně podrobností o ovládacích prvcích účtu, jako je zakázání místního ověřování pro Azure Policy a sdílení prostředků mezi zdroji (CORS).

Poznámka:

Kvůli zlepšení zabezpečené komunikace s Azure Maps teď podporujeme protokol TLS (Transport Layer Security) 1.2 a vyřazujeme podporu protokolu TLS 1.0 a 1.1. Pokud aktuálně používáte protokol TLS 1.x, vyhodnoťte připravenost protokolu TLS 1.2 a vytvořte plán migrace s testováním popsaným při řešení problému s protokolem TLS 1.0.

Ověřování pomocí sdíleného klíče

Informace o zobrazení klíčů na webu Azure Portal najdete v tématu Zobrazení podrobností o ověřování.

Při vytváření účtu Azure Maps se automaticky generují primární a sekundární klíče. Doporučujeme použít primární klíč jako klíč předplatného při volání Služby Azure Maps se sdíleným klíčem. Ověřování pomocí sdíleného klíče předává klíč vygenerovaný účtem Azure Maps do služby Azure Maps. Pro každou žádost o služby Azure Maps přidejte klíč předplatného jako parametr do adresy URL. Sekundární klíč je možné použít ve scénářích, jako jsou změny postupného klíče.

Příklad použití klíče předplatného jako parametru v adrese 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

Důležité

Primární a sekundární klíče by se měly považovat za citlivá data. Sdílený klíč slouží k ověření všech rozhraní REST API služby Azure Maps. Uživatelé, kteří používají sdílený klíč, by měli klíč rozhraní API abstraktovat, a to buď prostřednictvím proměnných prostředí, nebo zabezpečeného úložiště tajných kódů, kde je možné ho centrálně spravovat.

Ověřování Microsoft Entra

Předplatná Azure jsou k dispozici s tenantem Microsoft Entra, aby bylo možné jemně odstupňované řízení přístupu. Azure Maps nabízí ověřování pro služby Azure Maps pomocí ID Microsoft Entra. Id Microsoft Entra poskytuje ověřování na základě identity pro uživatele a aplikace zaregistrované v tenantovi Microsoft Entra.

Azure Maps přijímá přístupové tokeny OAuth 2.0 pro tenanty Microsoft Entra přidružené k předplatnému Azure, které obsahuje účet Azure Maps. Azure Maps také přijímá tokeny pro:

• Uživatelé Microsoft Entra
• Partnerské aplikace, které používají oprávnění delegovaná uživateli
• Spravované identity pro prostředky Azure

Azure Maps generuje jedinečný identifikátor (ID klienta) pro každý účet Azure Maps. Tokeny můžete vyžádat z ID Microsoft Entra, když toto ID klienta zkombinujete s dalšími parametry.

Další informace o konfiguraci ID Microsoft Entra a tokenů žádostí pro Azure Maps najdete v tématu Správa ověřování v Azure Maps.

Obecné informace o ověřování pomocí MICROSOFT Entra ID naleznete v tématu Ověřování vs. autorizace.

Spravované identity pro prostředky Azure a Azure Maps

Spravované identity pro prostředky Azure poskytují službám Azure automaticky spravovaný objekt zabezpečení založený na aplikacích, který se může ověřit pomocí ID Microsoft Entra. Pomocí řízení přístupu na základě role v Azure (Azure RBAC) je možné instanční objekt zabezpečení spravované identity autorizovat pro přístup ke službám Azure Maps. Mezi příklady spravovaných identit patří: Aplikace Azure Service, Azure Functions a Azure Virtual Machines. Seznam spravovaných identit najdete ve službách Azure, které můžou používat spravované identity pro přístup k jiným službám. Další informace o spravovaných identitách najdete v tématu Správa ověřování v Azure Maps.

Konfigurace ověřování Microsoft Entra v aplikaci

Aplikace se ověřují pomocí tenanta Microsoft Entra pomocí jednoho nebo více podporovaných scénářů poskytovaných ID Microsoft Entra. Každý scénář aplikace Microsoft Entra představuje různé požadavky na základě obchodních potřeb. Některé aplikace můžou vyžadovat přihlašování uživatelů a jiné aplikace můžou vyžadovat přihlašování k aplikaci. Další informace najdete v tématu Toky ověřování a scénáře aplikací.

Jakmile aplikace obdrží přístupový token, sada SDK a/nebo aplikace odešle požadavek HTTPS s následující sadou požadovaných hlaviček HTTP kromě dalších hlaviček HTTP rozhraní REST API:

Název záhlaví	Hodnota
x-ms-client-id	30d7cc... 9f55
Autorizace	Nosný eyJ0e... HNIVN

Poznámka:

x-ms-client-id je identifikátor GUID založený na účtu Azure Maps, který se zobrazí na stránce ověřování Azure Maps.

Tady je příklad požadavku azure Maps Route, který používá nosný token Microsoft Entra ID OAuth:

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

Informace o zobrazení ID klienta najdete v tématu Zobrazení podrobností o ověřování.

Návod

Programové získání ID klienta

Při použití PowerShellu se ID klienta uloží jako UniqueId vlastnost v objektu IMapsAccount . Tuto vlastnost načtete například takto Get-AzMapsAccount:

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

Při použití Azure CLI použijte az maps account show příkaz s parametrem --query , například:

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

Autorizace pomocí řízení přístupu na základě role

Požadavky

Pokud s Azure RBAC začínáte, poskytuje přehled řízení přístupu na základě role v Azure (Azure RBAC) sadu oprávnění, která se označuje také jako definice role. Definice role poskytuje oprávnění k akcím rozhraní REST API. Azure Maps podporuje přístup ke všem typům objektů zabezpečení pro řízení přístupu na základě role Azure (Azure RBAC), včetně jednotlivých uživatelů Microsoft Entra, skupin, aplikací, prostředků Azure a spravovaných identit Azure. Použití přístupu k jednomu nebo více účtům Azure Maps se označuje jako obor. Přiřazení role se vytvoří při použití objektu zabezpečení, definice role a oboru.

Přehled

V dalších částech najdete informace o konceptech a komponentách integrace Azure Maps s Azure RBAC. V rámci procesu nastavení účtu Azure Maps je adresář Microsoft Entra přidružený k předplatnému Azure, ve kterém se nachází účet Azure Maps.

Při konfiguraci Azure RBAC zvolíte objekt zabezpečení a použijete ho na přiřazení role. Informace o tom, jak přidat přiřazení rolí na webu Azure Portal, najdete v tématu Přiřazení rolí Azure pomocí webu Azure Portal.

Výběr definice role

Pro podporu scénářů aplikace existují následující typy definic rolí.

Definice role Azure	Popis
Azure Maps Search a vykreslovat čtečku dat	Poskytuje přístup pouze k vyhledávacím a vykreslovacím rozhraním REST API služby Azure Maps za účelem omezení přístupu k základním případům použití webového prohlížeče.
Čtečka dat Azure Maps	Poskytuje přístup k neměnným rozhraním REST API služby Azure Maps.
Přispěvatel dat Azure Maps	Poskytuje přístup k proměnlivé rozhraní REST API služby Azure Maps. Proměnlivost definovaná akcemi: zápis a odstranění
Role čtení dat a dávky dat Azure Maps	Tuto roli můžete použít k přiřazení akcí čtení a dávek ve službě Azure Maps.
Definice vlastní role	Vytvořte vytvořenou roli, která umožňuje flexibilní omezený přístup k rozhraním REST API služby Azure Maps.

Některé služby Azure Maps vyžadují zvýšená oprávnění k provádění akcí zápisu nebo odstranění v rozhraních REST API služby Azure Maps. Role Přispěvatel dat Azure Maps se vyžaduje pro služby, které poskytují akce zápisu nebo odstranění. Následující tabulka popisuje, které služby Azure Maps Data Contributor se vztahují při použití akcí zápisu nebo odstranění. Pokud jsou vyžadovány pouze akce čtení, je možné místo role Přispěvatel dat Azure Maps použít roli Čtenář dat Azure Maps.

Služba Azure Maps	Definice role Azure Maps
Dávkové vyhledávání a směrování	Přispěvatel dat Azure Maps

Informace o zobrazení nastavení Azure RBAC najdete v tématu Konfigurace Azure RBAC pro Azure Maps.

Vlastní definice rolí

Jedním z aspektů zabezpečení aplikací je princip nejnižších oprávnění, postup omezení přístupových práv na práva požadovaná pro aktuální úlohu. Omezení přístupových práv se provádí vytvořením vlastních definic rolí, které podporují případy použití vyžadující další členitost řízení přístupu. Pokud chcete vytvořit vlastní definici role, vyberte konkrétní akce dat, které se mají zahrnout nebo vyloučit pro definici.

Vlastní definici role je pak možné použít v přiřazení role pro libovolný objekt zabezpečení. Další informace o definicích vlastních rolí Azure najdete v tématu Vlastní role Azure.

Tady je několik ukázkových scénářů, ve kterých můžou vlastní role zlepšit zabezpečení aplikací.

Scénář	Akce vlastních dat role
Veřejná nebo interaktivní přihlašovací stránka s dlaždicemi základní mapy a žádnými dalšími rozhraními REST API	Microsoft.Maps/accounts/services/render/read
Aplikace, která vyžaduje pouze zpětné geokódování a žádná jiná rozhraní REST API.	Microsoft.Maps/accounts/services/search/read

Orientace v oborech

Přiřazení rolí se definují v hierarchii prostředků Azure, od skupiny pro správu nejvyšší úrovně až po nejnižší úroveň, jako je účet Azure Maps. Další informace najdete v tématu Co jsou skupiny pro správu Azure?

Přiřazením role ke skupině prostředků můžete udělit přístup k více účtům nebo prostředkům Azure Maps v této skupině.

Návod

Microsoft obecně doporučuje přiřazovat přístup v oboru účtu Azure Maps, aby se zabránilo neúmyslnému přístupu k jiným účtům Azure Maps ve stejném předplatném Azure.

Zakázání místního ověřování

Účty Azure Maps podporují standardní vlastnost Azure v rozhraní API pro správu Maps pro Microsoft.Maps/accounts volání disableLocalAuth. Pokud je pravda, veškeré ověřování pro rozhraní REST API roviny dat Azure Maps je zakázané, s výjimkou ověřování Microsoft Entra. To se konfiguruje pomocí Služby Azure Policy k řízení distribuce a správy sdílených klíčů a tokenů SAS. Další informace najdete v tématu Co je Azure Policy?.

Zakázání místního ověřování se neprojeví okamžitě. Počkejte několik minut, než služba zablokuje budoucí žádosti o ověření. Pokud chcete znovu povolit místní ověřování, nastavte vlastnost na false a po několika minutách se místní ověřování obnoví.

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

Ověřování tokenu sdíleného přístupového podpisu

Tokeny sdíleného přístupového podpisu (SAS), což jsou ověřovací tokeny ve formátu JSON Web Token (JWT), jsou kryptograficky podepsané k ověřování aplikací pomocí rozhraní REST API služby Azure Maps. Tyto tokeny se generují integrací spravované identity přiřazené uživatelem s účtem Azure Maps ve vašem předplatném Azure. Spravovaná identita má oprávnění pro přístup k účtu Azure Maps prostřednictvím Azure RBAC pomocí předdefinovaných nebo vlastních definic rolí.

Klíčové funkční rozdíly mezi tokeny SAS a přístupovými tokeny Microsoft Entra:

• Životnost tokenu pro maximální vypršení platnosti jednoho dne (24 hodin).
• Umístění Azure a geografické řízení přístupu na token
• Omezení rychlosti na token pro přibližně 1 až 500 požadavků za sekundu.
• Privátní klíče tokenu jsou primární a sekundární klíče prostředku účtu Azure Maps.
• Objekt instančního objektu pro autorizaci poskytuje spravovaná identita přiřazená uživatelem.

Tokeny SAS jsou neměnné. Po vytvoření zůstanou platné, dokud nevyprší jejich platnost, a jejich nastavení, jako jsou povolené oblasti, omezení rychlosti a spravovaná identita přiřazená uživatelem, se nedají změnit. Další informace o odvolání tokenu SAS a úpravách řízení přístupu najdete v tématu vysvětlení řízení přístupu.

Vysvětlení limitů rychlosti tokenů SAS

Maximální limit rychlosti tokenu SAS může řídit fakturaci prostředku Azure Maps.

Při nastavování maximálního limitu sazby u tokenu (maxRatePerSecond), žádné sazby, které tento limit překročí, se na účet neúčtují, což vám umožní omezit fakturovatelné transakce. Aplikace však obdrží chybu klienta 429 (TooManyRequests) jako odpověď na všechny transakce poté, co je limit dosažen. Za správu opakovaných pokusů a distribuci tokenů SAS zodpovídá aplikace. Počet tokenů SAS, které je možné vytvořit pro účet, neexistuje žádné omezení. Pokud chcete upravit limit existujícího tokenu, musí se vygenerovat nový token SAS. Starý token SAS zůstane platný, dokud nevyprší platnost.

Odhadovaný příklad:

Přibližná maximální sazba za sekundu	Skutečná sazba za sekundu	Doba trvání trvalé rychlosti v sekundách	Celkové fakturovatelné transakce
10	20	600	6 000

Skutečné limity rychlosti se liší v závislosti na schopnosti Azure Maps vynucovat konzistenci v rámci časového intervalu. To však umožňuje preventivní kontrolu fakturačních nákladů.

Omezení rychlosti se vynucují pro umístění Azure, ne globálně nebo geograficky.

Například jeden token SAS s maxRatePerSecond 10 je možné použít k omezení propustnosti v East US umístění. Pokud se použije West US 2stejný token, vytvoří se nový čítač, který omezí propustnost na 10 v daném umístění nezávisle na East US umístění. Návrhy pro řízení nákladů a zlepšení předvídatelnosti:

1. Vytvořte tokeny SAS s určenými povolenými umístěními Azure pro cílovou geografickou oblast.
2. Použijte koncové body https://us.atlas.microsoft.com rozhraní REST API roviny geografických dat nebo https://eu.atlas.microsoft.com.

Zvažte topologii aplikace, kde se koncový bod https://us.atlas.microsoft.com směruje do stejných umístění v USA, kde jsou hostované služby Azure Maps, například East US, West Central USnebo West US 2. Stejná myšlenka se vztahuje na jiné geografické koncové body, jako https://eu.atlas.microsoft.com jsou mezi West Europe a North Europe. Pokud chcete zabránit neočekávaným odepření autorizace, použijte token SAS, který používá stejná umístění Azure, která aplikace využívá. Umístění koncového bodu se definuje pomocí rozhraní REST API služby Azure Maps Management.

Výchozí limity sazeb přebírají předchůdci nad limity rychlosti tokenů SAS

Jak je popsáno v limitech rychlosti QPS služby Azure Maps, omezení rychlosti jednotlivých nabídek služeb se souhrnně vynucují na úrovni účtu.

Podívejte se na případ služby vyhledávání – reverzní vyhledávání jednotlivého dotazu s limitem (QPS) 250 dotazů za sekundu pro následující tabulky. Každá tabulka představuje odhadovaný celkový počet úspěšných transakcí z ukázkového využití.

První tabulka ukazuje jeden token, který má maximální požadavek za sekundu 500 a skutečné využití aplikace je 500 požadavků za sekundu po dobu 60 sekund. Vyhledávací služba – reverzní jeden požadavek má limit rychlosti 250, což znamená celkový počet 30 000 požadavků provedených za 60 sekund; 15 000 těchto požadavků jsou fakturovatelné transakce. Zbývající požadavky mají za následek stavový kód 429 (TooManyRequests).

Název	Přibližná maximální sazba za sekundu	Skutečná sazba za sekundu	Doba trvání trvalé rychlosti v sekundách	Přibližná celková úspěšná transakce
token	500	500	60	~15 000

Pokud jsou například vytvořeny dva tokeny SAS a používají stejné umístění jako účet Azure Maps, každý token sdílí výchozí limit rychlosti 250 QPS. Pokud se oba tokeny používají současně se stejnou propustností, každý token by uděloval 7 500 úspěšných transakcí.

Název	Přibližná maximální sazba za sekundu	Skutečná sazba za sekundu	Doba trvání trvalé rychlosti v sekundách	Přibližná celková úspěšná transakce
token 1	250	250	60	~7500
značka 2	250	250	60	~7500

Principy řízení přístupu tokenu SAS

Tokeny SAS používají RBAC k řízení přístupu k rozhraní REST API. Při vytváření tokenu SAS se požadované spravované identitě na mapovém účtu přiřadí role Azure RBAC, která uděluje přístup ke konkrétním akcím rozhraní REST API. Informace o tom, která rozhraní API aplikace umožňuje, najdete v tématu Výběr definice role.

Pokud chcete přiřadit dočasný přístup a odebrat ho před vypršením platnosti tokenu SAS, odvolejte token. Dalším důvodem odvolání přístupu je, že se token nechtěně distribuoval s rolí Přispěvatel dat Azure Maps, která může povolit neoprávněné čtení a zápis dat v rozhraních REST API služby Azure Maps, což vede k ohrožení citlivých dat nebo neočekávaným nákladům.

Přístup pro tokeny SAS můžete odvolat dvěma způsoby:

1. Znovu vygenerujte klíč používaný tokenem SAS nebo sekundárním klíčem účtu mapy.
2. Odeberte přiřazení role pro spravovanou identitu v přidruženém účtu mapování.

Upozorňující

Odstranění spravované identity používané tokenem SAS nebo odvoláním řízení přístupu spravované identity může vést k tomu, že instance vaší aplikace používají token SAS a spravovanou identitu k vrácení 401 Unauthorized nebo 403 Forbidden z rozhraní REST API služby Azure Maps, což vede k potenciálnímu přerušení aplikace.

Abyste se vyhnuli přerušení:

1. Přidejte do účtu mapy druhou spravovanou identitu a udělte nové spravované identitě správné přiřazení role.
2. Vytvořte token SAS pomocí secondaryKeynebo jiné spravované identity než předchozí, jako signingKey a distribuujte do aplikace nový token SAS.
3. Znovu vygenerujte primární klíč, odeberte spravovanou identitu z účtu a odeberte přiřazení role pro spravovanou identitu.

Vytvoření tokenů SAS

Pokud chcete vytvořit tokeny SAS, musíte mít Contributor přístup role ke správě účtů Azure Maps i identit přiřazených uživatelem v předplatném Azure.

Důležité

Existující účty Azure Maps vytvořené v umístění global Azure nepodporují spravované identity.

Nejprve byste měli vytvořit spravovanou identitu přiřazenou uživatelem ve stejném umístění jako účet Azure Maps.

Návod

Pro spravovanou identitu i účet Azure Maps byste měli použít stejné umístění.

Po vytvoření spravované identity můžete vytvořit nebo aktualizovat účet Azure Maps a připojit ji. Další informace najdete v tématu Správa účtu Azure Maps.

Po úspěšném vytvoření nebo aktualizaci účtu spravovanou identitou; přiřaďte řízení přístupu na základě role pro spravovanou identitu k roli dat Azure Maps v oboru účtu. To umožňuje, aby spravovaná identita byla udělena přístup k rozhraní REST API služby Azure Maps pro váš účet mapy.

Dále vytvořte token SAS pomocí nástrojů sady Sdk pro správu Azure, operace Výpis SAS v rozhraní API pro správu účtů nebo stránky sdíleného přístupového podpisu webu Azure Portal prostředku účtu mapování.

Parametry tokenu SAS:

Název parametru	Příklad hodnoty	Popis
podpisový klíč	primaryKey	Povinný argument, hodnota výčtu řetězce pro podpisKey buď primaryKeysecondaryKey nebo spravovaná identita se používá k vytvoření podpisu SAS.
hlavníId	<GUID>	Vyžaduje se, že principalId je ID objektu (objektu zabezpečení) spravované identity přiřazené uživatelem připojené k účtu mapování.
oblasti	[ "eastus", "westus2", "westcentralus" ]	Volitelné, výchozí hodnota je null. Oblasti řídí oblasti, ve kterých se dá token SAS použít v rozhraní REST API služby Azure Maps. Vynechání parametru oblastí umožňuje použití tokenu SAS bez jakýchkoli omezení. Pokud se používá v kombinaci se zeměpisným koncovým bodem roviny dat Azure Maps, jako us.atlas.microsoft.com je eu.atlas.microsoft.com například a umožňuje aplikaci řídit využití v zadané geografické oblasti. To umožňuje prevenci použití v jiných zeměpisných oblastech.
maximální rychlost za sekundu	500	Vyžaduje se zadaný přibližný maximální požadavek za sekundu, který má token SAS udělený. Po dosažení limitu je vyšší propustnost omezena stavovým kódem 429 (TooManyRequests)HTTP .
začátek	2021-05-24T10:42:03.1567373Z	Povinné je datum UTC, které určuje datum a čas, kdy se token aktivuje.
vypršení	2021-05-24T11:42:03.1567373Z	Povinné je datum UTC, které určuje datum a čas vypršení platnosti tokenu. Doba trvání mezi začátkem a vypršením platnosti nesmí být delší než 24 hodin.

Konfigurace aplikace pomocí tokenu SAS

Jakmile aplikace obdrží token SAS, sada Azure Maps SDK nebo aplikace odešlou požadavek HTTPS s následující povinnou hlavičkou HTTP kromě dalších hlaviček HTTP rozhraní REST API:

Název záhlaví	Hodnota
Autorizace	jwt-sas eyJ0e....HNIVN

Poznámka:

jwt-sas je schéma ověřování, které označuje pomocí tokenu SAS. Nezahrnujte ani nezahrnujte x-ms-client-id jiné autorizační hlavičky ani subscription-key parametr řetězce dotazu.

Sdílení prostředků mezi zdroji (CORS)

CORS je protokol HTTP, který umožňuje webové aplikaci spuštěné v jedné doméně přistupovat k prostředkům v jiné doméně. Webové prohlížeče implementují omezení zabezpečení známé jako zásady stejného původu, které brání webové stránce v volání rozhraní API v jiné doméně; CORS poskytuje bezpečný způsob, jak povolit, aby jedna doména (původní doména) volala rozhraní API v jiné doméně. Pomocí prostředku účtu Azure Maps můžete nakonfigurovat, které zdroje mají povolený přístup k rozhraní REST API služby Azure Maps z vašich aplikací.

Důležité

CORS není autorizační mechanismus. Požadavky na účet mapování pomocí rozhraní REST API, pokud je povolené CORS, potřebuje také platné schéma ověřování účtu mapování, jako je sdílený klíč, ID Microsoft Entra nebo token SAS.

CORS se podporuje pro všechny cenové úrovně mapových účtů, koncové body roviny dat a umístění.

Požadavky

Aby se zabránilo spuštění škodlivého kódu na klientovi, moderní prohlížeče blokují požadavky z webových aplikací na prostředky spuštěné v samostatné doméně.

• Pokud cors neznáte, přečtěte si téma Sdílení prostředků mezi zdroji (CORS), umožňuje hlavičku Access-Control-Allow-Origin deklarovat, které zdroje můžou volat koncové body účtu Azure Maps. Protokol CORS není specifický pro Azure Maps.

Požadavky CORS

Žádost CORS z původní domény se může skládat ze dvou samostatných požadavků:

• Předběžný požadavek, který se dotazuje omezení CORS, která služba uložila. Předběžný požadavek se vyžaduje, pokud se nejedná o standardní metodu GET, HEAD, POST nebo požadavky, které obsahují Authorization hlavičku požadavku.

• Skutečný požadavek provedený proti požadovanému prostředku.

Předběžný požadavek

Předběžný požadavek je bezpečnostní opatření, ale také zajišťuje, že server rozumí metodě a hlaviček odesílaných ve skutečném požadavku, ověřuje zdroj požadavku a dotazuje se na omezení CORS stanovená pro účet mapy. Webový prohlížeč (nebo jiný uživatelský agent) odešle požadavek OPTIONS, který obsahuje hlavičky požadavku, metodu a původní doménu. Služba mapového účtu se pokusí načíst všechna pravidla CORS, pokud je ověřování účtu možné prostřednictvím předběžného protokolu CORS.

Pokud ověřování není možné, služba Maps vyhodnocuje předem nakonfigurovanou sadu pravidel CORS, která určují, které domény původu, metody požadavků a hlavičky požadavků mohou být zadány na skutečném požadavku vůči službě Maps. Ve výchozím nastavení je účet maps nakonfigurovaný tak, aby umožňoval bezproblémovou integraci do webových prohlížečů.

Služba odpoví na předběžný požadavek s požadovanými hlavičkami řízení přístupu, pokud jsou splněna následující kritéria:

1. Požadavek OPTIONS obsahuje požadovaná hlavička CORS (hlavičky Origin a Access-Control-Request-Method).
2. Ověření proběhlo úspěšně a pro účet, který odpovídá předběžné žádosti, je povolené pravidlo CORS.
3. Ověřování se přeskočilo kvůli požadovaným Authorization hlavičkám požadavků, které není možné zadat v předběžném požadavku.

Když je předběžný požadavek úspěšný, služba odpoví stavovým kódem 200 (OK)a do odpovědi zahrne požadované hlavičky řízení přístupu.

Služba odmítne předběžné požadavky, pokud dojde k následujícím podmínkám:

1. Pokud požadavek OPTIONS neobsahuje požadovaná hlavička CORS (hlavičky Origin a Access-Control-Request-Method), služba odpoví stavovým kódem 400 (Bad request).
2. Pokud bylo ověření při předběžné žádosti úspěšné a žádné pravidlo CORS neodpovídá předběžnému požadavku, služba odpoví stavovým kódem 403 (Forbidden). K tomu může dojít, pokud je pravidlo CORS nakonfigurované tak, aby přijímalo zdroj, který neodpovídá aktuální hlavičce žádosti o původ klienta prohlížeče.

Poznámka:

Předběžný požadavek se vyhodnocuje vůči službě, nikoli vůči požadovanému prostředku. Vlastník účtu musí povolit CORS nastavením odpovídajících vlastností účtu, aby žádost mohla proběhnout úspěšně.

Skutečný požadavek

Jakmile se předběžný požadavek přijme a odpověď se vrátí, prohlížeč odešle skutečný požadavek do mapové služby. Prohlížeč okamžitě odmítne skutečnou žádost, pokud se předběžný požadavek odmítne.

Skutečný požadavek se považuje za normální požadavek vůči mapové službě. Origin Přítomnost hlavičky označuje, že požadavek je žádost CORS a služba pak ověří pravidla CORS. Pokud se najde shoda, hlavičky Řízení přístupu se přidají do odpovědi a odešlou se zpět klientovi. Pokud se shoda nenajde, vrátí 403 (Forbidden) odpověď indikující chybu původu CORS.

Povolení zásad CORS

Při vytvoření nebo aktualizaci účtu mapy definují jeho vlastnosti povolené zdroje. Pravidlo CORS je možné nastavit ve vlastnostech účtu Azure Maps prostřednictvím sady Azure Maps Management SDK, rozhraní REST API pro správu Azure Maps a portálu. Po nastavení pravidla CORS pro službu se vyhodnocují autorizované žádosti z různých domén, aby se zajistilo dodržování zadaného pravidla. Příklad:

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

Lze zadat pouze jedno pravidlo CORS se seznamem povolených zdrojů. Každý zdroj umožňuje provést požadavek HTTP do rozhraní REST API služby Azure Maps ve webovém prohlížeči zadaného původu.

Odebrání zásad CORS

CORS můžete odebrat:

• Ruční na webu Azure Portal
• Programově pomocí:
  • Sada Azure Maps SDK
  • Rozhraní REST API pro správu služby Azure Maps
  • Šablona ARM

Návod

Pokud používáte rozhraní REST API pro správu Služby Azure Maps, použijte PUT nebo PATCH použijte prázdný corsRule seznam v textu požadavku.

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

Vysvětlení fakturačních transakcí

Azure Maps nepočítá fakturační transakce pro:

• Stavové kódy HTTP 5xx
• 401 (Neautorizováno)
• 403 (zakázáno)
• 408 (časový limit)
• 429 (Příliš mnoho požadavků)
• Předběžné požadavky CORS

Další informace o fakturačních transakcích a dalších cenách Azure Maps najdete v tématu Ceny služby Azure Maps.

Další kroky

Další informace oosvědčených

Osvědčené postupy ověřování a autorizace

Další informace o ověřování aplikace pomocí Microsoft Entra ID a Azure Maps najdete tady:

Správa ověřování v Azure Maps

Další informace o ověřování ovládacího prvku Azure Maps pomocí ID Microsoft Entra najdete tady:

Použití ovládacího prvku Mapy Azure Maps