Kurz: Konfigurace identity ping pomocí Azure Active Directory B2C pro zabezpečený hybridní přístup

V tomto kurzu se dozvíte, jak rozšířit možnosti Azure Active Directory B2C (Azure AD B2C) o PingAccess a PingFederate. PingAccess poskytuje přístup k aplikacím a rozhraním API a modul zásad pro autorizovaný přístup uživatelů. PingFederate je podnikový federační server pro ověřování uživatelů a jednotné přihlašování, který umožňuje zákazníkům, zaměstnancům a partnerům přístup k aplikacím ze zařízení. Použijte je společně k povolení zabezpečeného hybridního přístupu (SHA).

Mnoho webů elektronického obchodování a webových aplikací vystavených na internetu je nasazených za proxy systémy nebo systémem reverzního proxy serveru. Tyto proxy systémy předem ověřují, vynucují zásady a směrují provoz. Mezi typické scénáře patří ochrana webových aplikací před příchozím webovým provozem a zajištění jednotné správy relací napříč nasazeními distribuovaných serverů.

Obecně platí, že konfigurace zahrnují vrstvu překladu ověřování, která externalizuje ověřování z webové aplikace. Reverzní proxy servery poskytují ověřený uživatelský kontext webovým aplikacím, jako je například hodnota hlavičky ve formě clear nebo digest. Aplikace nepoužívají standardní tokeny, jako jsou SAML (Security Assertion Markup Language), OAuth nebo OpenID Connect (OIDC). Místo toho proxy poskytuje kontext ověřování a udržuje relaci s agentem koncového uživatele, jako je prohlížeč nebo nativní aplikace. Proxy servery jako služba běžící jako man-in-the-middle poskytují významnou kontrolu nad relacemi. Služba proxy je efektivní a škálovatelná, nikoli kritický bod pro aplikace za proxy službou. Diagram je reverzní proxy implementace a tok komunikace.

Modernizace

Pokud chcete v takových konfiguracích modernizovat platformu identity, můžou se jednat o zákazníky:

• Oddělte úsilí o modernizaci aplikací od modernizace platformy identit.
• Prostředí s moderním a starším ověřováním, která využívají modernizovaného zprostředkovatele služeb identit
  • Zajištění konzistence prostředí koncového uživatele
  • Poskytování jednotného přihlašování napříč aplikacemi

V odpovědi na tyto obavy je přístup v tomto kurzu integrace Azure AD B2C, PingAccess a PingFederate.

Sdílené prostředí

Technicky proveditelným a nákladově efektivním řešením je nakonfigurovat systém reverzního proxy serveru tak, aby používal modernizovaný systém identit a delegoval ověřování.
Proxy servery podporují moderní ověřovací protokoly a používají ověřování založené na přesměrování (pasivní), které odesílá uživatele novému zprostředkovateli identity (IdP).

Azure AD B2C jako zprostředkovatel identity

V Azure AD B2C definujete zásady, které řídí uživatelské prostředí a chování, označované také jako cesty uživatelů. Každá taková zásada zveřejňuje koncový bod protokolu, který může provádět ověřování jako zprostředkovatel identity. Na straně aplikace se pro určité zásady nevyžaduje žádné zvláštní zpracování. Aplikace odešle standardní žádost o ověření koncovému bodu ověřování specifickému pro protokol, který jsou vystaveny zásadami.
Můžete nakonfigurovat Azure AD B2C tak, aby sdílel stejného vystavitele napříč zásadami nebo jedinečného vystavitele pro každou zásadu. Každá aplikace může odkazovat na zásady tím, že vytvoří požadavek na ověření nativní pro protokol, který řídí chování uživatelů, jako je přihlášení, registrace a úpravy profilu. Diagram znázorňuje pracovní postupy aplikací OIDC a SAML.

Scénář může být náročný na to, aby starší aplikace přesměrovávají uživatele přesně. Žádost o přístup k aplikacím nemusí obsahovat kontext uživatelského prostředí. Ve většině případů vrstva proxy serveru nebo integrovaný agent ve webové aplikaci zachytí žádost o přístup.

Reverzní proxy server PingAccess

PingAccess můžete nasadit jako reverzní proxy server. PingAccess zachytí přímý požadavek tím, že je man-in-the-middle, nebo jako přesměrování z agenta běžícího na webovém aplikačním serveru.

Nakonfigurujte PingAccess pomocí OIDC, OAuth2 nebo SAML pro ověřování pomocí nadřazeného zprostředkovatele ověřování. Pro tento účel můžete nakonfigurovat upstreamového zprostředkovatele identity na serveru PingAccess. Podívejte se na následující diagram.

V typickém nasazení Azure AD B2C se zásadami zpřístupňujícími zprostředkovatele identity je problém. PingAccess je nakonfigurovaný s jedním upstreamovým zprostředkovatele identity.

Proxy federace PingFederate

PingFederate můžete nakonfigurovat jako zprostředkovatele ověřování nebo proxy server pro upstreamové zprostředkovatele identity. Podívejte se na následující diagram.

Pomocí této funkce můžete kontextově, dynamicky nebo deklarativně přepnout příchozí požadavek na zásadu Azure AD B2C. Podívejte se na následující diagram toku posloupnosti protokolů.

Požadavky

Abyste mohli začít, budete potřebovat:

• Předplatné Azure
  • Pokud ho nemáte, získejte bezplatný účet Azure.
• Tenant Azure AD B2C propojený s vaším předplatným Azure
• PingAccess a PingFederate nasazené v kontejnerech Dockeru nebo na virtuálních počítačích Azure

Připojení a komunikace

Potvrďte následující připojení a komunikaci.

• Server PingAccess – komunikuje se serverem PingFederate, klientským prohlížečem, OIDC, známým OAuth a zjišťováním klíčů publikovaným službou Azure AD B2C a serverem PingFederate.
• Server PingFederate – komunikuje se serverem PingAccess, klientským prohlížečem, OIDC, známým OAuth a zjišťováním klíčů publikovanými službou Azure AD B2C.
• Starší aplikace AuthN nebo aplikace AuthN založená na hlavičce – komunikuje se serverem PingAccess a z ní
• Aplikace předávající strany SAML – dosáhne provozu prohlížeče z klienta. Přistupuje k metadatům federace SAML publikovaným službou Azure AD B2C.
• Moderní aplikace – dosáhne provozu prohlížeče z klienta. Přistupuje ke zjišťování dobře známých klíčů OIDC, OAuth a klíčů publikovaným službou Azure AD B2C.
• ROZHRANÍ REST API – dosáhne provozu z nativního nebo webového klienta. Přistupuje ke zjišťování dobře známých klíčů OIDC, OAuth a klíčů publikovaným službou Azure AD B2C.

Konfigurace Azure AD B2C

Můžete použít základní toky uživatelů nebo pokročilé zásady IEF (Identity Enterprise Framework). PingAccess vygeneruje koncový bod metadat na základě hodnoty vystavitele pomocí protokolu WebFinger pro konvenci zjišťování. Pokud chcete postupovat podle této konvence, aktualizujte vystavitele Azure AD B2C pomocí vlastností zásad toku uživatele.

V pokročilých zásadách konfigurace zahrnuje element metadat IssuanceClaimPattern do hodnoty AuthorityWithTfp v technickém profilu vystavitele tokenu JWT.

Konfigurace PingAccess a PingFederate

Podle pokynů v následujících částech nakonfigurujte PingAccess a PingFederate. Podívejte se na následující diagram celkového toku uživatele integrace.

Konfigurace PingFederate jako poskytovatele tokenu

Pokud chcete nakonfigurovat PingFederate jako poskytovatele tokenů pro PingAccess, zajistěte připojení z PingFederate k PingAccess. Ověřte připojení z PingAccessu k PingFederate.

Další informace najdete v tématu Konfigurace PingFederate jako zprostředkovatele tokenu pro PingAccess v dokumentaci ping identity.

Konfigurace aplikace PingAccess pro ověřování na základě hlaviček

Pomocí následujících pokynů vytvořte aplikaci PingAccess pro cílovou webovou aplikaci pro ověřování na základě hlaviček.

Vytvoření virtuálního hostitele

Důležité

Vytvořte virtuálního hostitele pro každou aplikaci. Další informace najdete v tématu Co můžu nakonfigurovat pomocí PingAccess? v dokumentaci k identitě ping.

Vytvoření virtuálního hostitele:

1. Přejděte na Nastavení>Přístup k virtuálním>hostitelům.
2. Vyberte Přidat virtuálního hostitele.
3. Jako Hostitel zadejte část plně kvalifikovaného názvu domény adresy URL aplikace.
4. Jako Port zadejte 443.
5. Vyberte Uložit.

Vytvoření webové relace

Vytvoření webové relace:

1. Přejděte na Nastavení>webových relacípřístupu>.
2. Vyberte Přidat webovou relaci.
3. Zadejte Název webové relace.
4. Vyberte Typ souboru cookie: Podepsaný JWT nebo Šifrovaný JWT.
5. Zadejte jedinečnou hodnotu pro cílovou skupinu.
6. Jako ID klienta zadejte ID aplikace Microsoft Entra.
7. Jako Tajný klíč klienta zadejte klíč, který jste vygenerovali pro aplikaci v Microsoft Entra ID.
8. (Volitelné) Vytváření a používání vlastních deklarací identity s Microsoft Graph API: Vyberte Upřesnit. Zrušte výběr možnosti Profil žádosti a Aktualizovat atributy uživatele. Další informace o vlastních deklarací identity: Jednotné přihlašování založené na hlavičkách pro místní aplikace s Microsoft Entra proxy aplikací.
9. Vyberte Uložit.

Vytvoření mapování identit

Poznámka

Mapování identit můžete použít u více než jedné aplikace, pokud v hlavičce očekávají stejná data.

Vytvoření mapování identit:

1. Přejděte na Nastavení>Mapování identit přístupu>.
2. Vyberte Přidat mapování identit.
3. Zadejte *Název.
4. Vyberte typ mapování identit pro mapování identity hlaviček.
5. V tabulce Attribute-Mapping (Mapování atributů ) zadejte požadovaná mapování. Třeba

Název atributu	Název hlavičky
Upn	x-userprincipalname
'e-mail'	x-mail
'oid'	x-oid
'scp'	x-scope
'amr'	x-amr

6. Vyberte Uložit.

Vytvoření lokality

Poznámka

V některých konfiguracích může lokalita obsahovat více aplikací. Pokud je to vhodné, můžete web použít s více než jednou aplikací.

Vytvoření webu:

1. Přejděte na hlavní>weby.
2. Vyberte Přidat web.
3. Zadejte název webu.
4. Zadejte cíl webu. Cílem je pár název hostitele a port pro server, který je hostitelem aplikace. Do tohoto pole nezadávejte cestu k aplikaci. Například aplikace na adrese https://mysite:9999/AppName má cílovou hodnotu můj web:9999.
5. Uveďte, jestli cíl očekává zabezpečená připojení.
6. Pokud cíl očekává zabezpečená připojení, nastavte skupinu důvěryhodných certifikátů na Důvěřovat všem.
7. Vyberte Uložit.

Vytvoření aplikace

Vytvoření aplikace v PingAccessu pro každou aplikaci v Azure, kterou chcete chránit.

1. Přejít na hlavní>aplikace

2. Vyberte Přidat aplikaci.

3. Zadejte název aplikace.

4. Volitelně můžete zadat popis aplikace.

5. Zadejte kořen kontextu pro aplikaci. Například aplikace na adrese https://mysite:9999/AppName bude mít kořen kontextu /AppName. Kořen kontextu musí začínat lomítkem (/), nesmí končit lomítkem (/) a může mít hloubku více než jedné vrstvy, například /Apps/MyApp.

6. Vyberte virtuálního hostitele , který jste vytvořili.

   Poznámka

   Kombinace virtuálního hostitele a kořene kontextu musí být v PingAccessu jedinečná.

7. Vyberte webovou relaci , kterou jste vytvořili.

8. Vyberte web , který jste vytvořili a který obsahuje aplikaci.

9. Vyberte mapování identit , které jste vytvořili.

10. Výběrem možnosti Povoleno povolíte web při ukládání.

11. Vyberte Uložit.

Konfigurace zásad ověřování PingFederate

Nakonfigurujte zásady ověřování PingFederate tak, aby se federoval s několika zprostředkovatele identity, které poskytují tenanti Azure AD B2C.

1. Vytvořte kontrakt pro přemostí atributy mezi zprostředkovatele identity a instančním objektem. Pokud objekt SP nevyžaduje od každého zprostředkovatele identity jinou sadu atributů, měli byste potřebovat pouze jeden kontrakt. Další informace najdete v tématu Kontrakty centra federace a zásad ověřování v dokumentaci Ping Identity.

2. Pro každého zprostředkovatele identity vytvořte připojení zprostředkovatele identity mezi zprostředkovatelem identity a PingFederate, centrem federace jako sp.

3. V okně Mapování cílové relace přidejte příslušné kontrakty zásad ověřování do připojení zprostředkovatele identity.

4. V okně Selektory nakonfigurujte selektor ověřování. Podívejte se například na instanci adaptéru Identifier First , která mapuje jednotlivé zprostředkovatele identity na odpovídající připojení zprostředkovatele identity v zásadách ověřování.

5. Vytvořte připojení SP mezi PingFederate, centrem federace jako zprostředkovatelem identity a sp.

6. V okně Mapování zdroje ověřování přidejte odpovídající kontrakt zásad ověřování do připojení SP.

7. Pracujte s jednotlivými zprostředkovatele identity a připojte se k PingFederate, což je centrum federace jako sp.

8. Připojte se ke službě PingFederate, což je centrum federace jako zprostředkovatele identity.

Další kroky

Další informace najdete v následujících článcích.

• Vlastní zásady v Azure AD B2C

• Začínáme s vlastními zásadami v Azure AD B2C