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

Článek
10/18/2023

Azure Mapy podporuje tři způsoby ověřování požadavků: ověřování pomocí sdíleného klíče, ověřování POMOCÍ ID Microsoftu a ověřování tokenu sdíleného přístupového podpisu (SAS). Tento článek vysvětluje metody ověřování, které vám pomůžou s implementací služeb Azure Mapy. Tento článek také popisuje další ovládací prvky úč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:

Pro zlepšení zabezpečené komunikace s Azure Mapy 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í.

Primární a sekundární klíče se generují po vytvoření účtu Azure Mapy. Doporučujeme použít primární klíč jako klíč předplatného při volání Azure Mapy se sdíleným klíčem. Ověřování pomocí sdíleného klíče předává klíč vygenerovaný účtem Azure Mapy do služby Azure Mapy. Pro každou žádost o služby Azure Mapy 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/mapData/upload?api-version=1.0&dataFormat=zip&subscription-key={Your-Azure-Maps-Subscription-key}

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 Mapy. 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 Mapy nabízí ověřování pro služby Azure Mapy 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 Mapy 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 Mapy. Azure Mapy 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 Mapy vygeneruje jedinečný identifikátor (ID klienta) pro každý účet Azure Mapy. Tokeny můžete vyžádat z ID Microsoft Entra, když toto ID klienta zkombinujete s dalšími parametry.

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

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 Mapy

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 Mapy. 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 Mapy.

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-idje identifikátor GUID založený na účtu Azure Mapy, který se zobrazí na stránce ověřování azure Mapy.

Tady je příklad požadavku na trasu Azure Mapy, 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í.

Tip

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 Mapy 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ů, skupin, aplikací, prostředků Azure a spravovaných identit Azure. Použití přístupu k jednomu nebo více účtům Azure Mapy 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 Mapy s Azure RBAC. V rámci procesu nastavení účtu Azure Mapy je adresář Microsoft Entra přidružený k předplatnému Azure, ve kterém se nachází účet Azure Mapy.

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 Mapy Search a Render Data Reader	Poskytuje přístup pouze k vyhledávání a vykreslení rozhraní Azure Mapy REST API pro omezení přístupu k základním případům použití webového prohlížeče.
Čtečka dat Azure Mapy	Poskytuje přístup k neměnným rozhraním AZURE Mapy REST API.
Přispěvatel dat Azure Mapy	Poskytuje přístup k proměnlivé službě Azure Mapy REST API. Proměnlivost definovaná akcemi: zápis a odstranění
Role Azure Mapy data pro čtení a dávku	Tuto roli můžete použít k přiřazení akcí čtení a dávek v Azure Mapy.
Definice vlastní role	Vytvořte vytvořenou roli, která umožňuje flexibilní omezený přístup k rozhraním REST API azure Mapy.

Některé služby Azure Mapy mohou vyžadovat zvýšená oprávnění k provádění akcí zápisu nebo odstranění v rozhraních AZURE Mapy REST API. Pro služby, které poskytují akce zápisu nebo odstranění, se vyžaduje role Přispěvatel dat Azure Mapy. Následující tabulka popisuje, které služby Azure Mapy Přispěvatel dat se použijí 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 Mapy data použít roli Čtenář dat Azure Mapy.

Služba Azure Mapy	Definice role Azure Mapy
Data	Přispěvatel dat Azure Mapy
Tvůrce	Přispěvatel dat Azure Mapy
Spatial	Přispěvatel dat Azure Mapy
Dávkové vyhledávání a směrování	Přispěvatel dat Azure Mapy

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

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 rolí
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`
Role pro objekt zabezpečení, který požaduje čtení dat map založených na Azure Mapy Creatoru a rozhraní REST API dlaždic základní mapy.	`Microsoft.Maps/accounts/services/data/read`, `Microsoft.Maps/accounts/services/render/read`
Role pro objekt zabezpečení, který vyžaduje čtení, zápis a odstranění mapových dat založených na Tvůrci. Definuje se jako role editoru dat mapování, která neumožňuje přístup k jiným rozhraním REST API, jako jsou dlaždice základní mapy.	`Microsoft.Maps/accounts/services/data/read`, , `Microsoft.Maps/accounts/services/data/writeMicrosoft.Maps/accounts/services/data/delete`

Orientace v oborech

Při vytváření přiřazení role se definuje v hierarchii prostředků Azure. Horní část hierarchie je skupina pro správu a nejnižší je prostředek Azure, jako je účet Azure Mapy. Přiřazení role ke skupině prostředků může povolit přístup k více účtům nebo prostředkům Azure Mapy ve skupině.

Tip

Obecné doporučení Microsoftu je přiřadit přístup k rozsahu účtu Azure Mapy, protože brání nezamýšleným přístupu k jiným účtům Azure Mapy existujícím ve stejném předplatném Azure.

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

Účty Azure Mapy podporují standardní vlastnost Azure v rozhraní API pro správu volanou Microsoft.Maps/accountsdisableLocalAuth. Pokud trueje všechna ověřování v Rozhraní REST API v rovině dat Azure Mapy 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 místní ověření a po několika minutách se 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) jsou ověřovací tokeny vytvořené ve formátu JSON Web Token (JWT) a jsou kryptograficky podepsané, aby bylo možné prokázat ověřování pro aplikaci do rozhraní Azure Mapy REST API. Token SAS vytvořený integrací spravované identity přiřazené uživatelem s účtem Azure Mapy ve vašem předplatném Azure. Spravovaná identita přiřazená uživatelem má autorizaci k účtu Azure Mapy prostřednictvím Azure RBAC pomocí předdefinovaných nebo vlastních definic rolí.

Funkční klíčové rozdíly tokenu SAS z přístupových tokenů 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 Mapy.
Objekt instančního objektu pro autorizaci poskytuje spravovaná identita přiřazená uživatelem.

Tokeny SAS jsou neměnné. To znamená, že po vytvoření tokenu je token SAS platný až do dosažení vypršení platnosti a nejde změnit konfiguraci povolených oblastí, omezení rychlosti a spravované identity přiřazené uživatelem. Další informace o porozumění řízení přístupu pro odvolání tokenu SAS a změnách řízení přístupu najdete níže.

Vysvětlení limitů rychlosti tokenů SAS

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

Při zadávání maximálního limitu sazby u tokenu (maxRatePerSecond) se nadbytečné sazby neúčtují na účet, takže při použití tokenu nastavíte horní limit fakturovatelných transakcí. Aplikace však obdrží chybové odpovědi klienta pro 429 (TooManyRequests) všechny transakce po dosažení limitu. Za správu opakování a distribuce tokenů SAS zodpovídá aplikace. Neexistuje žádný limit počtu tokenů SAS, které je možné pro účet vytvořit. Povolení zvýšení nebo snížení limitu existujícího tokenu; Je nutné vytvořit nový token SAS. Starý token SAS je stále platný až do vypršení platnosti.

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 Mapy schopnosti 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í. Pokud chcete řídit náklady a zlepšit předvídatelnost, doporučujeme:

Vytvořte tokeny SAS s určenými povolenými umístěními Azure pro cílovou geografickou oblast. Pokračujte ve čtení a seznamte se s vytvářením tokenů SAS.
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 aplikací, 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 Mapy, 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 Mapy Management.

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

Jak je popsáno v limitech rychlosti azure Mapy, jednotlivé nabídky služeb mají různá omezení rychlosti, která se vynucují jako agregace účtu.

Vezměte v úvahu případ Search – non-Batch Reverse, s limitem 250 dotazů za sekundu (QPS) 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. Search – Nesádkové obrácení má limit rychlosti 250, což znamená, že celkem 30 000 žádostí 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 Mapy, každý token teď sdílí výchozí limit rychlosti 250 QPS. Pokud se každý token použije současně se stejným tokenem propustnosti 1 a tokenem 2, úspěšně udělí 7500 ú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
token 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 přístup před vypršením platnosti tokenu SAS, odvolejte token. Další důvody odvolání přístupu můžou být v případě, že se token distribuuje neúmyslně s přiřazením Azure Maps Data Contributor role a každý, kdo má token SAS, může číst a zapisovat data do azure Mapy rozhraní REST API, která můžou vystavit citlivá data nebo neočekávané finanční náklady z využití.

existují dvě možnosti odvolání přístupu pro tokeny SAS:

Znovu vygenerujte klíč používaný tokenem SAS nebo sekundárním klíčem účtu mapy.
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 způsobí, že instance vaší aplikace pomocí tokenu SAS a spravované identity úmyslně vrátí 401 Unauthorized nebo 403 Forbidden z azure Mapy rozhraní REST API, která způsobí přerušení aplikace.

Abyste se vyhnuli přerušení:

Přidejte do účtu mapy druhou spravovanou identitu a udělte nové spravované identitě správné přiřazení role.
Vytvořte token SAS pomocí secondaryKeynebo jiné spravované identity než předchozí, jako signingKey a distribuujte do aplikace nový token SAS.
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 Mapy i identit přiřazených uživatelem v předplatném Azure.

Důležité

Stávající účty Azure Mapy 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 Mapy.

Tip

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

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

Po úspěšném vytvoření nebo aktualizaci účtu spravovanou identitou; přiřaďte spravované identitě řízení přístupu na základě role k roli dat Azure Mapy v oboru účtu. To umožňuje, aby spravovaná identita byla udělena přístup k rozhraní AZURE Mapy REST API 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
Signingkey	`primaryKey`	Povinný argument, hodnota výčtu řetězce pro podpisKey buď `primaryKeysecondaryKey` nebo spravovaná identita se používá k vytvoření podpisu SAS.
principalId	`<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í API roviny dat REST azure Mapy. Vynechání parametru oblastí umožňuje použití tokenu SAS bez jakýchkoli omezení. Pokud se používá v kombinaci s geografickým koncovým bodem `us.atlas.microsoft.com` v rovině dat Azure Mapy a `eu.atlas.microsoft.com` umožňuje aplikaci řídit využití v zadané zeměpisné oblasti. To umožňuje prevenci použití v jiných zeměpisných oblastech.
maxRatePerSecond	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 .
start	`2021-05-24T10:42:03.1567373Z`	Povinné je datum UTC, které určuje datum a čas, kdy se token aktivuje.
expiry	`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

Po přijetí tokenu SAS odešle sada Azure Mapy SDK nebo aplikace požadavek HTTPS s následující požadovanou 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.

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 Mapy můžete nakonfigurovat, které zdroje mají povolený přístup k rozhraní Azure Mapy REST API z vašich aplikací.

Důležité

CORS není autorizační mechanismus. Každý požadavek 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 Mapy. Protokol CORS není specifický pro Azure Mapy.

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 se provádí nejen jako bezpečnostní opatření, které zajistí, že server rozumí metodě a hlaviček odesílaných ve skutečném požadavku a že server ví a důvěřuje zdroji požadavku, ale také se dotazuje omezení CORS, která byla stanovena 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:

Požadavek OPTIONS obsahuje požadovaná hlavička CORS (hlavičky Origin a Access-Control-Request-Method).
Ověření proběhlo úspěšně a pro účet, který odpovídá předběžné žádosti, je povolené pravidlo CORS.
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:

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).
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 určují jeho vlastnosti povolené zdroje, které se mají konfigurovat. Pravidlo CORS ve vlastnostech účtu Azure Mapy můžete nastavit prostřednictvím sady Azure Mapy Management SDK, rozhraní REST API služby Azure Mapy Management a portálu. Jakmile nastavíte pravidlo CORS pro službu, vyhodnotí se správně autorizovaný požadavek na službu z jiné domény, abyste zjistili, jestli je povolené podle 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í Azure Mapy REST API 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 Mapy SDK
- Rozhraní REST API služby Azure Mapy Management
- Šablona ARM

Tip

Pokud používáte rozhraní REST API pro správu Azure Mapy , 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 Mapy nepočítá fakturační transakce pro:

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

Další informace o fakturačních transakcích a dalších cenách azure Mapy najdete v tématu Ceny Mapy Azure.

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 Mapy najdete tady:

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

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

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

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

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

Ověřování Microsoft Entra

Spravované identity pro prostředky Azure a Azure Mapy

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

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

Požadavky

Přehled

Výběr definice role

Vlastní definice rolí

Orientace v oborech

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

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

Vysvětlení limitů rychlosti tokenů SAS

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

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

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

Principy řízení přístupu tokenu SAS

Vytvoření tokenů SAS

Konfigurace aplikace pomocí tokenu SAS

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

Požadavky

Požadavky CORS

Předběžný požadavek

Skutečný požadavek

Povolení zásad CORS

Odebrání zásad CORS

Vysvětlení fakturačních transakcí

Další kroky

Další materiály