Postupy: Migrace ze služby Azure Access Control Service
Upozornění
Tento obsah je určený pro starší koncový bod Azure AD verze 1.0. U nových projektů použijte Microsoft identity platform.
Služba Microsoft Azure Access Control Service (ACS), služba Azure Active Directory (Azure AD), bude 7. listopadu 2018 vyřazena z provozu. Aplikace a služby, které aktuálně používají Access Control, musí být do té doby plně migrovány na jiný mechanismus ověřování. Tento článek popisuje doporučení pro aktuální zákazníky, protože plánujete přestat používat Access Control. Pokud aktuálně nepoužíváte Access Control, nemusíte nic dělat.
Přehled
Access Control je cloudová ověřovací služba, která nabízí snadný způsob ověřování a autorizace uživatelů pro přístup k webovým aplikacím a službám. Umožňuje řadu funkcí ověřování a autorizace zohlednit mimo váš kód. Access Control primárně používají vývojáři a architekti klientů Microsoft .NET, ASP.NET webových aplikací a webových služeb WCF (Windows Communication Foundation).
Případy použití Access Control lze rozdělit do tří hlavních kategorií:
- Ověřování v určitých cloudových službách Microsoftu, včetně Azure Service Bus a Dynamics CRM. Klientské aplikace získávají tokeny od Access Control k ověření v těchto službách za účelem provádění různých akcí.
- Přidání ověřování do webových aplikací, jak vlastních, tak i předem zabalených (například SharePoint). Pomocí Access Control "pasivního" ověřování můžou webové aplikace podporovat přihlašování pomocí účtu Microsoft (dříve Live ID) a účtů od Googlu, Facebook, Yahoo, Azure AD a Active Directory Federation Services (AD FS) (AD FS).
- Zabezpečení vlastních webových služeb pomocí tokenů vydaných Access Control. Pomocí "aktivního" ověřování můžou webové služby zajistit, že povolí přístup jenom známým klientům, kteří se ověřili pomocí Access Control.
Každý z těchto případů použití a jejich doporučené strategie migrace jsou popsány v následujících částech.
Upozornění
Ve většině případů se k migraci stávajících aplikací a služeb na novější technologie vyžadují významné změny kódu. Doporučujeme, abyste okamžitě začali plánovat a provádět migraci, abyste se vyhnuli případným výpadkům nebo výpadkům.
Access Control má následující komponenty:
- Služba zabezpečených tokenů (STS), která přijímá žádosti o ověření a na oplátku vydává tokeny zabezpečení.
- Portál Azure Classic, kde můžete vytvářet, odstraňovat a povolovat a zakazovat obory názvů Access Control.
- Samostatný portál pro správu Access Control, kde můžete přizpůsobit a konfigurovat Access Control obory názvů.
- Služba pro správu, kterou můžete použít k automatizaci funkcí portálů.
- Modul pravidel transformace tokenů, který můžete použít k definování složité logiky pro manipulaci s výstupním formátem tokenů, které Access Control problémy.
Chcete-li tyto komponenty použít, musíte vytvořit jeden nebo více Access Control oborů názvů. Obor názvů je vyhrazená instance Access Control, se kterými vaše aplikace a služby komunikují. Obor názvů je izolovaný od všech ostatních zákazníků Access Control. Ostatní zákazníci Access Control používají vlastní obory názvů. Obor názvů v Access Control má vyhrazenou adresu URL, která vypadá takto:
https://<mynamespace>.accesscontrol.windows.net
Veškerá komunikace se službou STS a operace správy se provádí na této adrese URL. Různé cesty se používají pro různé účely. Pokud chcete zjistit, jestli vaše aplikace nebo služby používají Access Control, monitorujte provoz do https://< namespace.accesscontrol.windows.net>. Veškerý provoz na tuto adresu URL zpracovává Access Control a je potřeba ho ukončit.
Výjimkou jsou všechny přenosy do https://accounts.accesscontrol.windows.net. Provoz na tuto adresu URL už zpracovává jiná služba a vyřazení Access Control na tento provoz nemá vliv.
Další informace o Access Control najdete v tématu Access Control Service 2.0 (archivováno).
Zjistěte, které z vašich aplikací budou ovlivněny.
Postupujte podle kroků v této části a zjistěte, které z vašich aplikací budou vyřazením služby ACS ovlivněny.
Stažení a instalace prostředí ACS PowerShell
Přejděte na Galerie prostředí PowerShell a stáhněte si Acs.Namespaces.
Nainstalujte modul spuštěním příkazu .
Install-Module -Name Acs.NamespacesZískejte seznam všech možných příkazů spuštěním příkazu.
Get-Command -Module Acs.NamespacesPokud chcete získat nápovědu ke konkrétnímu příkazu, spusťte:
Get-Help [Command-Name] -Fullkde
[Command-Name]je název příkazu služby ACS.
Výpis oborů názvů služby ACS
Připojte se ke službě ACS pomocí rutiny Connect-AcsAccount .
Abyste mohli tyto příkazy spouštět, možná budete muset spustit
Set-ExecutionPolicy -ExecutionPolicy Bypasspříkazy a být správcem těchto předplatných.Vytvořte seznam dostupných předplatných Azure pomocí rutiny Get-AcsSubscription .
Výpis oborů názvů služby ACS pomocí rutiny Get-AcsNamespace
Kontrola ovlivněných aplikací
Použijte obor názvů z předchozího kroku a přejděte na
https://<namespace>.accesscontrol.windows.netPokud je například jeden z oborů názvů contoso-test, přejděte na
https://contoso-test.accesscontrol.windows.netV části Vztahy důvěryhodnosti vyberte Aplikace předávajících stran a zobrazte seznam aplikací, které budou ovlivněny vyřazením služby ACS.
Opakujte kroky 1 až 2 pro všechny ostatní obory názvů služby ACS, které máte.
Plán vyřazení z provozu
Od listopadu 2017 jsou všechny Access Control komponenty plně podporované a funkční. Jediným omezením je, že prostřednictvím portálu Azure Classic nemůžete vytvářet nové Access Control obory názvů.
Tady je plán pro vyřazení Access Control komponent:
- Listopad 2017: Prostředí pro správu Azure AD na portálu Azure Classic je vyřazené. V tomto okamžiku je správa oboru názvů pro Access Control k dispozici na nové vyhrazené adrese URL:
https://manage.windowsazure.com?restoreClassic=true. Pomocí této adresy URL můžete zobrazit existující obory názvů, povolit a zakázat obory názvů a odstranit obory názvů, pokud se tak rozhodnete. - 2. dubna 2018: Portál Azure Classic je úplně vyřazený, což znamená, že správa oboru názvů Access Control už není dostupná prostřednictvím žádné adresy URL. V tuto chvíli nemůžete obory názvů Access Control zakázat ani povolit, odstranit ani vypsat. Portál pro správu Access Control ale bude plně funkční a bude se nacházet na adrese
https://<namespace>.accesscontrol.windows.net. Všechny ostatní součásti Access Control nadále normálně fungovat. - 7. listopadu 2018: Všechny Access Control komponenty jsou trvale vypnuté. To zahrnuje portál pro správu Access Control, službu pro správu, službu tokenů zabezpečení a modul pravidel transformace tokenů. V tomto okamžiku všechny požadavky odeslané do Access Control (umístěné na
<namespace>.accesscontrol.windows.netadrese ) selžou. Před touto dobou jste měli migrovat všechny existující aplikace a služby na jiné technologie.
Poznámka
Zásada zakáže obory názvů, které po určitou dobu nepožadovaly token. Od začátku září 2018 je tato doba momentálně ve 14 dnech nečinnosti, ale v nadcházejících týdnech se zkrátí na 7 dnů nečinnosti. Pokud máte Access Control obory názvů, které jsou aktuálně zakázané, můžete stáhnout a nainstalovat ACS PowerShell a obory názvů znovu povolit.
Strategie migrace
Následující části popisují základní doporučení pro migraci z Access Control na jiné technologie Microsoftu.
Klienti cloudových služeb Microsoftu
Každá cloudová služba Microsoftu, která přijímá tokeny vydané Access Control, teď podporuje alespoň jednu alternativní formu ověřování. Správný mechanismus ověřování se u každé služby liší. Doporučujeme, abyste si oficiální pokyny pro každou službu projděte v konkrétní dokumentaci. Pro usnadnění je každá sada dokumentace k dispozici zde:
| Služba | Pokyny |
|---|---|
| Azure Service Bus | Migrace na sdílené přístupové podpisy |
| Azure Service Bus Relay | Migrace na sdílené přístupové podpisy |
| Azure Managed Cache | Migrace na Azure Cache for Redis |
| Azure DataMarket | Migrace na rozhraní API služeb Azure AI |
| BizTalk Services | Migrace na funkci Logic Apps Azure App Service |
| Azure Media Services | Migrace na ověřování Azure AD |
| Azure Backup | Upgrade agenta Azure Backup |
Zákazníci SharePointu
Zákazníci SharePointu 2013, 2016 a SharePointu Online už dlouho používají službu ACS pro účely ověřování v cloudových, místních a hybridních scénářích. Vyřazení služby ACS ovlivní některé funkce a případy použití služby SharePoint, zatímco jiné ne. Následující tabulka shrnuje pokyny k migraci pro některé z nejoblíbenějších funkcí SharePointu, které využívají službu ACS:
| Funkce | Pokyny |
|---|---|
| Ověřování uživatelů z Azure AD | Dříve Azure AD nepodporovala tokeny SAML 1.1 vyžadované SharePointem pro ověřování a služba ACS se používala jako zprostředkovatel, díky kterému byl SharePoint kompatibilní s formáty tokenů Azure AD. Teď můžete připojit SharePoint přímo k Azure AD pomocí místní aplikace Azure AD App Gallery SharePointu. |
| Ověřování aplikací & ověřování mezi servery v místním SharePointu | Není ovlivněno vyřazením služby ACS; nejsou nutné žádné změny. |
| Autorizace nízké důvěryhodnosti pro doplňky SharePointu (hostovaný zprostředkovatel a hostovaný SharePoint) | Není ovlivněno vyřazením služby ACS; nejsou nutné žádné změny. |
| Hybridní vyhledávání v cloudu SharePointu | Není ovlivněno vyřazením služby ACS; nejsou nutné žádné změny. |
Webové aplikace, které používají pasivní ověřování
Pro webové aplikace, které používají Access Control pro ověřování uživatelů, poskytuje Access Control vývojářům a architektům webových aplikací následující funkce a možnosti:
- Hloubková integrace se službou Windows Identity Foundation (WIF)
- Federace s účty Google, Facebook, Yahoo, Azure Active Directory a AD FS a účty Microsoft.
- Podpora následujících ověřovacích protokolů: OAuth 2.0 Draft 13, WS-Trust a WS-Federation (Web Services Federation).
- Podpora následujících formátů tokenů: JSON Web Token (JWT), SAML 1.1, SAML 2.0 a Simple Web Token (SWT).
- Prostředí pro zjišťování domovské sféry integrované do WIF, které uživatelům umožňuje vybrat typ účtu, který používají k přihlášení. Toto prostředí hostuje webová aplikace a je plně přizpůsobitelné.
- Transformace tokenu, která umožňuje rozsáhlé přizpůsobení deklarací identity přijaté webovou aplikací z Access Control, včetně:
- Předávání deklarací identity od zprostředkovatelů identity
- Přidání dalších vlastních deklarací identity
- Jednoduchá logika if-then pro vydávání deklarací identity za určitých podmínek.
Bohužel neexistuje žádná služba, která nabízí všechny tyto ekvivalentní funkce. Měli byste vyhodnotit, jaké funkce Access Control potřebujete, a pak zvolit mezi použitím id Microsoft Entra, Azure Active Directory B2C (Azure AD B2C) nebo jiné cloudové ověřovací služby.
Migrace na ID Microsoft Entra
Zvažte možnost přímé integrace aplikací a služeb s id Microsoft Entra. Microsoft Entra ID je cloudový zprostředkovatel identity pro pracovní nebo školní účty Microsoftu. Microsoft Entra ID je zprostředkovatel identity pro Microsoft 365, Azure a mnoho dalších. Poskytuje podobné možnosti federovaného ověřování jako Access Control, ale nepodporuje všechny funkce Access Control.
Primárním příkladem je federace s poskytovateli sociálních identit, jako jsou Facebook, Google a Yahoo. Pokud se uživatelé přihlašují pomocí těchto typů přihlašovacích údajů, Microsoft Entra ID pro vás není řešením.
Microsoft Entra ID také nemusí nutně podporovat přesně stejné ověřovací protokoly jako Access Control. Přestože například Access Control i ID Microsoft Entra podporují OAuth, mezi jednotlivými implementacemi existují drobné rozdíly. Různé implementace vyžadují, abyste v rámci migrace upravili kód.
Microsoft Entra ID ale poskytuje Access Control zákazníkům několik potenciálních výhod. Nativně podporuje pracovní nebo školní účty Microsoft hostované v cloudu, které běžně používají Access Control zákazníci.
Tenanta Microsoft Entra je také možné federovat do jedné nebo více instancí místní Active Directory prostřednictvím služby AD FS. Aplikace tak může ověřovat cloudové uživatele a uživatele hostované místně. Podporuje také protokol WS-Federation, což relativně usnadňuje integraci s webovou aplikací pomocí wif.
Následující tabulka porovnává funkce Access Control, které jsou relevantní pro webové aplikace, s funkcemi, které jsou k dispozici v Microsoft Entra ID.
Na vysoké úrovni je Microsoft Entra ID pravděpodobně nejlepší volbou pro vaši migraci, pokud uživatelům umožníte, aby se přihlašovali jenom pomocí svých pracovních nebo školních účtů Microsoft.
| Schopnost | podpora Access Control | Podpora id Microsoft Entra |
|---|---|---|
| Typy účtů | ||
| Pracovní nebo školní účty Microsoft | Podporováno | Podporováno |
| Účty z Windows Server Active Directory a AD FS | – Podporováno prostřednictvím federace s tenantem Microsoft Entra – Podporováno prostřednictvím přímé federace se službou AD FS |
Podporováno pouze prostřednictvím federace s tenantem Microsoft Entra |
| Účty z jiných systémů správy podnikových identit | – Možné prostřednictvím federace s tenantem Microsoft Entra – Podporováno prostřednictvím přímé federace |
Možné prostřednictvím federace s tenantem Microsoft Entra |
| Účty Microsoft pro osobní použití | Podporováno | Podporováno prostřednictvím protokolu OAuth Microsoft Entra verze 2.0, ale ne přes žádné jiné protokoly. |
| účty Facebook, Google, Yahoo | Podporováno | Nepodporováno vůbec |
| Kompatibilita protokolů a sady SDK | ||
| WIF | Podporuje se | Podporované, ale k dispozici jsou omezené pokyny |
| WS-Federation | Podporováno | Podporováno |
| OAuth 2.0 | Podpora pro koncept 13 | Podpora pro RFC 6749, nejmodernější specifikaci |
| WS-Trust | Podporováno | Nepodporováno |
| Formáty tokenů | ||
| JWT | Podporováno v beta verzi | Podporuje se |
| SAML 1.1 | Podporováno | Preview |
| SAML 2.0 | Podporováno | Podporováno |
| SWT | Podporováno | Nepodporováno |
| Vlastní nastavení | ||
| Přizpůsobitelné uživatelské rozhraní pro zjišťování domovské sféry nebo výběr účtu | Kód ke stažení, který je možné začlenit do aplikací | Nepodporováno |
| Nahrání vlastních podpisových certifikátů tokenů | Podporováno | Podporováno |
| Přizpůsobení deklarací identity v tokenech | - Předávání vstupních deklarací identity od zprostředkovatelů identity – Získání přístupového tokenu od zprostředkovatele identity jako deklarace identity – Vystavení výstupních deklarací identity na základě hodnot vstupních deklarací identity – Vystavení výstupních deklarací identity s konstantními hodnotami |
– Nejde předat deklarace identity od zprostředkovatelů federovaných identit – Nejde získat přístupový token od zprostředkovatele identity jako deklaraci identity – Nejde vydat výstupní deklarace identity založené na hodnotách vstupních deklarací identity. - Může vydávat výstupní deklarace identity s konstantními hodnotami. - Může vydávat výstupní deklarace identity na základě vlastností uživatelů synchronizovaných s ID Microsoft Entra. |
| Automation | ||
| Automatizace úloh konfigurace a správy | Podporováno prostřednictvím služby Access Control Management Service | Podpora při používání microsoft Graph API |
Pokud se rozhodnete, že Microsoft Entra ID je nejlepší způsob migrace pro vaše aplikace a služby, měli byste mít na paměti dva způsoby integrace aplikace s ID Microsoft Entra.
Pokud chcete k integraci s ID Microsoft Entra použít WS-Federation nebo WIF, doporučujeme postupovat podle postupu popsaného v tématu Konfigurace federovaného jednotného přihlašování pro aplikaci mimo galerii. Tento článek se týká konfigurace id Microsoft Entra pro jednotné přihlašování založené na SAML, ale funguje také při konfiguraci WS-Federation. Tento přístup vyžaduje licenci Microsoft Entra ID P1 nebo P2. Tento přístup má dvě výhody:
- Přizpůsobení tokenu Microsoft Entra vám umožňuje plnou flexibilitu. Deklarace identity vystavené id Microsoft Entra můžete přizpůsobit tak, aby odpovídaly deklaracím vystaveným Access Control. To zahrnuje zejména ID uživatele nebo deklaraci identity identifikátoru názvu. Pokud chcete i po změně technologií dál dostávat konzistentní identifikátory IDentifiers pro uživatele, ujistěte se, že ID uživatelů vystavená Microsoft Entra ID odpovídají ID vystaveným Access Control.
- Můžete nakonfigurovat podpisový certifikát tokenu, který je specifický pro vaši aplikaci a má životnost, kterou řídíte.
Poznámka
Tento přístup vyžaduje licenci Microsoft Entra ID P1 nebo P2. Pokud jste zákazníkem Access Control a k nastavení jednotného přihlašování pro aplikaci potřebujete prémiovou licenci, kontaktujte nás. Rádi vám poskytneme vývojářské licence, které můžete používat.
Alternativním přístupem je postupovat podle této ukázky kódu, která poskytuje mírně odlišné pokyny pro nastavení WS-Federation. Tento vzorový kód nepoužívá WIF, ale middleware ASP.NET 4.5 OWIN. Pokyny pro registraci aplikací jsou ale platné pro aplikace používající WIF a nevyžadují licenci Microsoft Entra ID P1 nebo P2.
Pokud zvolíte tento přístup, potřebujete porozumět přechodu na podpisový klíč ve Microsoft Entra ID. Tento přístup k vydávání tokenů používá globální podpisový klíč Microsoft Entra. Technologie WIF ve výchozím nastavení automaticky neaktualizuje podpisové klíče. Když Microsoft Entra ID obměně globální podpisové klíče, musí být implementace WIF připravená na přijetí změn. Další informace najdete v tématu Důležité informace o přechodu podpisového klíče v ID Microsoft Entra.
Pokud můžete integrovat s ID Microsoft Entra prostřednictvím protokolů OpenID Connect nebo OAuth, doporučujeme to udělat. V naší příručce pro vývojáře Microsoft Entra máme k dispozici rozsáhlou dokumentaci a pokyny k integraci ID Microsoft Entra do webové aplikace.
Migrace do Azure Active Directory B2C
Druhou možností migrace, kterou je potřeba zvážit, je Azure AD B2C. Azure AD B2C je cloudová ověřovací služba, která podobně jako Access Control umožňuje vývojářům zasoudět logiku ověřování a správy identit do cloudové služby. Jedná se o placenou službu (s úrovní Free a Premium), která je navržená pro aplikace určené pro spotřebitele, které můžou mít až miliony aktivních uživatelů.
Stejně jako Access Control je jednou z nejatraktivnějších vlastností Azure AD B2C to, že podporuje mnoho různých typů účtů. S Azure AD B2C můžete přihlašovat uživatele pomocí jejich účtu Microsoft nebo Facebook účtů Google, LinkedIn, GitHub nebo Yahoo a dalších. Azure AD B2C také podporuje "místní účty" neboli uživatelské jméno a hesla, které uživatelé vytvářejí speciálně pro vaši aplikaci. Azure AD B2C také poskytuje bohatou rozšiřitelnost, kterou můžete použít k přizpůsobení toků přihlašování.
Azure AD B2C ale nepodporuje rozsah ověřovacích protokolů a formátů tokenů, které Access Control zákazníci mohou vyžadovat. Nemůžete také použít Azure AD B2C k získání tokenů a dotazování na další informace o uživateli od zprostředkovatele identity, Od Microsoftu ani od jiného.
Následující tabulka porovnává funkce Access Control, které jsou relevantní pro webové aplikace, s funkcemi, které jsou k dispozici v Azure AD B2C. Na nejvyšší úrovni je Azure AD B2C pravděpodobně tou správnou volbou pro vaši migraci, pokud vaše aplikace čelí spotřebiteli nebo pokud podporuje mnoho různých typů účtů.
| Schopnost | podpora Access Control | Podpora Azure AD B2C |
|---|---|---|
| Typy účtů | ||
| Pracovní nebo školní účty Microsoft | Podporováno | Podporováno prostřednictvím vlastních zásad |
| Účty z Windows Server Active Directory a AD FS | Podpora prostřednictvím přímé federace se službou AD FS | Podpora prostřednictvím federace SAML s využitím vlastních zásad |
| Účty z jiných systémů pro správu podnikových identit | Podporováno prostřednictvím přímé federace prostřednictvím WS-Federation | Podpora prostřednictvím federace SAML s využitím vlastních zásad |
| Účty Microsoft pro osobní použití | Podporováno | Podporováno |
| účty Facebook, Google, Yahoo | Podporuje se | Facebook a Google podporují nativně, Yahoo prostřednictvím federace OpenID Connect pomocí vlastních zásad |
| Protokoly a kompatibilita sady SDK | ||
| Windows Identity Foundation (WIF) | Podporováno | Nepodporováno |
| WS-Federation | Podporováno | Nepodporováno |
| OAuth 2.0 | Podpora pro návrh 13 | Podpora pro RFC 6749, nejmodernější specifikaci |
| WS-Trust | Podporováno | Nepodporováno |
| Formáty tokenů | ||
| JWT | Podporováno v beta verzi | Podporuje se |
| SAML 1.1 | Podporováno | Nepodporováno |
| SAML 2.0 | Podporováno | Nepodporováno |
| SWT | Podporováno | Nepodporováno |
| Vlastní nastavení | ||
| Přizpůsobitelné uživatelské rozhraní pro zjišťování a vybírání účtů domovské sféry | Kód ke stažení, který je možné začlenit do aplikací | Plně přizpůsobitelné uživatelské rozhraní prostřednictvím vlastních šablon stylů CSS |
| Nahrání vlastních podpisových certifikátů tokenů | Podporuje se | Vlastní podpisové klíče, nikoli certifikáty, podporované prostřednictvím vlastních zásad |
| Přizpůsobení deklarací identity v tokenech | – Předávání vstupních deklarací identity od zprostředkovatelů identity – Získání přístupového tokenu od zprostředkovatele identity jako deklarace identity – Vystavení výstupních deklarací identity na základě hodnot vstupních deklarací identity – Vydání výstupních deklarací identity s konstantními hodnotami |
- Může předávat deklarace identity od zprostředkovatelů identity; Vlastní zásady vyžadované pro některé deklarace identity – Nejde získat přístupový token od zprostředkovatele identity jako deklarace identity. – Může vydávat výstupní deklarace identity založené na hodnotách vstupních deklarací identity prostřednictvím vlastních zásad. – Může vydávat výstupní deklarace identity s konstantními hodnotami prostřednictvím vlastních zásad. |
| Automation | ||
| Automatizace úloh konfigurace a správy | Podporováno prostřednictvím služby Access Control Management Service | - Vytváření uživatelů povoleno pomocí Microsoft Graph API – Nejde vytvářet tenanty, aplikace nebo zásady B2C prostřednictvím kódu programu |
Pokud se rozhodnete, že Azure AD B2C je nejlepší cestou migrace pro vaše aplikace a služby, začněte následujícími zdroji informací:
Migrace na identitu ping nebo ověřování 0
V některých případech můžete zjistit, že Microsoft Entra ID a Azure AD B2C nestačí k nahrazení Access Control ve webových aplikacích, aniž by došlo k zásadním změnám kódu. Mezi běžné příklady patří:
- Webové aplikace, které používají WIF nebo WS-Federation pro přihlášení k zprostředkovateli sociálních identit, jako je Google nebo Facebook.
- Webové aplikace, které provádějí přímou federaci ke zprostředkovateli podnikových identit přes protokol WS-Federation.
- Webové aplikace, které vyžadují přístupový token vydaný zprostředkovatelem sociální identity (například Googlem nebo Facebook) jako deklaraci identity v tokenech vystavených Access Control.
- Webové aplikace se složitými pravidly transformace tokenů, které Microsoft Entra ID nebo Azure AD B2C, nemůžou reprodukovat.
- Víceklientské webové aplikace, které používají službu ACS k centrální správě federace pro mnoho různých zprostředkovatelů identit
V těchto případech můžete zvážit migraci webové aplikace na jinou službu cloudového ověřování. Doporučujeme prozkoumat následující možnosti. Každá z následujících možností nabízí funkce podobné Access Control:
Auth0 je flexibilní cloudová služba identit, která vytvořila pokyny k migraci na vysoké úrovni pro zákazníky Access Control a podporuje téměř všechny funkce, které služba ACS dělá.
Ping Identity nabízí dvě řešení podobná službě ACS. PingOne je cloudová služba identit, která podporuje mnoho stejných funkcí jako ACS, a PingFederate je podobný místní produkt identity, který nabízí větší flexibilitu. Další podrobnosti o používání těchto produktů najdete v pokynech k vyřazení ACS společnosti Ping.
Naším cílem při práci s identitou Ping a ověřováním0 je zajistit, aby všichni Access Control zákazníci měli pro své aplikace a služby cestu migrace, která minimalizuje množství práce potřebné k přechodu z Access Control.
Webové služby, které používají aktivní ověřování
Pro webové služby, které jsou zabezpečené pomocí tokenů vydaných Access Control, nabízí Access Control následující funkce a možnosti:
- Možnost zaregistrovat jednu nebo více identit služeb v oboru názvů Access Control. Identity služby je možné použít k vyžádání tokenů.
- Podpora protokolů OAuth WRAP a OAuth 2.0 Draft 13 pro vyžádání tokenů pomocí následujících typů přihlašovacích údajů:
- Jednoduché heslo vytvořené pro identitu služby
- Podepsaný swt pomocí symetrického klíče nebo certifikátu X509
- Token SAML vydaný důvěryhodným zprostředkovatelem identity (obvykle instancí služby AD FS)
- Podpora následujících formátů tokenů: JWT, SAML 1.1, SAML 2.0 a SWT.
- Jednoduchá pravidla transformace tokenu.
Identity služeb v Access Control se obvykle používají k implementaci ověřování mezi servery.
Migrace na ID Microsoft Entra
Pro tento typ toku ověřování doporučujeme migrovat na Microsoft Entra ID. Microsoft Entra ID je cloudový zprostředkovatel identity pro pracovní nebo školní účty Microsoftu. Microsoft Entra ID je zprostředkovatel identity pro Microsoft 365, Azure a mnoho dalších.
Můžete také použít id Microsoft Entra pro ověřování mezi servery pomocí Microsoft Entra implementace udělení přihlašovacích údajů klienta OAuth. Následující tabulka porovnává možnosti Access Control při ověřování mezi servery s možnostmi, které jsou k dispozici v Microsoft Entra ID.
| Schopnost | podpora Access Control | Podpora id Microsoft Entra |
|---|---|---|
| Postup registrace webové služby | Vytvoření předávající strany na portálu pro správu Access Control | Vytvoření webové aplikace Microsoft Entra v Azure Portal |
| Postup registrace klienta | Vytvoření identity služby na portálu pro správu Access Control | Vytvoření další webové aplikace Microsoft Entra v Azure Portal |
| Použitý protokol | – Protokol OAuth WRAP – Udělení přihlašovacích údajů klienta OAuth 2.0 Koncept 13 |
Udělení přihlašovacích údajů klienta OAuth 2.0 |
| Metody ověřování klientů | - Jednoduché heslo - Podepsaný SWT – Token SAML od federovaného zprostředkovatele identity |
- Jednoduché heslo - Podepsaný JWT |
| Formáty tokenů | - JWT – SAML 1.1 – SAML 2.0 -SWT |
Jenom JWT |
| Transformace tokenu | – Přidání vlastních deklarací identity – Jednoduchá logika vystavování deklarací identity |
Přidání vlastních deklarací identity |
| Automatizace úloh konfigurace a správy | Podporováno prostřednictvím služby Access Control Management Service | Podpora při používání Graph API Microsoftu |
Pokyny k implementaci scénářů mezi servery najdete v následujících zdrojích informací:
- Část Service-to-Service v příručce pro vývojáře Microsoft Entra
- Ukázka kódu démona pomocí jednoduchých přihlašovacích údajů klienta s heslem
- Ukázka kódu démona pomocí přihlašovacích údajů klienta certifikátu
Migrace na identitu ping nebo ověřování 0
V některých případech můžete zjistit, že Microsoft Entra přihlašovací údaje klienta a implementace udělení OAuth nestačí k nahrazení Access Control ve vaší architektuře bez zásadních změn kódu. Mezi běžné příklady patří:
- Ověřování mezi servery pomocí jiných formátů tokenů než JWT.
- Ověřování mezi servery pomocí vstupního tokenu poskytnutého externím zprostředkovatelem identity.
- Ověřování mezi servery pomocí pravidel transformace tokenů, která Microsoft Entra ID nelze reprodukovat.
V těchto případech můžete zvážit migraci webové aplikace do jiné cloudové ověřovací služby. Doporučujeme prozkoumat následující možnosti. Každá z následujících možností nabízí funkce podobné Access Control:
Auth0 je flexibilní cloudová služba identit, která vytvořila pokyny k migraci na vysoké úrovni pro zákazníky Access Control a podporuje téměř všechny funkce, které služba ACS dělá.
Ping Identity , které nabízí dvě řešení podobná službě ACS. PingOne je cloudová služba identit, která podporuje mnoho stejných funkcí jako ACS, a PingFederate je podobný místní produkt identity, který nabízí větší flexibilitu. Další podrobnosti o používání těchto produktů najdete v pokynech k vyřazení ACS společnosti Ping.
Naším cílem při práci s identitou Ping a ověřováním0 je zajistit, aby všichni Access Control zákazníci měli pro své aplikace a služby cestu migrace, která minimalizuje množství práce potřebné k přechodu z Access Control.
Předávací ověřování
Pro předávací ověřování s transformací libovolného tokenu neexistuje ekvivalentní technologie Microsoftu se službou ACS. Pokud je to to, co vaši zákazníci potřebují, Auth0 může být ten, kdo poskytuje nejbližší aproximaci řešení.
Dotazy, připomínky a zpětná vazba
Chápeme, že mnoho zákazníků Access Control po přečtení tohoto článku nenajde jasnou cestu migrace. Možná budete potřebovat pomoc nebo pokyny k určení správného plánu. Pokud chcete probrat vaše scénáře migrace a dotazy, napište prosím komentář na této stránce.