Informace o přihlašovacích údaji rozhraní API a správci přihlašovacích údajů

PLATÍ PRO: Všechny úrovně služby API Management

Aby vám pomohla spravovat přístup k back-endovým rozhraním API, vaše instance služby API Management zahrnuje správce přihlašovacích údajů. Pomocí správce přihlašovacích údajů můžete spravovat, ukládat a řídit přístup k přihlašovacím údajům rozhraní API z vaší instance služby API Management.

Poznámka:

  • V současné době můžete pomocí správce přihlašovacích údajů nakonfigurovat a spravovat připojení (dříve označovaná jako autorizace) pro rozhraní API OAuth 2.0 back-endu.
  • Ve Správci přihlašovacích údajů nejsou zavedeny žádné zásadní změny. Poskytovatelé přihlašovacích údajů OAuth 2.0 a připojení používají stávající autorizační rozhraní API služby API Management a poskytovatele prostředků.

Spravovaná připojení pro rozhraní API OAuth 2.0

Pomocí správce přihlašovacích údajů můžete výrazně zjednodušit proces ověřování a autorizace uživatelů, skupin a instančních objektů v jednom nebo několika back-endových službách nebo službách SaaS, které používají OAuth 2.0. Pomocí správce přihlašovacích údajů služby API Management můžete snadno nakonfigurovat OAuth 2.0, souhlas, získat tokeny, ukládat tokeny do mezipaměti v úložišti přihlašovacích údajů a obnovovat tokeny bez zápisu jednoho řádku kódu. Pomocí zásad přístupu delegujte ověřování na instanci služby API Management, instanční objekty, uživatele nebo skupiny. Základní informace o OAuth 2.0 najdete v tématu Microsoft Identity Platform a tok autorizačního kódu OAuth 2.0.

Tato funkce umožňuje zpřístupnění rozhraní API s klíčem předplatného nebo bez tohoto klíče, použití autorizací OAuth 2.0 pro back-endové služby a snížení nákladů na vývoj při zvýrazňování, implementaci a údržbě funkcí zabezpečení s integrací služeb.

Diagram správce přihlašovacích údajů služby API Management a podporovaných zprostředkovatelů identity SaaS

Příklady případů použití

Pomocí připojení OAuth spravovaných ve službě API Management se zákazníci můžou snadno připojit k poskytovatelům SaaS nebo back-endovým službám, které používají OAuth 2.0. Několik příkladů:

  • Snadné připojení k back-endu SaaS připojením uloženého autorizačního tokenu a žádostí o proxy server

  • Proxy požadavky na webovou aplikaci Aplikace Azure Service nebo back-end Služby Azure Functions připojením autorizačního tokenu, který může později odesílat požadavky do back-endu SaaS s využitím logiky transformace

  • Proxy požadavky na back-endy federace GraphQL připojením několika přístupových tokenů za účelem snadného provádění federace

  • Zveřejnění koncového bodu načtení tokenu, získání tokenu v mezipaměti a volání back-endu SaaS jménem uživatele z libovolného výpočetního prostředí, například z konzolové aplikace nebo démona Kubernetes. Zkombinujte svou oblíbenou sadu SaaS SDK v podporovaném jazyce.

  • Bezobslužné scénáře Azure Functions při připojování k několika back-endům SaaS

  • Durable Functions se přibližuje Logic Apps s připojením SaaS.

  • S připojeními OAuth 2.0 může každé rozhraní API ve službě API Management fungovat jako vlastní konektor Logic Apps.

Jak funguje správce přihlašovacích údajů?

Přihlašovací údaje tokenu ve správci přihlašovacích údajů se skládají ze dvou částí: správa a modul runtime.

  • Součástí správy ve správci přihlašovacích údajů je nastavení a konfigurace zprostředkovatele přihlašovacích údajů pro tokeny OAuth 2.0, povolení toku souhlasu pro zprostředkovatele identity a nastavení jednoho nebo více připojení k zprostředkovateli přihlašovacích údajů pro přístup k přihlašovacím údajům. Podrobnosti najdete v tématu Správa připojení.

  • Část runtime používá zásadu get-authorization-context k načtení a uložení přístupových a obnovovacích tokenů připojení. Když volání přijde do služby API Management a get-authorization-context zásada se spustí, nejprve ověří, jestli je existující autorizační token platný. Pokud vypršela platnost autorizačního tokenu, služba API Management pomocí toku OAuth 2.0 aktualizuje uložené tokeny od zprostředkovatele identity. Přístupový token se pak použije k autorizaci přístupu k back-endové službě. Podrobnosti najdete v tématu Modul runtime připojení.

Kdy použít správce přihlašovacích údajů?

Následují tři scénáře použití správce přihlašovacích údajů.

Scénář konfigurace

Po konfiguraci zprostředkovatele přihlašovacích údajů a připojení může správce rozhraní API připojení otestovat. Správce rozhraní API nakonfiguruje testovací back-endové rozhraní API OAuth tak, aby používalo zásadu get-authorization-context pomocí spravované identity instance. Správce rozhraní API pak může otestovat připojení voláním testovacího rozhraní API.

Diagram počátečního scénáře konfigurace pro správce přihlašovacích údajů

Bezobslužný scénář

Ve výchozím nastavení při vytvoření připojení jsou zásady přístupu a připojení předem nakonfigurované pro spravovanou identitu instance služby API Management. Pokud chcete takové připojení použít, můžou se různí uživatelé přihlásit k klientské aplikaci, jako je statická webová aplikace, která pak volá back-endové rozhraní API zveřejněné prostřednictvím služby API Management. K provedení tohoto volání se připojení použijí pomocí get-authorization-context zásad. Vzhledem k tomu, že volání rozhraní API používá předkonfigurované připojení, které nesouvisí s kontextem uživatele, vrátí se stejná data všem uživatelům.

Diagram scénáře spravované identity pro správce přihlašovacích údajů

Scénář účasti (delegovaný uživatelem)

Pokud chcete uživatelům klientských aplikací, jako jsou statické webové aplikace, které volají back-endová rozhraní API SaaS, která vyžadují kontext uživatele, povolit přístup k připojení jménem uživatele nebo identity skupiny Microsoftu. V tomto případě se nakonfigurovaný uživatel musí přihlásit a poskytnout souhlas pouze jednou a instance služby API Management vytvoří a bude po tom spravovat připojení. Když služba API Management získá příchozí volání, které se má přesměrovat do externí služby, připojí přístupový token z připojení k požadavku. To je ideální pro případ, kdy jsou požadavky rozhraní API a odpovědi zaměřené na jednotlivce (například načítání informací o profilu specifickém pro uživatele).

Diagram scénáře delegovaného uživatelem pro správce přihlašovacích údajů

Jak nakonfigurovat správce přihlašovacích údajů?

Požadavky

  • Pro instanci služby API Management musí být povolená identita přiřazená spravovaným systémem.

  • Instance služby API Management musí mít odchozí připojení k internetu na portu 443 (HTTPS).

Dostupnost

  • Všechny úrovně služby API Management

  • Nepodporuje se v bráně v místním prostředí

  • Nepodporuje se v suverénních cloudech nebo v následujících oblastech: australiacentral, australiacentral2, indiacentral

Podrobné příklady

Bezpečnostní aspekty

Přístupový token a další tajné kódy (například tajné kódy klienta) se šifrují pomocí šifrování obálky a ukládají se v interním víceklientovém úložišti. Data se šifrují pomocí AES-128 pomocí klíče, který je jedinečný na data. Tyto klíče se šifrují asymetricky pomocí hlavního certifikátu uloženého ve službě Azure Key Vault a každý měsíc se obměňují.

Omezení

Prostředek Omezení
Maximální počet zprostředkovatelů přihlašovacích údajů na instanci služby 1000
Maximální počet připojení na zprostředkovatele přihlašovacích údajů 10,000
Maximální počet zásad přístupu na připojení 100
Maximální početžádostích 250

Nejčastější dotazy

Kdy se obnovují přístupové tokeny?

Pro připojení typu autorizačního kódu se přístupové tokeny aktualizují následujícím způsobem: Při get-authorization-context spuštění zásady za běhu služba API Management zkontroluje, jestli je uložený přístupový token platný. Pokud platnost tokenu vypršela nebo brzy vyprší, služba API Management použije obnovovací token k načtení nového přístupového tokenu a nového obnovovacího tokenu z nakonfigurovaného zprostředkovatele identity. Pokud vypršela platnost obnovovacího tokenu, vyvolá se chyba a připojení musí být před tím, než bude fungovat, znovu autorizováno.

Co se stane, když vyprší platnost tajného klíče klienta u zprostředkovatele identity?

Za běhu nemůže služba API Management načíst nové tokeny a dojde k chybě.

  • Pokud je připojení typu autorizačního kódu, je potřeba aktualizovat tajný klíč klienta na úrovni zprostředkovatele přihlašovacích údajů.

  • Pokud je připojení typu přihlašovací údaje klienta, je potřeba aktualizovat tajný klíč klienta na úrovni připojení.

Podporuje se tato funkce pomocí služby API Management spuštěné uvnitř virtuální sítě?

Ano, pokud je povolené odchozí připojení na portu 443 ke značce služby Azure Připojení orům. Další informace najdete v tématu Referenční informace o konfiguraci virtuální sítě.

Co se stane, když se odstraní zprostředkovatel přihlašovacích údajů?

Odstraní se také všechna základní připojení a zásady přístupu.

Jsou přístupové tokeny uložené ve službě API Management v mezipaměti?

Ve vrstvách služby Classic a v2 se přístupový token ukládá do mezipaměti instance služby API Management do 3 minut před vypršením platnosti tokenu. Pokud je přístupový token kratší než 3 minuty od vypršení platnosti, doba uložená v mezipaměti bude do vypršení platnosti přístupového tokenu.

Přístupové tokeny nejsou uloženy v mezipaměti na úrovni Consumption.