Sdílet prostřednictvím

Scénář – Zabezpečení přístupu k platformám a aplikacím SAP pomocí ID Microsoft Entra

  • Článek

Tento dokument obsahuje rady k technickému návrhu a konfiguraci platforem a aplikací SAP při použití ID Microsoft Entra jako primární služby ověřování uživatelů pro služby SAP Cloud Identity Services. Sap Cloud Identity Services zahrnuje ověřování identit, zřizování identit, adresář identit a správu autorizace. Přečtěte si další informace o počátečním nastavení ověřování v integraci jednotného přihlašování (SSO) Microsoft Entra s kurzem SAP Cloud Identity Services. Další informace o zřizování a dalších scénářích najdete v tématu Plánování nasazení Microsoft Entra pro zřizování uživatelů pomocí zdrojové a cílové aplikace SAP a správa přístupu k vašim aplikacím SAP.

Terminologie použitá v této příručce

Zkratka Popis
BTP SAP Business Technology Platform je inovační platforma optimalizovaná pro aplikace SAP v cloudu. Většina zde probíraných technologií SAP je součástí BTP. Produkty, které se formálně označují jako SAP Cloud Platform, jsou součástí SAP BTP.
IAS SAP Cloud Identity Services – Ověřování identit, součást služby SAP Cloud Identity Services, je cloudová služba pro ověřování, jednotné přihlašování a správu uživatelů v cloudových a místních aplikacích SAP. SLUŽBA IAS pomáhá uživatelům ověřovat se svými vlastními instancemi služby SAP BTP jako proxy, který se integruje s jednotným přihlašováním Microsoft Entra.
IPS SAP Cloud Identity Services – Zřizování identit, součást SAP Cloud Identity Services, je cloudová služba, která pomáhá zřizovat identity a jejich autorizaci pro cloud a místní aplikaci SAP.
XSUAA Rozšířené služby pro uživatelský účet a ověřování Cloud Foundry Cloud Foundry, platforma jako služba (PaaS), která se dá nasadit na různé infrastruktury, je prostředí, na kterém SAP vytvořil platformu SAP Business Technology Platform. XSUAA je víceklientská autorizační server OAuth, který je centrální komponentou infrastruktury prostředí Cloud Foundry. XSUAA poskytuje ověřování a autorizaci podnikových uživatelů v rámci SAP BTP.
Fiori Webové uživatelské prostředí SAP (na rozdíl od desktopového prostředí)

Přehled

V zásobníku technologií SAP a Microsoftu existuje mnoho služeb a komponent, které hrají roli ve scénářích ověřování a autorizace uživatelů. Hlavní služby jsou uvedené v následujícím diagramu.

Přehled architektury SAP na šířku

Vzhledem k tomu, že je možné nakonfigurovat mnoho permutací možných scénářů, zaměřujeme se na jeden scénář, který je v souladu s první strategií identity Microsoft Entra. Provedeme následující předpoklady:

  • Chcete řídit všechny své identity centrálně a pouze z Microsoft Entra ID.
  • Chcete omezit úsilí o údržbu co nejvíce a automatizovat přístup k ověřování a aplikacím v rámci Microsoftu a SAP.
  • Obecné pokyny pro Microsoft Entra ID s IAS platí pro aplikace nasazené v BTP a aplikacích SAP SaaS nakonfigurovaných v IAS. Konkrétní doporučení se zobrazí také tam, kde je to možné pro BTP (například použití mapování rolí se skupinami Microsoft Entra) a aplikací SAP SaaS (například použití služby zřizování identit pro autorizaci na základě role).
  • Předpokládáme také, že uživatelé jsou již zřízeni v Microsoft Entra ID a vůči všem systémům SAP, které vyžadují, aby uživatelé byli zřízeni pro fungování. Bez ohledu na to, jak toho bylo dosaženo: zřizování mohlo projít ručně, od místní Active Directory přes Microsoft Entra Připojení nebo prostřednictvím systémů personálního oddělení, jako je SAP SuccessFactors. V tomto dokumentu se proto successFactors považuje za aplikaci jako jakoukoli jinou, ke které se budou (stávající) uživatelé přihlašovat. Nepokrýváme skutečné zřizování uživatelů z SuccessFactors do Microsoft Entra ID. Další informace o přenesení uživatelů do Microsoft Entra ID pro použití s úlohami SAP najdete v tématu plánování nasazení Microsoft Entra pro zřizování uživatelů pomocí zdrojové a cílové aplikace SAP a správa přístupu k vašim aplikacím SAP.

Na základě těchto předpokladů se zaměříme hlavně na produkty a služby uvedené v následujícím diagramu. Jedná se o různé komponenty, které jsou pro ověřování a autorizaci v cloudovém prostředí nejrelevantní.

Služby SAP v oboru

Pokud používáte SAP Identity Management (IDM), můžete migrovat scénáře správy identit ze SAP IDM do Microsoft Entra. Další informace najdete v tématu Migrace scénářů správy identit ze SAP IDM do Microsoft Entra.

Poznámka:

Většina těchto pokynů platí i pro Azure Active Directory B2C , ale existují některé důležité rozdíly. Další informace najdete v tématu Použití Azure AD B2C jako zprostředkovatele identity.

Upozorňující

Mějte na paměti limity kontrolních výrazů SAP SAML a vliv na délku názvů kolekcí rolí SAP Cloud Foundry a množství kolekcí, které jsou proxidovány skupinami ve službě SAP Cloud Identity Service. Další informace najdete v poznámkách SAP 2732890 v SAP for Me. Překročení limitů vede k problémům s autorizací.

Doporučení

Shrnutí

1. Použití federovaného ověřování v platformě SAP Business Technology Platform a aplikacích SAP SaaS prostřednictvím služby SAP Identity Authentication Service

Kontext

Vaše aplikace v BTP můžou pomocí zprostředkovatelů identity prostřednictvím konfigurací důvěryhodnosti ověřovat uživatele pomocí protokolu SAML 2.0 mezi BTP/XSUAA a zprostředkovatelem identity. Všimněte si, že se podporuje jenom SAML 2.0, i když se mezi samotnou aplikací a BTP/XSUAA používá protokol OpenID Připojení (v tomto kontextu to není relevantní).

V BTP můžete nastavit konfiguraci důvěryhodnosti pro SAP Cloud Identity Services – Ověřování identit (což je výchozí), ale pokud je váš autoritativní uživatelský adresář Microsoft Entra ID, můžete nastavit federaci tak, aby se uživatelé mohli přihlásit pomocí svých stávajících účtů Microsoft Entra.

Kromě federace můžete volitelně také nastavit zřizování uživatelů tak, aby se uživatelé Microsoft Entra zřídili předem v BTP. Neexistuje však žádná nativní podpora (pouze pro Microsoft Entra ID –> SAP Identity Authentication Service), integrované řešení s nativní podporou by byla služba BTP Identity Provisioning. Zřizování uživatelských účtů předem může být užitečné pro autorizační účely (například pro přidání uživatelů do rolí). V závislosti na požadavcích toho ale můžete dosáhnout také pomocí skupin Microsoft Entra (viz níže), což může znamenat, že vůbec nepotřebujete zřizování uživatelů.

Při nastavování federačního vztahu existuje několik možností:

  • Můžete se rozhodnout federovat směrem k Microsoft Entra ID přímo z BTP/XSUAA.
  • Můžete se rozhodnout federovat s IAS, který je zase nastavený tak, aby federovaný s Microsoft Entra ID jako zprostředkovatel podnikové identity (označovaný také jako "proxy server SAML").

Pro aplikace SAP SaaS SE SLUŽBA IAS zřizuje a předem konfiguruje pro snadné zprovoznění koncových uživatelů. (Mezi příklady patří SuccessFactors, Marketing Cloud, Cloud for Customer, Sales Cloud a další.) Tento scénář je méně složitý, protože služba IAS je přímo připojená k cílové aplikaci a nepřesílaná k XSUAA. V každém případě platí stejná pravidla pro toto nastavení jako pro Microsoft Entra ID s IAS obecně.

Co doporučujeme?

Pokud je autoritativním uživatelským adresářem Microsoft Entra ID, doporučujeme nastavit konfiguraci důvěryhodnosti v BTP směrem k IAS. Ias je zase nastavený tak, aby se federuje s Microsoft Entra ID jako zprostředkovatel podnikové identity.

Konfigurace důvěryhodnosti SAP

V konfiguraci důvěryhodnosti v protokolu BTP doporučujeme povolit možnost Vytvořit stínové uživatele během přihlašování. Tímto způsobem uživatelé, kteří ještě nebyli vytvořeni v BTP, automaticky získají účet při prvním přihlášení prostřednictvím IAS / Microsoft Entra ID. Pokud by toto nastavení bylo zakázané, budou se moct přihlásit jenom předem zřízení uživatelé.

Proč toto doporučení?

Při použití federace můžete definovat konfiguraci vztahu důvěryhodnosti na úrovni podúčtu BTP. V takovém případě musíte konfiguraci zopakovat pro každý druhý dílčí účet, který používáte. Používáním ias jako konfigurace zprostředkující důvěryhodnosti získáte výhodu centralizované konfigurace napříč několika podúčty a můžete používat funkce IAS, jako je ověřování na základě rizika a centralizované rozšiřování atributů kontrolních výrazů. Aby bylo možné zabezpečit uživatelské prostředí, měly by se tyto pokročilé funkce zabezpečení vynucovat pouze na jednom místě. Může se jednat o IAS nebo při zachování ID Microsoft Entra jako jediného autoritativního úložiště uživatelů (stejně jako v případě tohoto dokumentu), který by centrálně zpracoval správa podmíněného přístupu Microsoft Entra.

Poznámka: do IAS se každý podúčt považuje za "aplikaci", i když v rámci daného podúčtu může být nasazena jedna nebo více aplikací. V rámci IAS může být každá taková aplikace nastavena pro federaci se stejným zprostředkovatelem podnikové identity (v tomto případě Microsoft Entra ID).

Shrnutí implementace

V Microsoft Entra ID:

V Microsoft Entra ID a IAS:

  • Postupujte podle dokumentace a připojte Microsoft Entra ID k IAS v režimu federace (proxy) (dokumentace SAP, dokumentace Microsoftu). Dávejte pozor na NameID nastavení konfigurace jednotného přihlašování v Microsoft Entra ID, protože hlavní názvy uživatelů nejsou nutně e-mailové adresy.
  • Nakonfigurujte "zkompilovanou aplikaci" tak, aby používala ID Microsoft Entra tak, že přejdete na stránku Podmíněné ověřování a nastavíte výchozího zprostředkovatele ověřování identity na zprostředkovatele podnikové identity představujícího váš adresář Microsoft Entra.

V BTP:

  • Nastavte konfiguraci důvěryhodnosti pro ias (dokument SAP) a ujistěte se, že jsou povolené možnosti "K dispozici pro přihlášení uživatele" a "Vytvořit stínové uživatele během přihlášení".
  • Volitelně zakažte možnost "K dispozici pro přihlášení uživatele" ve výchozí konfiguraci důvěryhodnosti SAP ID, aby se uživatelé vždy ověřili prostřednictvím Microsoft Entra ID a nezobrazí se na obrazovce, aby zvolili svého zprostředkovatele identity.

2. Pro ověřování a ověřování použijte ID Microsoft Entra a pro autorizaci použijte ias/BTP.

Kontext

Pokud je pro ověřování uživatelů prostřednictvím federace nakonfigurované ověřování BTP a IAS k Microsoft Entra ID, existuje několik možností konfigurace autorizace:

  • V Microsoft Entra ID můžete přiřadit uživatele a skupiny Microsoft Entra k podnikové aplikaci představující vaši instanci SAP IAS v Microsoft Entra ID.
  • V IAS můžete pomocí ověřování založeného na rizicích povolit nebo zablokovat přihlášení a tím, že zabráníte přístupu k aplikaci v protokolu BTP.
  • V BTP můžete pomocí kolekcí rolí definovat, kteří uživatelé a skupiny mají přístup k aplikaci a získat určité role.

Co doporučujeme?

Doporučujeme, abyste přímo v microsoft Entra neuložili žádnou autorizaci a explicitně vypněte "Požadováno přiřazení uživatele" v podnikové aplikaci v Microsoft Entra ID. Všimněte si, že pro aplikace SAML je toto nastavení ve výchozím nastavení povolené, takže musíte provést explicitní akci, abyste ji zakázali.

Proč toto doporučení?

Když je aplikace federovaná prostřednictvím IAS, z pohledu Microsoft Entra ID uživatel během procesu přihlašování v podstatě "ověřuje ve službě IAS". To znamená, že Microsoft Entra ID nemá žádné informace o tom, ke které konečné aplikaci BTP se uživatel pokouší přihlásit. To také znamená, že autorizaci v Microsoft Entra ID lze použít pouze k provádění velmi hrubě odstupňované autorizace, například umožnit uživateli přihlásit se k jakékoli aplikaci v BTP nebo k žádné. To také zdůrazňuje strategii SAP pro izolaci aplikací a mechanismů ověřování na úrovni podúčtu BTP.

I když to může být platný důvod pro použití požadovaného přiřazení uživatele, znamená to, že teď existují dvě různá místa, kde je potřeba zachovat informace o autorizaci: jak v Microsoft Entra ID podnikové aplikace (kde platí pro všechny aplikace BTP), tak i v každém dílčím účtu BTP. To může vést k nejasnostem a chybným konfiguracím, kdy se nastavení autorizace aktualizují na jednom místě, ale ne na druhém místě. Příklad: Uživatel byl povolen v BTP, ale nebyl přiřazen k aplikaci v Microsoft Entra ID, což vede k neúspěšné ověřování.

Shrnutí implementace

V podnikové aplikaci Microsoft Entra Enterprise představující vztah federace s IAS zakažte "Vyžaduje se přiřazení uživatele". To také znamená, že můžete bezpečně přeskočit přiřazení uživatelů.

3. Použití skupin Microsoft Entra pro autorizaci prostřednictvím kolekcí rolí v IAS/BTP

Kontext

Pokud chcete nakonfigurovat autorizaci pro vaše aplikace BTP, máte několik možností:

  • Můžete nakonfigurovat jemně odstupňované řízení přístupu uvnitř samotné aplikace na základě přihlášeného uživatele.
  • Přístup můžete zadat prostřednictvím rolí a kolekcí rolí v BTP na základě přiřazení uživatelů nebo přiřazení skupin.

Konečná implementace může použít kombinaci obou strategií. Pro přiřazení prostřednictvím kolekcí rolí to ale můžete provést na základě uživatele nebo můžete použít skupiny nakonfigurovaného zprostředkovatele identity.

Co doporučujeme?

Pokud chcete použít Microsoft Entra ID jako autoritativní zdroj pro jemně odstupňovanou autorizaci, doporučujeme použít skupiny Microsoft Entra a přiřadit je kolekcím rolí v BTP. Udělení přístupu uživatelů k určitým aplikacím pak jednoduše znamená jejich přidání do příslušných skupin Microsoft Entra bez jakékoli další konfigurace vyžadované v IAS/BTP.

V této konfiguraci doporučujeme použít ID skupiny (ID objektu) skupiny Microsoft Entra jako jedinečný identifikátor skupiny, nikoli zobrazovaný název (sAMAccountName). To znamená, že musíte použít ID skupiny jako kontrolní výraz "Groups" v tokenu SAML vydaném Microsoft Entra ID. Id skupiny se navíc používá pro přiřazení k kolekci rolí v BTP.

Použití kolekcí rolí v SAP

Proč toto doporučení?

Pokud byste uživatelům přiřadili přímo kolekce rolí v BTP, necentrujete rozhodnutí o autorizaci v Microsoft Entra ID. Znamená to také, že uživatel už musí existovat v IAS, aby mohl být přiřazený ke kolekci rolí v BTP – a vzhledem k tomu, že místo zřizování uživatelů doporučujeme federování, znamená to, že stínový účet uživatele v době, kdy chcete provést přiřazení uživatele, možná ještě neexistuje. Použití skupin Microsoft Entra a jejich přiřazení ke kolekcím rolí eliminuje tyto problémy.

Přiřazování skupin ke kolekcím rolí se může zdát, že je v rozporu s předchozím doporučením, abyste k autorizaci nepoužíli ID Microsoft Entra. I v tomto případě se ale rozhodnutí o autorizaci stále provádí v BTP, je to jen to, že rozhodnutí je teď založené na členství ve skupině udržovaném v Microsoft Entra ID.

Doporučujeme místo názvu použít ID skupiny Microsoft Entra, protože ID skupiny je globálně jedinečné, neměnné a nedá se použít pro jinou skupinu později; Vzhledem k tomu, že použití názvu skupiny může vést k problémům, když se název změní, a existuje bezpečnostní riziko, že se skupina odstraní a jiná skupina se vytvoří se stejným názvem, ale s uživateli, kteří by neměli mít k aplikaci přístup.

Shrnutí implementace

V Microsoft Entra ID:

  • Vytvořte skupiny, do kterých je možné přidat uživatele, kteří potřebují přístup k aplikacím v BTP (například vytvořte skupinu Microsoft Entra pro každou kolekci rolí v BTP).
  • V podnikové aplikaci Microsoft Entra, která představuje federační vztah s IAS, nakonfigurujte atributy uživatele SAML a deklarace identity pro přidání deklarace identity skupiny pro skupiny zabezpečení:

    • Nastavte atribut Source na "ID skupiny" a název na Groups (napsané přesně tak, s velkými písmeny G).

    • Kromě toho, aby byla datová část deklarací malá a aby nedocházelo k omezení, kdy id Microsoft Entra omezí počet deklarací identity skupin na 150 v kontrolních výrazech SAML, důrazně doporučujeme omezit skupiny vrácené v deklaracích pouze na skupiny, které byly explicitně přiřazeny:

      • V části "Které skupiny přidružené k uživateli by měly být vráceny v deklaraci identity?" odpovědi "Skupiny přiřazené k aplikaci". Potom pro skupiny, které chcete zahrnout jako deklarace identity, přiřaďte je k podnikové aplikaci pomocí oddílu Uživatelé a skupiny a vyberte Přidat uživatele nebo skupinu.

      Konfigurace deklarace identity skupiny Microsoft Entra

V IAS:

  • V konfiguraci zprostředkovatele podnikové identity v rámci možností Federace identit zajistěte, abyste zakázali úložiště uživatelů ověřování identit. Jinak by se informace o skupině z Id Microsoft Entra nezachovaly v tokenu SAML pro BTP a autorizace selžou.

Poznámka:

Pokud potřebujete použít úložiště uživatelů ověřování identit (například k zahrnutí deklarací identity, které nelze získat z ID Microsoft Entra, ale které jsou k dispozici v úložišti uživatelů IAS), můžete toto nastavení zachovat. V takovém případě však budete muset nakonfigurovat výchozí atributy odeslané do aplikace tak, aby zahrnovaly relevantní deklarace identity pocházející z Microsoft Entra ID (například s formátem ${corporateIdP.Groups} ).

V BTP:

  • Na kolekcích rolí používaných aplikacemi v daném podúčtu namapujte kolekce rolí na skupiny uživatelů přidáním konfigurace pro zprostředkovatele identity IAS a nastavením názvu na ID skupiny (ID objektu) skupiny Microsoft Entra.

Poznámka:

V případě, že byste v ID Microsoft Entra měli další deklaraci identity, která bude obsahovat autorizační informace, které se mají použít v BTP, nemusíte používat Groups název deklarace identity. Toto je to, co BTP používá při mapování kolekcí rolí na skupiny uživatelů jako výše, ale můžete také mapovat kolekce rolí na atributy uživatele, což vám dává větší flexibilitu.

4. Použití jednoho dílčího účtu BTP pouze pro aplikace, které mají podobné požadavky na identitu

Kontext

V rámci protokolu BTP může každý dílčí účet obsahovat více aplikací. Z pohledu IAS je však "sbalená aplikace" úplný dílčí účet BTP, nikoli podrobnější aplikace v rámci této aplikace. To znamená, že všechna nastavení důvěryhodnosti, ověřování a konfigurace přístupu a možnosti brandingu a rozložení v IAS platí pro všechny aplikace v rámci tohoto podúčtu. Podobně platí, že všechny konfigurace důvěryhodnosti a kolekce rolí v protokolu BTP platí také pro všechny aplikace v rámci daného podúčtu.

Co doporučujeme?

Doporučujeme kombinovat více aplikací v jednom podúčtu BTP pouze v případě, že mají podobné požadavky na úrovni identity (uživatelé, skupiny, zprostředkovatelé identity, role, konfigurace důvěryhodnosti, branding, ...).

Proč toto doporučení?

Kombinací více aplikací, které mají velmi odlišné požadavky na identitu do jednoho podúčtu VTP, můžete skončit s konfigurací, která je nezabezpečená nebo může být snadněji chybně nakonfigurovaná. Příklad: Když se pro jednu aplikaci v protokolu BTP vytvoří změna konfigurace sdíleného prostředku, jako je zprostředkovatel identity, ovlivní to všechny aplikace, které se spoléhají na tento sdílený prostředek.

Shrnutí implementace

Pečlivě zvažte, jak chcete seskupit více aplikací mezi podúčty v BTP. Další informace najdete v dokumentaci k modelu účtu SAP.

5. Pro všechny ověřování a autorizaci koncového uživatele použijte tenanta IAS v produkčním prostředí.

Kontext

Při práci s IAS obvykle máte tenanta pro produkční prostředí a vývoj/testování. U různých dílčích účtů nebo aplikací v protokolu BTP můžete zvolit, kterého zprostředkovatele identity (tenant IAS) chcete použít.

Co doporučujeme?

Pro všechny interakce s koncovými uživateli doporučujeme vždy používat tenanta IAS produkčního prostředí, a to i v kontextu verze vývoje/testování nebo prostředí aplikace , ke které se musí přihlásit.

Doporučujeme používat jiné tenanty IAS pouze pro testování konfigurace související s identitou, která musí být provedena izolovaně od produkčního tenanta.

Proč toto doporučení?

Vzhledem k tomu, že IAS je centralizovaná komponenta, která je nastavená na federaci s Microsoft Entra ID, existuje pouze jedno místo, kde musí být konfigurace federace a identity nastavena a udržována. Duplikování tohoto chování v jiných tenantech IAS může vést k chybným konfiguracím nebo nekonzistencí v přístupu koncových uživatelů mezi prostředími.

6. Definování procesu pro vrácení podpisových certifikátů SAML

Kontext

Při konfiguraci federace mezi Microsoft Entra ID a IAS a mezi IAS a BTP se vyměňují metadata SAML, která obsahují certifikáty X.509 používané pro šifrování a kryptografické podpisy tokenů SAML, které se odesílají mezi oběma stranami. Tyto certifikáty mají data vypršení platnosti a musí se pravidelně aktualizovat (i v situacích tísňového volání v případě ohrožení zabezpečení certifikátu).

Poznámka: Výchozí doba platnosti počátečního certifikátu Microsoft Entra použitého k podepisování kontrolních výrazů SAML je 3 roky (a všimněte si, že certifikát je specifický pro podnikovou aplikaci, na rozdíl od tokenů OpenID Připojení a OAuth 2.0, které jsou podepsány globálním certifikátem v Microsoft Entra ID). Můžete se rozhodnout vygenerovat nový certifikát s jiným datem vypršení platnosti nebo vytvořit a importovat vlastní certifikát.

Po vypršení platnosti certifikátů se už nedají použít a musí být nakonfigurované nové certifikáty. Proto musí být vytvořen proces, aby se zachovala konfigurace certifikátu uvnitř předávající strany (která potřebuje ověřit podpisy) aktuální se skutečnými certifikáty, které se používají k podepsání tokenů SAML.

V některých případech to předávající strana může provést automaticky tím, že jí poskytne koncový bod metadat, který dynamicky vrací nejnovější informace o metadatech – to je obvykle veřejně přístupná adresa URL, ze které může předávající strana pravidelně načítat metadata a aktualizovat své interní úložiště konfigurace.

Služba IAS však umožňuje nastavení zprostředkovatelů podnikové identity pouze prostřednictvím importu souboru XML metadat, nepodporuje poskytování koncového bodu metadat pro dynamické načítání metadat metadat Microsoft Entra (například https://login.microsoftonline.com/my-azuread-tenant/federationmetadata/2007-06/federationmetadata.xml?appid=my-app-id). Podobně BTP neumožňuje nastavení nové konfigurace důvěryhodnosti z koncového bodu metadat IAS (například https://my-ias-tenant.accounts.ondemand.com/saml2/metadata), potřebuje také jednorázové nahrání souboru XML metadat.

Co doporučujeme?

Při nastavování federace identit mezi libovolnými dvěma systémy (například Microsoft Entra ID a IAS a IAS a BTP) se ujistěte, že zaznamenáte datum vypršení platnosti použitých certifikátů. Ujistěte se, že tyto certifikáty lze dobře nahradit předem a že existuje zdokumentovaný proces aktualizace nových metadat ve všech předávajících stranách, které jsou na těchto certifikátech závislé.

Jak je popsáno dříve, doporučujeme nastavit konfiguraci důvěryhodnosti v BTP směrem k IAS, která je zase nastavená tak, aby se federovala s Microsoft Entra ID jako zprostředkovatel podnikové identity. V tomto případě jsou důležité následující certifikáty (které se používají pro podepisování a šifrování SAML):

  • Certifikát podúčtu v protokolu BTP: Při této změně se musí aktualizovat konfigurace SAML 2.0 aplikace v IAS.
  • Certifikát tenanta v IAS: Při této změně musí být aktualizována konfigurace SAML 2.0 podnikové aplikace v Microsoft Entra ID a Konfigurace důvěryhodnosti v BTP.
  • Certifikát podnikové aplikace v Microsoft Entra ID: Při této změně musí být aktualizována konfigurace SAML 2.0 zprostředkovatele podnikové identity v IAS.

Vrácení podpisových certifikátů SAML

SAP obsahuje ukázkové implementace pro oznámení o klientských certifikátech pomocí integrace SAP Cloud a zpracování téměř vypršení platnosti. Tuto možnost je možné přizpůsobit pomocí služeb Azure Integration Services nebo PowerAutomate. Je však nutné je přizpůsobit tak, aby fungovaly s certifikáty serveru. Takový přístup vyžaduje vlastní implementaci.

Proč toto doporučení?

Pokud platnost certifikátů vyprší nebo když jsou nahrazeny včas, ale předávající strany, které na nich závisejí, se neaktualizují s informacemi o novém certifikátu, uživatelé se už nebudou moct přihlásit k žádné aplikaci prostřednictvím federace. To může znamenat významný výpadek pro všechny uživatele při obnovování služby tím, že překonfigurujete metadata.

Shrnutí implementace

Přidejte e-mailovou adresu pro vypršení platnosti certifikátu v Microsoft Entra ID a nastavte ji na poštovní schránku skupiny tak, aby se neodesílala jediné osobě (která už možná ještě nemá účet v době, kdy platnost certifikátu vyprší). Ve výchozím nastavení obdrží oznámení jenom uživatel, který vytvořil podnikovou aplikaci.

Zvažte vytvoření automatizace, aby se spustil celý proces vrácení certifikátu. Můžete například pravidelně kontrolovat vypršení platnosti certifikátů a nahradit je při aktualizaci všech předávajících stran novými metadaty.

Použití Azure AD B2C jako zprostředkovatele identity

Azure Active Directory B2C poskytuje identitu mezi firmami jako službu. Vzhledem k tomu, že integrace s Azure AD B2C je podobná tomu, jak byste podnikovým uživatelům umožnili přihlásit se pomocí Microsoft Entra ID, výše uvedená doporučení platí hlavně v případě, že chcete používat Azure AD B2C pro zákazníky, uživatele nebo občany a umožnit jim používat preferované identity sociálních, podnikových nebo místních účtů.

Existuje však několik důležitých rozdílů. Nastavení Azure AD B2C jako zprostředkovatele podnikové identity v IAS a konfigurace federace mezi oběma tenanty je podrobněji popsáno v tomto blogovém příspěvku.

Registrace aplikace SAML v Azure AD B2C

Azure AD B2C nemá galerii podnikových aplikací, které můžete použít ke snadné konfiguraci vztahu důvěryhodnosti vůči zprostředkovateli podnikové identity v IAS. Místo toho budete muset k registraci aplikace SAML v Azure AD B2C použít vlastní zásady. Tato aplikace SAML hraje stejnou logickou roli jako podniková aplikace v ID Microsoft Entra, takže platí stejné pokyny týkající se vrácení certifikátů SAML, například.

Autorizace pomocí Azure AD B2C

Azure AD B2C nativně nepodporuje použití skupin k vytváření kolekcí uživatelů, kterým můžete přiřadit přístup, což znamená, že pokyny k použití skupin Microsoft Entra pro autorizaci prostřednictvím kolekcí rolí v BTP se musí implementovat odlišně.

Azure AD B2C je naštěstí vysoce přizpůsobitelný, takže můžete nakonfigurovat tokeny SAML, které odesílá službě IAS, aby zahrnovaly všechny vlastní informace. Různé možnosti podpory deklarací identity autorizace najdete v dokumentaci, která doprovází ukázku rolí aplikací Azure AD B2C, ale v souhrnu: prostřednictvím mechanismu rozšiřitelnosti rozhraní API Připojení můžete volitelně používat skupiny, role aplikací nebo dokonce vlastní databázi k určení toho, k čemu má uživatel povolený přístup.

Bez ohledu na to, odkud autorizační informace pocházejí, je pak možné je vygenerovat jako Groups atribut uvnitř tokenu SAML tak, že tento název atributu nakonfigurujete jako výchozí typ deklarace identity partnera ve schématu deklarací identity nebo přepsáním typu deklarace identity partnera u výstupních deklarací identity. Mějte však na paměti, že BTP umožňuje mapovat kolekce rolí na atributy uživatele, což znamená, že jakýkoli název atributu se dá použít k rozhodování o autorizaci, i když název atributu Groups nepoužíváte.

Další kroky