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

Článek
03/09/2023
19 min ke čtení

Azure Maps podporuje tři způsoby ověřování požadavků: ověřování pomocí sdíleného klíče, ověřování Azure Active Directory (Azure AD) a ověřování tokenem 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. Č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

Abychom zlepšili zabezpečenou komunikaci s Azure Maps, podporujeme teď protokol TLS (Transport Layer Security) 1.2 a vyřazujeme podporu protokolů 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 pomocí testování popsaného v tématu Řešení problému s protokolem TLS 1.0.

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

Informace o zobrazení klíčů v Azure Portal najdete v tématu Správa ověřování.

Primární a sekundární klíče se vygenerují po vytvoření účtu Azure Maps. Při volání Azure Maps se sdíleným klíčem doporučujeme jako klíč předplatného použít primární klíč. Ověřování pomocí sdíleného klíče předá klíč vygenerovaný účtem Azure Maps službě Azure Maps. Pro každý požadavek na Azure Maps služeb 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 průběžné změny 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é

S primárními a sekundárními klíči by se mělo zacházet jako s citlivými daty. Sdílený klíč slouží k ověřování všech Azure Maps rozhraní REST API. Uživatelé, kteří používají sdílený klíč, by měli klíč rozhraní API abstrahovat, 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 spravovat centrálně.

Ověřování Azure AD

Předplatná Azure se poskytují s tenantem Azure AD, který umožňuje jemně odstupňované řízení přístupu. Azure Maps nabízí ověřování pro služby Azure Maps pomocí Azure AD. Azure AD poskytuje uživatelům a aplikacím zaregistrovaným v tenantovi Azure AD ověřování na základě identit.

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

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

Azure Maps vygeneruje jedinečný identifikátor (ID klienta) pro každý účet Azure Maps. Tokeny můžete požadovat od Azure AD, když toto ID klienta zkombinujete s dalšími parametry.

Další informace o konfiguraci tokenů Azure AD a vyžádání pro Azure Maps najdete v tématu Správa ověřování v Azure Maps.

Obecné informace o ověřování pomocí Azure AD najdete 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ěřovat pomocí Azure AD. Pomocí řízení přístupu na základě role v Azure (Azure RBAC) je možné objekt zabezpečení spravované identity autorizovat pro přístup k Azure Maps službám. Mezi příklady spravovaných identit patří: Azure App Service, Azure Functions a Azure Virtual Machines. Seznam spravovaných identit najdete v tématu Služby Azure, které můžou používat spravované identity pro přístup k další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í Azure AD aplikací

Aplikace se budou ověřovat v tenantovi Azure AD pomocí jednoho nebo několika podporovaných scénářů poskytovaných Azure AD. Každý scénář Azure AD aplikace představuje různé požadavky v závislosti na obchodních potřebách. Některé aplikace můžou vyžadovat přihlašování uživatelů a jiné můžou vyžadovat přihlašování aplikací. Další informace najdete v tématu Toky ověřování a scénáře aplikací.

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

Název hlavičky	Hodnota
x-ms-client-id	30d7cc....9f55
Autorizace	Bearer eyJ0e....HNIVN

Poznámka

x-ms-client-idje identifikátor GUID Azure Maps založený na účtu, 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 OAuth Azure AD:

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 pomocí Get-AzMapsAccount, například:

$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 s využitím řízení přístupu na základě role

Požadavky

Pokud s Azure RBAC začínáte, přehled řízení přístupu na základě role v Azure (Azure RBAC) poskytuje typům objektů zabezpečení sadu oprávnění, označovanou také jako definice role. Definice role poskytuje oprávnění k akcím rozhraní REST API. Azure Maps podporuje přístup ke všem hlavním typům pro řízení přístupu na základě role v Azure (Azure RBAC), včetně jednotlivých uživatelů Azure AD, skupin, aplikací, prostředků Azure a spravovaných identit Azure. Použití přístupu na jeden nebo více účtů 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

Další části popisují koncepty a komponenty Azure Maps integrace s Azure RBAC. V rámci procesu nastavení účtu Azure Maps je k předplatnému Azure, ve kterém se nachází účet Azure Maps, přidružený adresář Azure AD.

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

Výběr definice role

Existují následující typy definic rolí, které podporují scénáře aplikací.

Definice role Azure	Popis
Azure Maps Prohledávat a vykreslovat čtečku dat	Poskytuje přístup pouze k vyhledávání a vykreslování Azure Maps rozhraní REST API, aby se omezil přístup k základním případům použití webového prohlížeče.
Azure Maps Data Reader	Poskytuje přístup k neměnným rozhraním REST API Azure Maps.
Přispěvatel dat Azure Maps	Poskytuje přístup k měnitelným rozhraním REST API Azure Maps. Proměnlivost je definována akcemi: zápis a odstranění.
Definice vlastní role	Vytvořte vytvořenou roli, která umožní flexibilní omezený přístup k rozhraním AZURE MAPS REST API.

Některé Azure Maps služby můžou k provádění akcí zápisu nebo odstranění v rozhraních REST API Azure Maps vyžadovat zvýšená oprávnění. Azure Maps služeb, které poskytují akce zápisu nebo odstranění, se vyžaduje role Přispěvatel dat. Následující tabulka popisuje, které služby Azure Maps Přispěvatel dat jsou použitelné při použití akcí zápisu nebo odstranění. Pokud se vyžadují jenom akce čtení, můžete místo role Přispěvatel dat Azure Maps použít roli čtenáře dat Azure Maps.

Azure Maps služba	definice role Azure Maps
Data	Přispěvatel dat Azure Maps
tvůrce	Přispěvatel dat Azure Maps
Prostorové	Přispěvatel dat 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.

Definice vlastních rolí

Jedním z aspektů zabezpečení aplikací je princip nejnižších oprávnění, postup omezení přístupových práv pouze na ty, které jsou potřeba k provádění příslušné úlohy. Chcete-li toho dosáhnout, vytvořte vlastní definice rolí, které podporují případy použití, které vyžadují další členitost řízení přístupu. Pokud chcete vytvořit vlastní definici role, vyberte konkrétní akce dat, které chcete zahrnout nebo vyloučit pro definici.

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

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

Scenario	Akce dat vlastních rolí
Veřejná nebo interaktivní přihlašovací webová 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 reverzní geokódování a žádná další rozhraní REST API.	`Microsoft.Maps/accounts/services/search/read`
Role pro objekt zabezpečení, který požaduje čtení rozhraní REST API založených na mapě Azure Maps Creator a 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 odstraňování mapových dat založených na Autoru. Dá se definovat jako role editoru dat mapování, ale 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/write`, `Microsoft.Maps/accounts/services/data/delete`

Orientace v oborech

Při vytváření přiřazení role se definuje v hierarchii prostředků Azure. Na vrcholu 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 umožnit přístup k více Azure Maps účtům nebo prostředkům ve skupině.

Tip

Microsoft obecně doporučuje přiřadit přístup k oboru účtu Azure Maps, protože brání neúmyslnému přístupu k jiným účtům Azure Maps existujícím ve stejném předplatném Azure.

Zakázat místní ověřování

Azure Maps účty podporují standardní vlastnost Azure v rozhraní API pro správu s Microsoft.Maps/accounts názvem disableLocalAuth. Pokud trueje zakázáno veškeré ověřování v rozhraní REST API v rovině dat Azure Maps s výjimkou ověřování Azure AD. To se konfiguruje pomocí 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ých podpisů

Důležité

Funkce Ve verzi Preview jsou k dispozici na základě samoobslužného souhlasu. Verze Preview se poskytují "tak, jak jsou" a "tak, jak jsou k dispozici" a jsou vyloučené ze smluv o úrovni služeb a omezené záruky. Azure Maps verze Preview jsou částečně pokryty zákaznickou podporou na základě maximálního úsilí. Tyto funkce proto nejsou určené pro produkční použití.

Ověřování tokenem sdíleného přístupových podpisů je ve verzi Preview.

Tokeny sdíleného přístupového podpisu (SAS) jsou ověřovací tokeny vytvořené pomocí formátu JSON Web Token (JWT) a jsou kryptograficky podepsané, aby se prokázalo ověření aplikace v rozhraní AZURE MAPS REST API. Token SAS se vytvoří tak, že nejprve integrujete spravovanou identitu přiřazenou uživatelem s účtem Azure Maps ve vašem předplatném Azure. Spravované identitě přiřazené uživatelem se udělí autorizace k účtu Azure Maps prostřednictvím Azure RBAC pomocí některé z předdefinovaných nebo vlastních definic rolí.

Rozdíly funkčních klíčů tokenu SAS od přístupových tokenů Azure AD:

Životnost tokenu s maximálním vypršením platnosti jednoho roku (365 dnů)
Řízení přístupu k poloze a zeměpisné oblasti Azure 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 Azure Maps účtu.
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 vypršení platnosti a není možné změnit konfiguraci povolených oblastí, omezení rychlosti a spravované identity přiřazené uživatelem. Níže si přečtěte další informace o tom, jak porozumět řízení přístupu k odvolání tokenů SAS a změnám řízení přístupu.

Principy omezení rychlosti tokenů SAS

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

Zadáním maximálního limitu sazby tokenu (maxRatePerSecond) se nadbytečná sazba neúčtuje na účet, což vám umožní nastavit horní limit fakturovatelných transakcí pro účet při použití tokenu. Aplikace však obdrží odpovědi na chyby klienta s 429 (TooManyRequests) pro všechny transakce po dosažení limitu. Za správu opakování a distribuce tokenů SAS zodpovídá aplikace. Neexistuje žádné omezení počtu tokenů SAS, které je možné pro účet vytvořit. Umožnění zvýšení nebo snížení limitu existujícího tokenu; Musí se vytvořit nový token SAS. Starý token SAS je stále platný až do vypršení jeho platnosti.

Odhadovaný příklad:

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

Jedná se o odhady, skutečné limity rychlosti se mírně liší v závislosti na Azure Maps schopnosti vynucovat konzistenci v rámci časového intervalu. To však umožňuje preventivní kontrolu nákladů na fakturaci.

Omezení rychlosti se vynucují pro každou lokalitu Azure, nikoli 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 stejný token použije v West US 2nástroji , vytvoří se nový čítač pro omezení propustnosti 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 rozhraní REST API geografické roviny dat nebo https://us.atlas.microsoft.comhttps://eu.atlas.microsoft.com.

Vezměte v úvahu topologii aplikace, kde koncový bod https://us.atlas.microsoft.com směruje do stejných umístění v USA, jako jsou hostované Azure Maps služby, jako East USjsou , West Central USnebo West US 2. Stejná myšlenka platí i pro jiné geografické koncové body, například https://eu.atlas.microsoft.com 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 jako aplikace. Umístění koncového bodu se definuje pomocí rozhraní REST API služby Azure Maps Management.

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

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

Podívejte se na 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ázky využití.

První tabulka ukazuje jeden token, který má maximální počet požadavků za sekundu 500 a potom skutečné využití aplikace bylo 500 požadavků za sekundu po dobu 60 sekund. Search – Non-Batch Reverse má limit rychlosti 250, což znamená celkový počet 30 000 požadavků provedených za 60 sekund; 15 000 těchto požadavků bude fakturovatelné transakce. Zbývající požadavky budou mít za následek stavový kód 429 (TooManyRequests).

Name	Přibližná maximální rychlost za sekundu	Skutečná sazba za sekundu	Doba trvání trvalé rychlosti v sekundách	Přibližný celkový počet úspěšných transakcí
token	500	500	60	~15 000

Pokud jsou například v systému 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žívá současně se stejným tokenem propustnosti 1 a token 2 by úspěšně udělil 7500 úspěšných transakcí.

Name	Přibližná maximální rychlost za sekundu	Skutečná sazba za sekundu	Doba trvání trvalé rychlosti v sekundách	Přibližný celkový počet úspěšných transakcí
token 1	250	250	60	~7500
token 2	250	250	60	~7500

Principy řízení přístupu k tokenům 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 by měla aplikace povolit, najdete v tématu Výběr definice role .

Pokud chcete přiřadit dočasný přístup a odebrat přístup pro před vypršením platnosti tokenu SAS, budete chtít token odvolat. K dalším důvodům odvolání přístupu může dojít v případě, že se token neúmyslně distribuuje 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 Maps rozhraní REST API, která můžou vystavit citlivá data nebo neočekávané finanční náklady spojené s využitím.

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

Znovu vygenerujte klíč, který byl použit tokenem SAS, primárním nebo sekundárním klíčem účtu mapování.
Odeberte přiřazení role pro spravovanou identitu v přidruženém účtu mapování.

Upozornění

Odstranění spravované identity používané tokenem SAS nebo odvolání řízení přístupu ke spravované identitě způsobí, že instance vaší aplikace používající token SAS a spravovanou identitu záměrně vrátí 401 Unauthorized nebo 403 Forbidden z Azure Maps rozhraní REST API, což způsobí přerušení aplikace.

Abyste se vyhnuli přerušení:

Přidejte do mapového účtu druhou spravovanou identitu a udělte nové spravované identitě správné přiřazení role.
Vytvořte token SAS pomocí secondaryKeysigningKey příkazu a distribuujte nový token SAS do aplikace.
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 vytvářet 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 ho. 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 roli Azure Maps dat v oboru účtu. To umožňuje, aby spravovaná identita získala přístup k rozhraní AZURE MAPS REST API pro váš účet mapy.

Dále budete muset vytvořit token SAS pomocí nástrojů sady Azure Management SDK, operace vypsat SAS v rozhraní API pro správu účtů nebo stránky Azure Portal sdíleného přístupového podpisu prostředku mapového účtu.

Parametry tokenu SAS:

Název parametru	Příklad hodnoty	Popis
Signingkey	`primaryKey`	Povinný argument: Hodnota výčtu řetězce pro signingKey buď `primaryKey` , nebo `secondaryKey` 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í.
Regiony	`[ "eastus", "westus2", "westcentralus" ]`	Volitelné, výchozí hodnota je `null`. Oblasti určují, které oblasti lze token SAS použít v rozhraní API Azure Maps roviny dat REST. Vynechání parametru oblastí umožní použití tokenu SAS bez jakýchkoli omezení. Při použití v kombinaci s Azure Maps geografický koncový bod roviny dat, například `us.atlas.microsoft.com` a `eu.atlas.microsoft.com` umožní aplikaci řídit využití v zadané geografické oblasti. To umožňuje zabránit použití v jiných zeměpisných oblastech.
maxRatePerSecond	500	Vyžaduje se zadaný přibližný maximální počet požadavků za sekundu, který je udělený token SAS. Jakmile dosáhnete limitu, další propustnost bude rychlostně 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.
Vypršení platnosti	`2021-05-24T11:42:03.1567373Z`	Povinné je datum UTC, které určuje datum a čas vypršení platnosti tokenu. Doba mezi začátkem a vypršením platnosti nesmí být delší než 365 dnů.

Konfigurace aplikace pomocí tokenu SAS

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

Název hlavičky	Hodnota
Autorizace	jwt-sas eyJ0e....HNIVN

Poznámka

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

Důležité

Funkce Preview jsou k dispozici na základě samoobslužného souhlasu. Verze Preview se poskytují "tak, jak jsou" a "tak, jak jsou" a "tak, jak jsou k dispozici" a jsou vyloučeny ze smluv o úrovni služeb a omezené záruky. Azure Maps verze Preview jsou částečně pokryté zákaznickou podporou v maximálním úsilí. Z tohoto důvodu nejsou tyto funkce určeny pro produkční použití.

Sdílení prostředků mezi zdroji (CORS) je ve verzi Preview.

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) a hlavička umožňuje Access-Control-Allow-Origin deklarovat, které zdroje můžou volat koncové body účtu Azure Maps. Protokol CORS není specifický pro Azure Maps.

CORS účtu

CORS je protokol HTTP, který webové aplikaci spuštěné v jedné doméně umožňuje přístup k prostředkům v jiné doméně. Webové prohlížeče implementují omezení zabezpečení označované jako zásady stejného původu , které brání webové stránce volat rozhraní API v jiné doméně. CORS poskytuje bezpečný způsob, jak jedné doméně (původní doméně) povolit volání rozhraní API v jiné doméně. Pomocí prostředku Azure Maps účtu můžete nakonfigurovat, které zdroje mají povolený přístup k rozhraní AZURE MAPS 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, také vyžaduje platné schéma ověřování účtu mapování, jako je sdílený klíč, Azure AD nebo token SAS.

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

Požadavky CORS

Požadavek 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 na omezení CORS stanovená službou. Předběžný požadavek je povinný, pokud se nejedná o standardní metodu GET, HEAD, POST nebo požadavky, které obsahují Authorization hlavičku požadavku.
Skutečný požadavek provedený vůči požadovanému prostředku.

Předběžný požadavek

Předběžný požadavek se provádí nejen jako bezpečnostní opatření, aby se zajistilo, že server rozumí metodě a hlavičce, které budou odeslány ve skutečném požadavku, a že server zná zdroj požadavku a důvěřuje mu, ale také se dotazuje na omezení CORS, která byla pro účet mapování nastavena. 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ání účtů 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 vyhodnotí 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 ve skutečném požadavku na službu Maps. Ve výchozím nastavení je účet maps nakonfigurovaný tak, aby umožňoval bezproblémovou integraci všech počátků do webových prohlížečů.

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

Požadavek OPTIONS obsahuje požadované hlavičky CORS (hlavičky Origin a Access-Control-Request-Method).
Ověření proběhlo úspěšně a pro účet, který odpovídá předběžnému požadavku, je povolené pravidlo CORS.
Ověřování bylo vynecháno kvůli požadovaným Authorization hlavičkám požadavků, které nelze 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 Access-Control.

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čky CORS (hlavičky Origin a Access-Control-Request-Method), služba odpoví stavovým kódem 400 (Bad request).
Pokud bylo ověření úspěšné na předběžném požadavku a předběžnému požadavku neodpovídá žádné pravidlo CORS, 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ě, a ne vůči požadovanému prostředku. Aby mohl požadavek proběhnout úspěšně, musí vlastník účtu povolit CORS nastavením příslušných vlastností účtu.

Skutečná žádost

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

Se skutečným požadavkem se zachází jako s normálním požadavkem vůči mapové službě. Přítomnost Origin hlavičky značí, že požadavek je požadavek CORS a služba pak provede ověření podle pravidel CORS. Pokud se najde shoda, hlavičky Access-Control se přidají do odpovědi a odešlou se zpět klientovi. Pokud se nenajde shoda, odpověď vrátí 403 (Forbidden) chybu původu CORS.

Povolení zásad CORS

Při vytváření nebo aktualizaci existujícího účtu mapování můžou vlastnosti účtu mapování určovat povolené zdroje, které se mají nakonfigurovat. Pravidlo CORS pro vlastnosti účtu Azure Maps můžete nastavit prostřednictvím sady SDK Azure Maps Management, rozhraní REST API Azure Maps Management a portálu. Jakmile pro službu nastavíte pravidlo CORS, vyhodnotí se správně autorizovaný požadavek na službu z jiné domény, aby se zjistilo, jestli je povolená podle pravidla, které jste zadali. Podívejte se na následující příklad:

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

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

Odebrání zásad CORS

CORS můžete odebrat ručně v Azure Portal nebo programově pomocí sady Azure Maps SDK, rozhraní REST API pro správu Azure Maps nebo šablony ARM.

Tip

Pokud používáte rozhraní REST API Azure Maps Management , použijte PUT nebo PATCH s prázdným corsRule seznamem v textu požadavku.

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

Vysvětlení fakturačních transakcí

Azure Maps nezapočítává transakce fakturace pro:

Stavové kódy HTTP 5xx
401 (Neautorizováno)
403 (zakázáno)
408 (vypršení časového limitu)
429 (TooManyRequests)
Předběžné požadavky CORS

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

Další kroky

Další informace o osvědčených postupech zabezpečení najdete tady:

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

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

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

Další informace o ověřování mapového ovládacího prvku Azure Maps pomocí Azure AD najdete tady:

Použití Azure Maps mapového ovládacího prvku

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

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

Ověřování Azure AD

Spravované identity pro prostředky Azure a Azure Maps

Konfigurace ověřování Azure AD aplikací

Autorizace s využitím řízení přístupu na základě role

Požadavky

Přehled

Výběr definice role

Definice vlastních rolí

Orientace v oborech

Zakázat místní ověřování

Ověřování tokenu sdíleného přístupových podpisů

Principy omezení rychlosti tokenů SAS

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

Omezení rychlosti se vynucují pro každou lokalitu Azure, nikoli globálně nebo geograficky.

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

Principy řízení přístupu k tokenům SAS

Vytvoření tokenů SAS

Konfigurace aplikace pomocí tokenu SAS

Požadavky

CORS účtu

Požadavky CORS

Předběžný požadavek

Skutečná žádost

Povolení zásad CORS

Odebrání zásad CORS

Vysvětlení fakturačních transakcí

Další kroky

Další materiály

Další materiály