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

Článek
09/25/2024

Azure Maps 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 Maps. 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:

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

Primární a sekundární klíče se generují po vytvoření účtu Azure Maps. 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 na trasu Azure Maps, 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 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 mohou vyžadovat 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
Tvůrce (zastaralé¹)	Přispěvatel dat Azure Maps
Prostorová (zastaralá¹)	Přispěvatel dat Azure Maps
Dávkové vyhledávání a směrování	Přispěvatel dat Azure Maps

¹ Azure Maps Creator a registr dat a prostorové služby jsou nyní zastaralé a budou vyřazeny 30. 9. 25.

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 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 Maps 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. V horní části hierarchie je skupina pro správu a nejnižší je prostředek Azure, jako je účet Azure Maps. Přiřazení role ke skupině prostředků může povolit přístup k více účtům nebo prostředkům Azure Maps ve skupině.

Tip

Obecné doporučení Microsoftu je přiřadit přístup k rozsahu účtu Azure Maps, protože brání nezamýšleným přístupu k jiným účtům Azure Maps existujícím 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 pro Microsoft.Maps/accounts volání disableLocalAuth. Pokud trueje veškeré ověřování pro rozhraní REST API roviny dat Azure Maps 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é ověřit ověřování pro aplikaci v rozhraní REST API služby Azure Maps. Token SAS vytvořený integrací spravované identity přiřazené uživatelem s účtem Azure Maps ve vašem předplatném Azure. Spravovaná identita přiřazená uživatelem má autorizaci k účtu Azure Maps 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 Maps.
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 Maps.

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 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í. 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 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 služby Azure Maps, 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 Maps, 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 rozhraní REST API služby Azure Maps, 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 rozhraní REST API služby Azure Maps, která vytvoří 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 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.

Tip

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

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.

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. 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 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 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 Maps můžete nastavit prostřednictvím sady AZURE Maps Management SDK, rozhraní REST API pro správu Služby Azure Maps 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í 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

Tip

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 (TooManyRequests)
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

Sdílet prostřednictvím

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 Maps

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

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

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

Váš názor

Další materiály

Sdílet prostřednictvím

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 Maps

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

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

Váš názor

Další materiály