Útmutató: Migrálás az Azure Access Control szolgáltatásból
Figyelmeztetés
Ez a tartalom a régebbi Azure AD 1.0-s verziójú végponthoz készült. Használja a Microsoft Identitásplatform új projektekhez.
A Microsoft Azure Access Control Service (ACS), az Azure Active Directory (Azure AD) szolgáltatása 2018. november 7-én megszűnik. A jelenleg Access Control használó alkalmazásokat és szolgáltatásokat addigra teljesen át kell telepíteni egy másik hitelesítési mechanizmusba. Ez a cikk a jelenlegi ügyfelekre vonatkozó javaslatokat ismerteti, mivel a Access Control használatának elavulását tervezi. Ha jelenleg nem használja a Access Control, nem kell semmilyen műveletet végrehajtania.
Áttekintés
Access Control egy felhőalapú hitelesítési szolgáltatás, amely egyszerű módot kínál a felhasználók hitelesítésére és engedélyezésére a webalkalmazásokhoz és -szolgáltatásokhoz való hozzáféréshez. Lehetővé teszi a hitelesítés és az engedélyezés számos funkciójának figyelembe vételét a kódból. Access Control elsősorban a Microsoft .NET-ügyfelek, ASP.NET webalkalmazások és a Windows Communication Foundation (WCF) webszolgáltatásainak fejlesztői és tervezői használják.
A Access Control használati esetei három fő kategóriába sorolhatók:
- Hitelesítés bizonyos Microsoft-felhőszolgáltatásokhoz, például Azure Service Bus és Dynamics CRM-hez. Az ügyfélalkalmazások jogkivonatokat szereznek be Access Control a szolgáltatások hitelesítéséhez különböző műveletek végrehajtásához.
- Hitelesítés hozzáadása webalkalmazásokhoz egyéni és előre csomagolt (például SharePoint) alkalmazásokhoz. A "passzív" hitelesítés Access Control használatával a webalkalmazások microsoftos fiókkal (korábbi nevén Live ID) és Google-, Facebook-, Yahoo-, Azure AD- és Active Directory összevonási szolgáltatások (AD FS) -fiókokkal (AD FS) támogathatják a bejelentkezést.
- Egyéni webszolgáltatások biztonságossá tétele a Access Control által kibocsátott jogkivonatokkal. Az "aktív" hitelesítés használatával a webszolgáltatások gondoskodhatnak arról, hogy csak az Access Control hitelesített ismert ügyfelekhez engedélyezzenek hozzáférést.
Ezeket a használati eseteket és azok javasolt migrálási stratégiáit az alábbi szakaszok ismertetik.
Figyelmeztetés
A legtöbb esetben jelentős kódmódosításokra van szükség a meglévő alkalmazások és szolgáltatások újabb technológiákba való migrálásához. Javasoljuk, hogy azonnal kezdje meg a migrálás megtervezését és végrehajtását, hogy elkerülje a lehetséges kimaradásokat és állásidőket.
Access Control a következő összetevőket tartalmazza:
- Egy biztonságos jogkivonat-szolgáltatás (STS), amely hitelesítési kéréseket fogad, és cserébe biztonsági jogkivonatokat ad ki.
- A klasszikus Azure-portál, ahol létrehozhat, törölhet és engedélyezhet és letilthat Access Control névtereket.
- Egy külön Access Control felügyeleti portál, ahol testre szabhatja és konfigurálhatja Access Control névtereket.
- Felügyeleti szolgáltatás, amellyel automatizálhatja a portálok funkcióit.
- Egy jogkivonat-átalakítási szabálymotor, amellyel összetett logikát definiálhat a problémákat Access Control jogkivonatok kimeneti formátumának módosításához.
Ezeknek az összetevőknek a használatához létre kell hoznia egy vagy több Access Control névteret. A névtér az alkalmazások és szolgáltatások által kommunikált Access Control dedikált példánya. A névtér el van különítve az összes többi Access Control ügyféltől. Más Access Control ügyfelek saját névtereket használnak. A Access Control névterének dedikált URL-címe a következőképpen néz ki:
https://<mynamespace>.accesscontrol.windows.net
Az STS-sel és a felügyeleti műveletekkel való kommunikáció ezen az URL-címen történik. Különböző célokra különböző elérési utakat használ. Annak megállapításához, hogy az alkalmazások vagy szolgáltatások használnak-e Access Control, figyelje meg a https://< namespace.accesscontrol.windows.net> felé irányuló forgalmat. Az URL-címre mutató forgalmat a Access Control kezeli, és meg kell szüntetni.
Ez alól kivételt képeznek a felé történő forgalom.https://accounts.accesscontrol.windows.net Az URL-címre mutató forgalmat már egy másik szolgáltatás kezeli, és a Access Control elavulása nem érinti.
A Access Control kapcsolatos további információkért lásd: Access Control Service 2.0 (archivált).
Megtudhatja, hogy melyik alkalmazásra lesz hatással
Az ebben a szakaszban található lépéseket követve megtudhatja, hogy melyik alkalmazásra lesz hatással az ACS kivonása.
Az ACS PowerShell letöltése és telepítése
Lépjen a PowerShell-galéria, és töltse le az Acs.Namespaces fájlt.
A modul telepítése a következő futtatásával:
Install-Module -Name Acs.NamespacesAz összes lehetséges parancs listájának lekérése a futtatással
Get-Command -Module Acs.NamespacesHa segítségre van szüksége egy adott parancshoz, futtassa a következőt:
Get-Help [Command-Name] -Fullahol
[Command-Name]az ACS-parancs neve.
Az ACS-névterek listázása
Csatlakozzon az ACS-hez a Connect-AcsAccount parancsmag használatával.
Előfordulhat, hogy a parancsok végrehajtásához futtatnia
Set-ExecutionPolicy -ExecutionPolicy Bypasskell a parancsokat, és az előfizetések rendszergazdájának kell lennie a parancsok végrehajtásához.Listázhatja az elérhető Azure-előfizetéseket a Get-AcsSubscription parancsmaggal.
Listázhatja az ACS-névtereket a Get-AcsNamespace parancsmaggal.
Annak ellenőrzése, hogy mely alkalmazások lesznek érintettek
Használja az előző lépésben használt névteret, és lépjen a
https://<namespace>.accesscontrol.windows.netHa például az egyik névtér contoso-test, lépjen a
https://contoso-test.accesscontrol.windows.netA Megbízhatósági kapcsolatok területen válassza a Függő entitásalkalmazások lehetőséget az ACS-kivezetés által érintett alkalmazások listájának megtekintéséhez.
Ismételje meg az 1–2. lépést minden más ACS-névtér(ek) esetében.
Kivezetés ütemezése
2017 novemberétől minden Access Control összetevő teljes mértékben támogatott és működőképes. Az egyetlen korlátozás az, hogy nem hozhat létre új Access Control névtereket a klasszikus Azure portálon keresztül.
Íme a Access Control összetevők elavulásának ütemezése:
- 2017. november: A klasszikus Azure portálon Azure AD rendszergazdai felület megszűnik. Ezen a ponton a Access Control névtérkezelése egy új, dedikált URL-címen érhető el:
https://manage.windowsazure.com?restoreClassic=true. Ezzel az URL-címmel megtekintheti a meglévő névtereket, engedélyezheti és letilthatja a névtereket, valamint törölheti a névtereket, ha úgy dönt. - 2018. április 2.: A klasszikus Azure-portál teljesen ki van vonva, ami azt jelenti, hogy Access Control névtér kezelése már nem érhető el URL-címen keresztül. Jelenleg nem tilthatja le, nem engedélyezheti, törölheti vagy számba veheti Access Control névtereit. A Access Control felügyeleti portál azonban teljes mértékben működőképes lesz, és a címen
https://<namespace>.accesscontrol.windows.nettalálható. A Access Control minden más összetevője továbbra is normálisan működik. - 2018. november 7.: Minden Access Control összetevő véglegesen leáll. Ez magában foglalja a Access Control felügyeleti portált, a felügyeleti szolgáltatást, az STS-t és a jogkivonat-átalakítási szabálymotort. Ezen a ponton az Access Control (a helyen
<namespace>.accesscontrol.windows.nettalálható) címre küldött kérések meghiúsulnak. Az összes meglévő alkalmazást és szolgáltatást már jóval korábban át kellett volna telepítenie más technológiákba.
Megjegyzés
A szabályzat letiltja azokat a névtereket, amelyek egy ideje nem kértek jogkivonatot. 2018. szeptember eleje óta ez az időtartam jelenleg 14 nap inaktivitást jelent, de ez a következő hetekben 7 nap inaktivitásra rövidül. Ha jelenleg le van tiltva Access Control névtér, letöltheti és telepítheti az ACS PowerShellt a névtér(ek) újbóli engedélyezéséhez.
Migrálási stratégiák
Az alábbi szakaszok a Access Control más Microsoft-technológiákba történő migrálásra vonatkozó magas szintű javaslatokat ismertetik.
A Microsoft felhőszolgáltatásainak ügyfelei
A Access Control által kibocsátott jogkivonatokat elfogadó Összes Microsoft-felhőszolgáltatás legalább egy alternatív hitelesítési formát támogat. A megfelelő hitelesítési mechanizmus minden szolgáltatás esetében eltérő. Javasoljuk, hogy hivatalos útmutatásért tekintse meg az egyes szolgáltatásokra vonatkozó dokumentációt. A kényelem érdekében minden dokumentációt itt talál:
| Szolgáltatás | Útmutató |
|---|---|
| Azure Service Bus | Migrálás megosztott hozzáférésű jogosultságkódokra |
| Azure Service Bus Relay | Migrálás megosztott hozzáférésű jogosultságkódokra |
| Azure Managed Cache | Migrálás az Azure Cache for Redisbe |
| Azure DataMarket | Migrálás az Azure AI-szolgáltatások API-jára |
| BizTalk Services | Migrálás a Azure App Service Logic Apps szolgáltatására |
| Azure Media Services | Migrálás Azure AD hitelesítésre |
| Azure Backup | Az Azure Backup-ügynök frissítése |
SharePoint-ügyfelek
A SharePoint 2013, 2016 és a SharePoint Online ügyfelei már régóta használják az ACS-t hitelesítési célokra a felhőben, a helyszínen és a hibrid forgatókönyvekben. Egyes SharePoint-funkciókat és használati eseteket az ACS kivezetése érint, míg mások nem. Az alábbi táblázat az ACS-t használó legnépszerűbb SharePoint-funkciók áttelepítési útmutatóját foglalja össze:
| Szolgáltatás | Útmutató |
|---|---|
| Felhasználók hitelesítése Azure AD | Korábban Azure AD nem támogatja a SharePoint által a hitelesítéshez szükséges SAML 1.1-jogkivonatokat, és az ACS-t közvetítőként használták, amely kompatibilissé tette a SharePointot Azure AD tokenformátumokkal. Mostantól közvetlenül csatlakoztathatja a SharePointot Azure AD a Azure AD Helyszíni SharePoint alkalmazással. |
| Alkalmazáshitelesítés & kiszolgálóról kiszolgálóra történő hitelesítés a helyszíni SharePointban | Az ACS kivezetése nem érinti; nincs szükség módosításokra. |
| Alacsony megbízhatósági engedélyezés a SharePoint-bővítményekhez (üzemeltetett szolgáltató és üzemeltetett SharePoint) | Az ACS kivezetése nem érinti; nincs szükség módosításokra. |
| Hibrid SharePoint-felhőbeli keresés | Az ACS kivezetése nem érinti; nincs szükség módosításokra. |
Passzív hitelesítést használó webalkalmazások
A felhasználói hitelesítéshez Access Control használó webalkalmazások esetében a Access Control a következő funkciókat és képességeket biztosítja a webalkalmazás-fejlesztők és -tervezők számára:
- A Windows Identity Foundation (WIF) mély integrációja.
- Összevonás Google-, Facebook-, Yahoo-, Azure Active Directory- és AD FS-fiókokkal és Microsoft-fiókokkal.
- A következő hitelesítési protokollok támogatása: OAuth 2.0 Draft 13, WS-Trust és Web Services Federation (WS-Federation).
- A következő jogkivonat-formátumok támogatása: JSON Web Token (JWT), SAML 1.1, SAML 2.0 és Simple Web Token (SWT).
- A WIF-be integrált otthoni tartományfelderítési felület, amellyel a felhasználók kiválaszthatják a bejelentkezéshez használt fiók típusát. Ezt a felületet a webalkalmazás üzemelteti, és teljes mértékben testre szabható.
- Jogkivonat-átalakítás, amely lehetővé teszi a webalkalmazás által a Access Control fogadott jogcímek részletes testreszabását, beleértve a következőket:
- Identitásszolgáltatóktól származó jogcímek továbbítása.
- További egyéni jogcímek hozzáadása.
- Egyszerű if-then logika a jogcímek bizonyos feltételek mellett történő kiadásához.
Sajnos nincs olyan szolgáltatás, amely az összes ilyen egyenértékű képességet kínálja. Ki kell értékelnie a szükséges Access Control képességeit, majd válasszon az Microsoft Entra ID, az Azure Active Directory B2C (Azure AD B2C) vagy egy másik felhőhitelesítési szolgáltatás használata közül.
Migrálás Microsoft Entra azonosítóra
A megfontolandó út az alkalmazások és szolgáltatások közvetlen integrálása Microsoft Entra azonosítóval. Microsoft Entra azonosító a Microsoft munkahelyi vagy iskolai fiókjai felhőalapú identitásszolgáltatója. Microsoft Entra azonosító a Microsoft 365, az Azure és még sok más identitásszolgáltatója. Hasonló összevont hitelesítési képességeket biztosít a Access Control, de nem támogatja az összes Access Control funkciót.
Az elsődleges példa a közösségi identitásszolgáltatókkal való összevonás, például a Facebook, a Google és a Yahoo. Ha a felhasználók ilyen típusú hitelesítő adatokkal jelentkeznek be, Microsoft Entra azonosító nem a megoldás.
Microsoft Entra azonosító szintén nem feltétlenül támogatja ugyanazokat a hitelesítési protokollokat, mint Access Control. Bár például Access Control és Microsoft Entra azonosító is támogatja az OAuthot, az egyes implementációk között apró különbségek vannak. A különböző implementációk megkövetelik, hogy a migrálás részeként módosítsa a kódot.
Azonban Microsoft Entra azonosító számos lehetséges előnyt biztosít Access Control ügyfelek számára. Natív módon támogatja a felhőben üzemeltetett Microsoft munkahelyi vagy iskolai fiókokat, amelyeket általában Access Control ügyfelek használnak.
A Microsoft Entra-bérlők az AD FS-en keresztül egy vagy több helyi Active Directory példányra is összevonhatók. Így az alkalmazás hitelesítheti a helyszínen üzemeltetett felhőalapú felhasználókat és felhasználókat. Támogatja a WS-Federation protokollt is, ami viszonylag egyszerűvé teszi a webalkalmazással való integrációt WIF használatával.
Az alábbi táblázat összehasonlítja a webalkalmazások szempontjából releváns Access Control funkcióit azokkal a funkciókkal, amelyek Microsoft Entra azonosítóban érhetők el.
Magas szinten Microsoft Entra azonosító valószínűleg a legjobb választás a migráláshoz, ha csak a Microsoft munkahelyi vagy iskolai fiókjával engedélyezi a felhasználóknak a bejelentkezést.
| Képesség | Access Control támogatás | Microsoft Entra azonosító támogatása |
|---|---|---|
| Fióktípusok | ||
| Microsoft munkahelyi vagy iskolai fiókok | Támogatott | Támogatott |
| Fiókok Windows Server Active Directory és AD FS-ből | – Összevonással támogatott Microsoft Entra bérlővel – Az AD FS-sel való közvetlen összevonással támogatott |
Csak összevonással támogatott Microsoft Entra bérlővel |
| Más vállalati identitáskezelő rendszerekből származó fiókok | – Összevonással lehetséges Microsoft Entra bérlővel – Közvetlen összevonással támogatott |
Összevonással lehetséges Microsoft Entra bérlővel |
| Microsoft-fiókok személyes használatra | Támogatott | A Microsoft Entra v2.0 OAuth protokollon keresztül támogatott, de más protokollon nem |
| Facebook, Google, Yahoo-fiókok | Támogatott | Egyáltalán nem támogatott |
| Protokollok és SDK-kompatibilitás | ||
| WIF | Támogatott | Támogatott, de korlátozott utasítások érhetők el |
| WS-Federation | Támogatott | Támogatott |
| OAuth 2.0 | A Piszkozat 13 támogatása | Az RFC 6749 támogatása, a legkorszerűbb specifikáció |
| WS-Trust | Támogatott | Nem támogatott |
| Jogkivonat-formátumok | ||
| JWT | Bétaverzióban támogatott | Támogatott |
| SAML 1.1 | Támogatott | Előnézet |
| SAML 2.0 | Támogatott | Támogatott |
| SWT | Támogatott | Nem támogatott |
| Testreszabások | ||
| Testreszabható otthoni tartományfelderítés/fiókválasztási felhasználói felület | Letölthető kód, amely beépíthető az alkalmazásokba | Nem támogatott |
| Egyéni jogkivonat-aláíró tanúsítványok feltöltése | Támogatott | Támogatott |
| Jogcímek testreszabása jogkivonatokban | - Identitásszolgáltatóktól származó bemeneti jogcímek továbbítása – Hozzáférési jogkivonat lekérése identitásszolgáltatótól jogcímként – Kimeneti jogcímek kiállítása bemeneti jogcímek értékei alapján – Kimeneti jogcímek kiállítása állandó értékekkel |
– Az összevont identitásszolgáltatóktól érkező jogcímek nem továbbíthatók – Nem lehet hozzáférési jogkivonatot lekérni az identitásszolgáltatótól jogcímként – A kimeneti jogcímek nem állíthatók ki bemeneti jogcímek értékei alapján – Kibocsáthat kimeneti jogcímeket állandó értékekkel – Kibocsáthat kimeneti jogcímeket a Microsoft Entra azonosítóval szinkronizált felhasználók tulajdonságai alapján |
| Automatizálás | ||
| Konfigurációs és felügyeleti feladatok automatizálása | A Access Control Management Service-en keresztül támogatott | Támogatott a Microsoft Graph API |
Ha úgy dönt, hogy az Microsoft Entra-azonosító a legjobb migrálási útvonal az alkalmazások és szolgáltatások számára, akkor tisztában kell lennie azzal, hogy kétféleképpen integrálhatja az alkalmazást Microsoft Entra azonosítóval.
Ha WS-Federation vagy WIF-et szeretne használni az Microsoft Entra-azonosítóval való integrációhoz, javasoljuk, hogy kövesse az összevont egyszeri bejelentkezés konfigurálása nem katalógusbeli alkalmazáshoz című témakört. A cikk az SAML-alapú egyszeri bejelentkezés Microsoft Entra-azonosítójának konfigurálására vonatkozik, de a WS-Federation konfigurálására is használható. Ennek a módszernek a követéséhez P1 vagy P2 azonosítójú Microsoft Entra-licencre van szükség. Ennek a megközelítésnek két előnye van:
- A jogkivonatok testreszabása Microsoft Entra teljes rugalmasságot teszi lehetővé. Testre szabhatja Microsoft Entra azonosító által kibocsátott jogcímeket, hogy megfeleljenek az Access Control által kiadott jogcímnek. Ez különösen a felhasználói azonosító vagy a névazonosító jogcímet foglalja magában. Ha a technológiák módosítása után is egységes felhasználói IDentifiers azonosítókat szeretne kapni a felhasználók számára, győződjön meg arról, hogy az Microsoft Entra azonosító által kibocsátott felhasználói azonosítók megegyeznek a Access Control által kiadott azonosítókkal.
- Konfigurálhat egy, az alkalmazásra jellemző jogkivonat-aláíró tanúsítványt egy Ön által szabályozható élettartammal.
Megjegyzés
Ehhez a megközelítéshez P1 vagy P2 azonosítójú Microsoft Entra licencre van szükség. Ha Ön Access Control ügyfél, és prémium szintű licencre van szüksége egy alkalmazás egyszeri bejelentkezésének beállításához, lépjen kapcsolatba velünk. Örömmel biztosítjuk a használathoz szükséges fejlesztői licenceket.
Alternatív megoldásként kövesse ezt a kódmintát, amely kissé eltérő utasításokat ad a WS-Federation beállításához. Ez a kódminta nem a WIF-et, hanem a ASP.NET 4.5 OWIN köztes szoftvert használja. Az alkalmazásregisztrációra vonatkozó utasítások azonban érvényesek a WIF-et használó alkalmazásokra, és nem igényelnek P1 vagy P2 azonosítójú Microsoft Entra-licencet.
Ha ezt a módszert választja, ismernie kell az aláírókulcs-váltást Microsoft Entra azonosítóban. Ez a módszer a Microsoft Entra globális aláírókulcsot használja a jogkivonatok kiállításához. Alapértelmezés szerint a WIF nem frissíti automatikusan az aláírókulcsokat. Amikor Microsoft Entra azonosító elforgatja a globális aláírókulcsait, a WIF-implementációnak készen kell állnia a módosítások elfogadására. További információ: Fontos információk az aláírókulcs-váltásról Microsoft Entra azonosítóban.
Ha integrálható Microsoft Entra-azonosítóval az OpenID Connect vagy az OAuth protokollon keresztül, javasoljuk, hogy tegye meg. A Microsoft Entra fejlesztői útmutatónkban található részletes dokumentációval és útmutatóval rendelkezünk arról, hogyan integrálható Microsoft Entra id a webalkalmazásba.
Migrálás az Azure Active Directory B2C-be
A másik megfontolandó migrálási útvonal a B2C Azure AD. Azure AD B2C egy felhőalapú hitelesítési szolgáltatás, amely a Access Control-hez hasonlóan lehetővé teszi a fejlesztők számára, hogy kiszervezzék hitelesítési és identitáskezelési logikájukat egy felhőszolgáltatásba. Ez egy fizetős (ingyenes és prémium szintű) szolgáltatás, amelyet olyan fogyasztói alkalmazásokhoz terveztek, amelyek akár több millió aktív felhasználóval is rendelkezhetnek.
A Access Control-hez hasonlóan a B2C Azure AD egyik legvonzóbb jellemzője, hogy számos különböző típusú fiókot támogat. A Azure AD B2C-vel microsoftos fiókjával, illetve Facebook, Google, LinkedIn, GitHub vagy Yahoo-fiókjával jelentkezhet be a felhasználókba, és így tovább. Azure AD B2C támogatja a "helyi fiókokat", illetve a felhasználók által kifejezetten az alkalmazáshoz létrehozott felhasználóneveket és jelszavakat. Azure AD B2C gazdag bővíthetőséget is biztosít, amellyel testre szabhatja a bejelentkezési folyamatokat.
Azonban Azure AD B2C nem támogatja az ügyfelek által megkövetelt hitelesítési protokollok és jogkivonat-formátumok Access Control. A Azure AD B2C nem használható jogkivonatok lekérésére és a felhasználóval kapcsolatos további információk lekérdezésére az identitásszolgáltatótól, a Microsofttól vagy más módon.
Az alábbi táblázat a webalkalmazások szempontjából releváns Access Control funkcióit hasonlítja össze az Azure AD B2C-ben elérhető funkciókkal. Magas szinten a Azure AD B2C valószínűleg a megfelelő választás a migráláshoz, ha az alkalmazás ügyféloldali, vagy ha számos különböző típusú fiókot támogat.
| Képesség | Access Control támogatás | Azure AD B2C-támogatás |
|---|---|---|
| Fióktípusok | ||
| Munkahelyi vagy iskolai Microsoft-fiókok | Támogatott | Egyéni szabályzatokkal támogatott |
| Fiókok Windows Server Active Directory és AD FS-ből | Az AD FS-sel való közvetlen összevonással támogatott | SAML-összevonással támogatott egyéni szabályzatok használatával |
| Más vállalati identitáskezelő rendszerekből származó fiókok | Közvetlen összevonással támogatott WS-Federation | SAML-összevonással támogatott egyéni szabályzatok használatával |
| Microsoft-fiókok személyes használatra | Támogatott | Támogatott |
| Facebook, Google, Yahoo-fiókok | Támogatott | Facebook és a Google natív módon támogatott, a Yahoo az OpenID Connect-összevonáson keresztül támogatott egyéni szabályzatok használatával |
| Protokollok és SDK-kompatibilitás | ||
| Windows Identity Foundation (WIF) | Támogatott | Nem támogatott |
| WS-Federation | Támogatott | Nem támogatott |
| OAuth 2.0 | A Draft 13 támogatása | Az RFC 6749 támogatása, a legkorszerűbb specifikáció |
| WS-Trust | Támogatott | Nem támogatott |
| Jogkivonat-formátumok | ||
| JWT | Bétaverzióban támogatott | Támogatott |
| SAML 1.1 | Támogatott | Nem támogatott |
| SAML 2.0 | Támogatott | Nem támogatott |
| SWT | Támogatott | Nem támogatott |
| Testreszabások | ||
| Testreszabható otthoni tartományfelderítés/fiókválasztási felhasználói felület | Letölthető kód, amely beépíthető az alkalmazásokba | Teljesen testre szabható felhasználói felület egyéni CSS-en keresztül |
| Egyéni jogkivonat-aláíró tanúsítványok feltöltése | Támogatott | Egyéni aláírási kulcsok, nem tanúsítványok, egyéni szabályzatokkal támogatottak |
| Jogcímek testreszabása jogkivonatokban | - Identitásszolgáltatóktól származó bemeneti jogcímek továbbítása – Hozzáférési jogkivonat lekérése identitásszolgáltatótól jogcímként – Kimeneti jogcímek kiállítása bemeneti jogcímek értékei alapján – Kimeneti jogcímek kiállítása állandó értékekkel |
- Átadhatja az identitásszolgáltatóktól származó jogcímeket; egyes jogcímekhez szükséges egyéni szabályzatok – Nem lehet hozzáférési jogkivonatot lekérni az identitásszolgáltatótól jogcímként – Kibocsáthat kimeneti jogcímeket a bemeneti jogcímek értékei alapján egyéni szabályzatokkal – Kibocsáthat állandó értékekkel rendelkező kimeneti jogcímeket egyéni szabályzatokkal |
| Automatizálás | ||
| Konfigurációs és felügyeleti feladatok automatizálása | A Access Control Management Service-en keresztül támogatott | – A Microsoft Graph API használatával engedélyezett felhasználók létrehozása – Nem hozhatók létre B2C-bérlők, alkalmazások vagy szabályzatok programozott módon |
Ha úgy dönt, hogy Azure AD B2C a legjobb migrálási útvonal az alkalmazások és szolgáltatások számára, kezdje az alábbi forrásokkal:
Migrálás pingelési identitásra vagy hitelesítésre0
Bizonyos esetekben előfordulhat, hogy Microsoft Entra azonosító és Azure AD B2C nem elegendő a webalkalmazásokban Access Control cseréjéhez anélkül, hogy jelentős kódmódosításokat végezne. Néhány gyakori példa:
- Olyan webalkalmazások, amelyek WIF-et vagy WS-Federation használnak a közösségi identitásszolgáltatókkal, például a Google-ral vagy Facebook való bejelentkezéshez.
- Olyan webalkalmazások, amelyek a WS-Federation protokollon keresztül végeznek közvetlen összevonást egy vállalati identitásszolgáltatóval.
- A közösségi identitásszolgáltató (például a Google vagy a Facebook) által kiállított hozzáférési jogkivonatot igénylő webalkalmazások jogcímként a Access Control által kibocsátott jogkivonatokban.
- Olyan összetett jogkivonat-átalakítási szabályokkal rendelkező webalkalmazások, amelyek Microsoft Entra azonosítót vagy Azure AD B2C-t nem tudnak reprodukálni.
- Több-bérlős webalkalmazások, amelyek az ACS-t használják számos különböző identitásszolgáltató összevonásának központi kezelésére
Ezekben az esetekben érdemes lehet a webalkalmazást egy másik felhőhitelesítő szolgáltatásba migrálni. Javasoljuk, hogy vizsgálja meg az alábbi lehetőségeket. Az alábbi lehetőségek mindegyike a Access Control-hez hasonló képességeket kínál:
Az Auth0 egy rugalmas felhőalapú identitásszolgáltatás, amely magas szintű migrálási útmutatót hozott létre a Access Control ügyfelei számára, és szinte minden olyan funkciót támogat, amelyet az ACS használ.
A Ping Identity két, az ACS-hez hasonló megoldást kínál. A PingOne egy olyan felhőalapú identitásszolgáltatás, amely az ACS-sel megegyező számos funkciót támogat, a PingFederate pedig egy hasonló helyszíni identitástermék, amely nagyobb rugalmasságot biztosít. A termékek használatával kapcsolatos további részletekért tekintse meg a Ping ACS kivezetési útmutatóját.
A Ping Identity és az Auth0 szolgáltatással való együttműködés célja annak biztosítása, hogy minden Access Control ügyfél rendelkezzen olyan migrálási útvonallal az alkalmazásaihoz és szolgáltatásaihoz, amely minimálisra csökkenti a Access Control való áthelyezéshez szükséges munkát.
Aktív hitelesítést használó webszolgáltatások
Az Access Control által kibocsátott jogkivonatokkal védett webszolgáltatások esetében a Access Control a következő funkciókat és képességeket kínálja:
- Egy vagy több szolgáltatásidentitás regisztrálása a Access Control névtérben. A szolgáltatásidentitások jogkivonatok lekérésére használhatók.
- Az OAuth WRAP és az OAuth 2.0 Piszkozat 13 protokoll támogatása a jogkivonatok lekéréséhez az alábbi hitelesítő adatokkal:
- A szolgáltatásidentitáshoz létrehozott egyszerű jelszó
- Aláírt SWT szimmetrikus kulccsal vagy X509-tanúsítvánnyal
- Egy megbízható identitásszolgáltató által kibocsátott SAML-jogkivonat (általában egy AD FS-példány)
- A következő jogkivonat-formátumok támogatása: JWT, SAML 1.1, SAML 2.0 és SWT.
- Egyszerű jogkivonat-átalakítási szabályok.
A Access Control szolgáltatásidentitásait általában a kiszolgálók közötti hitelesítés megvalósításához használják.
Migrálás Microsoft Entra azonosítóra
Az ilyen típusú hitelesítési folyamatra vonatkozó javaslatunk az, hogy migráljuk Microsoft Entra azonosítóra. Microsoft Entra azonosító a Munkahelyi vagy iskolai Microsoft-fiókok felhőalapú identitásszolgáltatója. Microsoft Entra id a Microsoft 365, az Azure és még sok más identitásszolgáltatója.
A Microsoft Entra-azonosítót a kiszolgálók közötti hitelesítéshez is használhatja az OAuth-ügyfél hitelesítő adatainak megadása Microsoft Entra implementálásával. Az alábbi táblázat összehasonlítja a kiszolgálók közötti hitelesítés Access Control képességeit az Microsoft Entra-azonosítóban elérhető képességekkel.
| Képesség | Access Control támogatás | Microsoft Entra-azonosító támogatása |
|---|---|---|
| Webszolgáltatás regisztrálása | Függő entitás létrehozása a Access Control felügyeleti portálon | Microsoft Entra-webalkalmazás létrehozása a Azure Portal |
| Ügyfél regisztrálása | Szolgáltatásidentitás létrehozása Access Control felügyeleti portálon | Hozzon létre egy másik Microsoft Entra webalkalmazást a Azure Portal |
| Használt protokoll | - OAuth WRAP protokoll - OAuth 2.0 Piszkozat 13 ügyfél hitelesítő adatainak megadása |
OAuth 2.0-ügyfél hitelesítő adatainak megadása |
| Ügyfél-hitelesítési módszerek | - Egyszerű jelszó - Aláírt SWT - SAML-jogkivonat összevont identitásszolgáltatótól |
- Egyszerű jelszó - Aláírt JWT |
| Jogkivonat-formátumok | -JWT - SAML 1.1 - SAML 2.0 -SWT |
Csak JWT |
| Jogkivonat-átalakítás | – Egyéni jogcímek hozzáadása – Egyszerű if-then jogcím kiállítási logika |
Egyéni jogcímek hozzáadása |
| Konfigurációs és felügyeleti feladatok automatizálása | A Access Control Management Service-en keresztül támogatott | Támogatott a Microsoft Graph API |
A kiszolgálók közötti forgatókönyvek implementálásával kapcsolatos útmutatásért tekintse meg a következő forrásanyagokat:
- A Microsoft Entra fejlesztői útmutató szolgáltatásközi szakasza
- Démonkódminta egyszerű jelszóügyfél hitelesítő adataival
- Démonkódminta tanúsítványügyfél hitelesítő adatainak használatával
Migrálás pingelési identitásra vagy hitelesítésre0
Bizonyos esetekben előfordulhat, hogy a Microsoft Entra ügyfél-hitelesítő adatok és az OAuth-támogatás implementációja nem elegendő a Access Control jelentős kódmódosítások nélküli cseréjéhez az architektúrában. Néhány gyakori példa:
- Kiszolgálóról kiszolgálóra történő hitelesítés jWT-k kivételével jogkivonat-formátumokkal.
- Kiszolgálóról kiszolgálóra történő hitelesítés külső identitásszolgáltató által biztosított bemeneti jogkivonattal.
- Olyan jogkivonat-átalakítási szabályokkal rendelkező kiszolgálóról kiszolgálóra történő hitelesítés, amelyet Microsoft Entra azonosító nem tud reprodukálni.
Ezekben az esetekben megfontolhatja a webalkalmazás másik felhőhitelesítési szolgáltatásba való migrálását. Javasoljuk, hogy vizsgálja meg az alábbi lehetőségeket. Az alábbi lehetőségek mindegyike a Access Control hasonló képességeket kínál:
Az Auth0 egy rugalmas felhőalapú identitásszolgáltatás, amely magas szintű migrálási útmutatót hozott létre az Access Control ügyfelei számára, és szinte minden olyan funkciót támogat, amelyet az ACS tesz.
Ping Identity két, az ACS-hez hasonló megoldást kínál. A PingOne egy felhőalapú identitásszolgáltatás, amely az ACS-hez hasonló funkciókat támogat, a PingFederate pedig egy hasonló helyszíni identitástermék, amely nagyobb rugalmasságot biztosít. A termékek használatával kapcsolatos további részletekért tekintse meg a Ping ACS-kivonási útmutatóját.
A Ping Identity és az Auth0 szolgáltatással való együttműködés célja annak biztosítása, hogy minden Access Control ügyfél rendelkezik olyan migrálási útvonallal az alkalmazásaikhoz és szolgáltatásaikhoz, amely minimálisra csökkenti a Access Control való áthelyezéshez szükséges munkát.
Átmenő hitelesítés
Tetszőleges jogkivonat-átalakítással történő átengedési hitelesítéshez nincs egyenértékű Microsoft-technológia az ACS-vel. Ha erre van szüksége az ügyfeleknek, az Auth0 lehet az, aki a legközelebbi közelítő megoldást nyújtja.
Kérdések, aggodalmak és visszajelzések
Tisztában vagyunk azzal, hogy sok Access Control ügyfél nem talál egyértelmű migrálási útvonalat a cikk elolvasása után. Előfordulhat, hogy segítségre vagy útmutatásra van szüksége a megfelelő terv meghatározásához. Ha meg szeretné beszélni a migrálási forgatókönyveket és kérdéseket, írjon megjegyzést ezen az oldalon.