Forgatókönyv – A Microsoft Entra ID használata az SAP-platformokhoz és alkalmazásokhoz való hozzáférés biztonságossá tételéhez

Ez a dokumentum tanácsokat nyújt az SAP-platformok és -alkalmazások műszaki tervezéséhez és konfigurálásához, amikor a Microsoft Entra ID-t használja az SAP Cloud Identity Services elsődleges felhasználói hitelesítési szolgáltatásaként. Az SAP Cloud Identity Services magában foglalja az identitáshitelesítést, az identitáskiosztást, az identitáskönyvtárat és az engedélyezéskezelést. További információ a hitelesítés kezdeti beállításáról a Microsoft Entra egyszeri bejelentkezési (SSO) integrációjában az SAP Cloud Identity Services oktatóanyagával. A kiépítéssel és egyéb forgatókönyvekkel kapcsolatos további információkért tekintse meg a Microsoft Entra üzembe helyezésének tervét az SAP-forrás- és célalkalmazásokkal való felhasználói kiépítéshez, valamint az SAP-alkalmazásokhoz való hozzáférés kezelésével kapcsolatban.

Az útmutatóban használt terminológia

Rövidítés	Leírás
BTP	Az SAP Business Technology Platform egy felhőalapú SAP-alkalmazásokhoz optimalizált innovációs platform. Az itt tárgyalt SAP-technológiák többsége a BTP része. A hivatalosan SAP Cloud Platform néven ismert termékek az SAP BTP részét képezik.
IAS	Az SAP Cloud Identity Services – Identitáshitelesítés, az SAP Cloud Identity Services egyik összetevője, egy felhőszolgáltatás, amely az SAP-felhőben és a helyszíni alkalmazásokban történő hitelesítésre, egyszeri bejelentkezésre és felhasználókezelésre szolgál. Az IAS segít a felhasználóknak a saját SAP BTP-szolgáltatáspéldányaikon való hitelesítésben, olyan proxyként, amely integrálható a Microsoft Entra egyszeri bejelentkezéssel.
IPS	Az SAP Cloud Identity Services – Identity Provisioning, az SAP Cloud Identity Services egyik összetevője, egy felhőalapú szolgáltatás, amely segít az identitások kiépítésében és azok az SAP-felhőben és a helyszíni alkalmazásokban való engedélyezésében.
XSUAA	Kiterjesztett szolgáltatások a Cloud Foundry felhasználói fiókjához és hitelesítéséhez. A Cloud Foundry egy olyan szolgáltatásként nyújtott platform (PaaS), amely különböző infrastruktúrákon helyezhető üzembe, az SAP által létrehozott SAP Üzleti technológiai platform környezete. Az XSUAA egy több-bérlős OAuth engedélyezési kiszolgáló, amely a Cloud Foundry-környezet központi infrastruktúra-összetevője. Az XSUAA biztosítja az üzleti felhasználók hitelesítését és engedélyezését az SAP BTP-n belül.
Fiori	Az SAP webes felhasználói felülete (szemben az asztali felülettel).

Áttekintés

Az SAP és a Microsoft technológiai verem számos szolgáltatása és összetevője szerepet játszik a felhasználói hitelesítésben és engedélyezésben. A fő szolgáltatások az alábbi ábrán láthatók.

Mivel számos lehetséges forgatókönyvet kell konfigurálni, egy olyan forgatókönyvre összpontosítunk, amely összhangban van a Microsoft Entra-identitás első stratégiájával. A következő feltételezéseket fogjuk tenni:

• Az összes identitást központilag és csak a Microsoft Entra-azonosítóból szeretné szabályozni.
• A lehető legnagyobb mértékben szeretné csökkenteni a karbantartási erőfeszítéseket, és automatizálni szeretné a hitelesítést és az alkalmazáshozzáférést a Microsoft és az SAP között.
• A Microsoft Entra ID és az IAS használatával kapcsolatos általános útmutató a BTP-n és az IAS-ben konfigurált SAP SaaS-alkalmazásokon üzembe helyezett alkalmazásokra vonatkozik. A BTP-hez (például a Microsoft Entra-csoportokkal való szerepkörleképezésekhez) és az SAP SaaS-alkalmazásokhoz (például identitáskiépítési szolgáltatás szerepköralapú engedélyezéshez) vonatkozó konkrét javaslatokat is megadunk.
• Azt is feltételezzük, hogy a felhasználók már ki vannak építve a Microsoft Entra-azonosítóban és minden olyan SAP-rendszerben, amely megköveteli a felhasználók üzembe helyezését a működéshez. Függetlenül attól, hogy ez hogyan valósult meg: a kiépítés történhetett manuálisan, helyi Active Directory a Microsoft Entra Csatlakozás vagy olyan HR-rendszereken keresztül, mint az SAP SuccessFactors. Ebben a dokumentumban ezért a SuccessFactors olyan alkalmazásnak minősül, mint bármely más, a (meglévő) felhasználók által bejelentkezett alkalmazás. Nem foglalkozunk a felhasználók tényleges kiosztásával a SuccessFactorsból a Microsoft Entra ID-ba. További információ arról, hogy a felhasználók a Microsoft Entra-azonosítóba kerülnek az SAP-számítási feladatokhoz való használatra, tekintse meg a Microsoft Entra üzembe helyezésének tervét az SAP-forrás- és célalkalmazásokkal való felhasználói kiépítéshez, valamint az SAP-alkalmazásokhoz való hozzáférés kezeléséhez.

Ezen feltételezések alapján elsősorban az alábbi ábrán bemutatott termékekre és szolgáltatásokra összpontosítunk. Ezek azok a különböző összetevők, amelyek a felhőalapú környezetekben a hitelesítés és az engedélyezés szempontjából a legrelevánsabbak.

Ha SAP Identity Managementet (IDM) használ, akkor az identitáskezelési forgatókönyveket az SAP IDM-ből a Microsoft Entra-ba migrálhatja. További információ: Identitáskezelési forgatókönyvek migrálása AZ SAP IDM-ből a Microsoft Entra-ba.

Feljegyzés

Az itt található útmutatás nagy része az Azure Active Directory B2C-hez is vonatkozik, de van néhány fontos különbség. További információ: Az Azure AD B2C használata identitásszolgáltatóként.

Figyelmeztetés

Vegye figyelembe az SAP SAML-érvényesítési korlátokat, valamint az SAP Cloud Foundry szerepkörcsoportnevek hosszának és az SAP Cloud Identity Service csoportjai által létrehozott gyűjtemények mennyiségének hatását. További információ: SAP megjegyzés 2732890 az SAP for Me-ben. A túllépett korlátok engedélyezési problémákat eredményeznek.

Ajánlások

Összegzés

• 1 – Összevont hitelesítés használata az SAP Business Technology Platformban és az SAP SaaS-alkalmazásokban az SAP Identity Authentication Service-n keresztül
• 2 – A Microsoft Entra-azonosító használata hitelesítéshez és AZ IAS/BTP hitelesítéshez
• 3 – A Microsoft Entra-csoportok használata szerepkörcsoportokon keresztüli engedélyezéshez az IAS/BTP-ben
• 4 – Egyetlen BTP-alfiók használata csak hasonló identitásigényű alkalmazásokhoz
• 5 – Az Éles IAS-bérlő használata az összes végfelhasználói hitelesítéshez és engedélyezéshez
• 6 – SAML-aláíró tanúsítványok átállítási folyamatának definiálása

1 – Összevont hitelesítés használata az SAP Business Technology Platformban és az SAP SaaS-alkalmazásokban az SAP Identity Authentication Service-n keresztül

Környezet

A BTP-alkalmazások identitásszolgáltatókat használhatnak a megbízhatósági konfigurációkon keresztül a felhasználók hitelesítéséhez a BTP/XSUAA és az identitásszolgáltató közötti SAML 2.0 protokoll használatával. Vegye figyelembe, hogy csak az SAML 2.0 támogatott, annak ellenére, hogy az OpenID Csatlakozás protokollt maga az alkalmazás és a BTP/XSUAA között használják (ebben a kontextusban nem releváns).

A BTP-ben beállíthatja a megbízhatósági konfigurációt az SAP Cloud Identity Services – Identity Authentication felé (ez az alapértelmezett), de ha a mérvadó felhasználói címtár a Microsoft Entra ID, akkor összevonást állíthat be, hogy a felhasználók bejelentkezhessenek a meglévő Microsoft Entra-fiókjukkal.

Az összevonás mellett igény szerint felhasználói kiépítést is beállíthat, hogy a Microsoft Entra-felhasználók előre kiépülhessenek a BTP-ben. Ehhez azonban nincs natív támogatás (csak a Microsoft Entra ID -> SAP Identity Authentication Service esetében); a Natív támogatással integrált megoldás a BTP Identity Provisioning Service lenne. A felhasználói fiókok előzetes kiépítése hasznos lehet engedélyezési célokra (például felhasználók szerepkörökhöz való hozzáadásához). A követelményektől függően ezt a Microsoft Entra-csoportokkal is elérheti (lásd alább), ami azt jelentheti, hogy egyáltalán nincs szükség felhasználói kiépítésre.

Az összevonási kapcsolat beállításakor több lehetőség is van:

• Dönthet úgy, hogy közvetlenül a BTP/XSUAA-ból fonódik össze a Microsoft Entra-azonosítóval.
• Dönthet úgy, hogy összevonja az IAS-et, amely viszont úgy van beállítva, hogy a Microsoft Entra-azonosítót vállalati identitásszolgáltatóként (más néven "SAML-proxyzás") egyesítse.

Az SAP SaaS-alkalmazások esetében az IAS ki van építve és előre konfigurálva van a végfelhasználók egyszerű előkészítése érdekében. (Ilyenek például a SuccessFactors, a Marketing Cloud, a Cloud for Customer, a Sales Cloud és mások.) Ez a forgatókönyv kevésbé összetett, mivel az IAS közvetlenül kapcsolódik a célalkalmazáshoz, és nem kapcsolódik az XSUAA-hoz. Mindenesetre ugyanazok a szabályok vonatkoznak erre a beállításra, mint a Microsoft Entra ID és általában az IAS esetében.

Mit ajánlunk?

Ha a mérvadó felhasználói címtár Microsoft Entra-azonosító, javasoljuk, hogy állítson be egy megbízhatósági konfigurációt a BTP-ben az IAS felé. Az IAS viszont úgy van beállítva, hogy összevonja a Microsoft Entra-azonosítót vállalati identitásszolgáltatóként.

A BTP megbízhatósági konfigurációjában azt javasoljuk, hogy engedélyezve legyen az "Árnyékfelhasználók létrehozása bejelentkezéskor" beállítás. Így azok a felhasználók, akik még nem lettek létrehozva a BTP-ben, automatikusan kapnak egy fiókot, amikor első alkalommal jelentkeznek be az IAS/Microsoft Entra-azonosítón keresztül. Ha ez a beállítás le lenne tiltva, csak az előre kiépített felhasználók jelentkezhetnek be.

Miért ez a javaslat?

Összevonás használatakor megadhatja a megbízhatósági konfigurációt a BTP-alfiók szintjén. Ebben az esetben meg kell ismételnie a konfigurációt a többi használt alfiókhoz. Ha az IAS-t köztes megbízhatósági konfigurációként használja, több alfiókban is használhatja a központosított konfigurációt, és olyan IAS-funkciókat használhat, mint a kockázatalapú hitelesítés és az érvényesítési attribútumok központosított bővítése. A felhasználói élmény védelme érdekében ezeket a speciális biztonsági funkciókat csak egyetlen helyen kell kikényszeríteni. Ez lehet az IAS, vagy ha a Microsoft Entra-azonosítót egyetlen mérvadó felhasználói tárolóként tartja meg (ahogyan a jelen tanulmány előfeltétele is), ezt központilag a Microsoft Entra Feltételes hozzáférés-kezelés kezeli.

Megjegyzés: Az IAS-hez minden alfiók "alkalmazásnak" minősül, annak ellenére, hogy ezen az alfiókon belül egy vagy több alkalmazás üzembe helyezhető. Az IAS-en belül minden ilyen alkalmazás beállítható ugyanazon vállalati identitásszolgáltatóval (ebben az esetben a Microsoft Entra-azonosítóval) való összevonáshoz.

A megvalósítás összefoglalása

A Microsoft Entra-azonosítóban:

• Igény szerint konfigurálhatja a Microsoft Entra-azonosítót a közvetlen egyszeri bejelentkezéshez (közvetlen egyszeri bejelentkezéshez), amely automatikusan bejelentkezteti a felhasználókat, amikor a vállalati hálózathoz csatlakoztatott vállalati eszközeiken vannak. Ha engedélyezve van, a felhasználóknak nem kell beírniuk a jelszavukat a Microsoft Entra ID-be való bejelentkezéshez, sőt, általában még a felhasználónevüket sem kell beírniuk.

A Microsoft Entra ID-ben és az IAS-ben:

• A dokumentációt követve csatlakoztassa a Microsoft Entra-azonosítót az IAS-hez összevonási (proxy) módban (SAP-dokumentum, Microsoft-dokumentum). Figyelje meg az egyszeri bejelentkezés konfigurációjának beállítását a NameID Microsoft Entra-azonosítóban, mert az UPN-ek nem feltétlenül e-mail-címek.
• A "Csomagolt alkalmazás" konfigurálásával használja a Microsoft Entra-azonosítót. Ehhez lépjen a "Feltételes hitelesítés" oldalra, és állítsa be az "Alapértelmezett hitelesítési identitásszolgáltatót" a Microsoft Entra-címtárat képviselő vállalati identitásszolgáltatóra.

A BTP-ben:

• Állítson be egy megbízhatósági konfigurációt az IAS -hez (SAP-dokumentum), és győződjön meg arról, hogy a "Felhasználói bejelentkezéshez elérhető" és az "Árnyékfelhasználók létrehozása bejelentkezéskor" lehetőség is engedélyezve van.
• Ha szeretné, tiltsa le a "Felhasználói bejelentkezéshez elérhető" beállítást az alapértelmezett "SAP ID Service" megbízhatósági konfigurációban, hogy a felhasználók mindig a Microsoft Entra-azonosítón keresztül hitelesítsék magukat, és ne jelenjen meg képernyő az identitásszolgáltatójuk kiválasztásához.

2 – A Microsoft Entra-azonosító használata hitelesítéshez és AZ IAS/BTP hitelesítéshez

Környezet

Ha a BTP és az IAS a Microsoft Entra ID-vel való összevonáson keresztül lett konfigurálva a felhasználói hitelesítéshez, az engedélyezés konfigurálására több lehetőség is van:

• A Microsoft Entra-azonosítóban Microsoft Entra-felhasználókat és -csoportokat rendelhet hozzá az SAP IAS-példányt képviselő nagyvállalati alkalmazáshoz a Microsoft Entra-azonosítóban.
• Az IAS-ben kockázatalapú hitelesítéssel engedélyezheti vagy letilthatja a bejelentkezéseket, és ezzel megakadályozhatja az alkalmazáshoz való hozzáférést a BTP-ben.
• A BTP-ben szerepkörcsoportok használatával meghatározhatja, hogy mely felhasználók és csoportok férhetnek hozzá az alkalmazáshoz, és kaphatnak bizonyos szerepköröket.

Mit ajánlunk?

Javasoljuk, hogy ne tegyen közvetlenül a Microsoft Entra-ba semmilyen engedélyt, és kifejezetten kapcsolja ki a "Felhasználói hozzárendelés szükséges" beállítást a Vállalati alkalmazáson a Microsoft Entra-azonosítóban. Vegye figyelembe, hogy az SAML-alkalmazások esetében ez a beállítás alapértelmezés szerint engedélyezve van, ezért explicit műveletet kell végrehajtania a letiltásához.

Miért ez a javaslat?

Ha az alkalmazás az IAS-en keresztül van összevontan, a microsoft entra-azonosító szempontjából a felhasználó lényegében "hitelesítést nyújt az IAS-nek" a bejelentkezési folyamat során. Ez azt jelenti, hogy a Microsoft Entra-azonosító nem rendelkezik információval arról, hogy a felhasználó melyik utolsó BTP-alkalmazásba próbál bejelentkezni. Ez azt is jelenti, hogy a Microsoft Entra ID-ban való engedélyezés csak nagyon durva részletes engedélyezésre használható, például lehetővé teszi a felhasználónak, hogy jelentkezzen be bármely alkalmazásba a BTP-ben, vagy egyik sem. Ez azt is hangsúlyozza, hogy az SAP stratégiája elkülöníti az alkalmazásokat és a hitelesítési mechanizmusokat a BTP-alfiók szintjén.

Bár ez lehet a "Felhasználói hozzárendelés szükséges" használatának érvényes oka, ez azt jelenti, hogy jelenleg két különböző helyen kell megőrizni az engedélyezési adatokat: mindkettő a Nagyvállalati alkalmazás Microsoft Entra-azonosítójában (ahol az összes BTP-alkalmazásra vonatkozik), valamint minden BTP-alfiókban. Ez zavart és helytelen konfigurációkat eredményezhet, amikor az engedélyezési beállításokat egy helyen frissítik, a másikat azonban nem. Például: egy felhasználó engedélyezett volt a BTP-ben, de nem lett hozzárendelve az alkalmazáshoz a Microsoft Entra-azonosítóban, ami sikertelen hitelesítést eredményezett.

A megvalósítás összefoglalása

Az IAS-hez való összevonási kapcsolatot képviselő Microsoft Entra Enterprise-alkalmazásban tiltsa le a "Felhasználó-hozzárendelés szükséges" beállítást. Ez azt is jelenti, hogy nyugodtan kihagyhatja a felhasználók hozzárendelését.

3 – A Microsoft Entra-csoportok használata szerepkörcsoportokon keresztüli engedélyezéshez az IAS/BTP-ben

Környezet

Ha a BTP-alkalmazások engedélyezését szeretné konfigurálni, több lehetőség is van:

• A bejelentkezett felhasználó alapján az alkalmazáson belül is konfigurálhat részletes hozzáférés-vezérlést.
• Felhasználói hozzárendelések vagy csoporthozzárendelések alapján a BTP-ben szerepkörökön és szerepkörcsoportokon keresztül is megadhatja a hozzáférést.

A végső megvalósítás mindkét stratégia kombinációját használhatja. A szerepkörcsoportokon keresztüli hozzárendelés esetében azonban ez felhasználónként elvégezhető, vagy használhatja a konfigurált identitásszolgáltató csoportjait.

Mit ajánlunk?

Ha a Részletes engedélyezés mérvadó forrásaként a Microsoft Entra-azonosítót szeretné használni, javasoljuk, hogy használja a Microsoft Entra-csoportokat, és rendelje hozzá őket a BTP szerepkör-gyűjteményeihez. Ha hozzáférést ad a felhasználóknak bizonyos alkalmazásokhoz, az egyszerűen azt jelenti, hogy hozzáadja őket a megfelelő Microsoft Entra-csoportokhoz anélkül, hogy az IAS/BTP-ben további konfigurációra van szükség.

Ezzel a konfigurációval azt javasoljuk, hogy a Microsoft Entra-csoport csoportazonosítóját (objektumazonosítóját) használja a csoport egyedi azonosítójaként, ne pedig a megjelenítendő nevet ("sAMAccountName"). Ez azt jelenti, hogy a Microsoft Entra ID által kibocsátott SAML-jogkivonatban a csoportazonosítót kell "Csoportok" állításként használnia. A csoportazonosító emellett a BTP szerepkörgyűjteményéhez való hozzárendeléshez is használható.

Miért ez a javaslat?

Ha közvetlenül a BTP-ben rendelne felhasználókat szerepkörcsoportokhoz, nem központosítja az engedélyezési döntéseket a Microsoft Entra-azonosítóban. Azt is jelenti, hogy a felhasználónak már léteznie kell az IAS-ben, mielőtt hozzá lehetne rendelni őket egy BTP-szerepkörcsoporthoz – és mivel a felhasználó kiépítése helyett összevonást javasolunk, ez azt jelenti, hogy a felhasználó árnyékfiókja még nem létezik az IAS-ben a felhasználói hozzárendelés végrehajtásakor. A Microsoft Entra-csoportok használata és szerepkörcsoportokhoz való hozzárendelése kiküszöböli ezeket a problémákat.

Úgy tűnhet, hogy a csoportok szerepkörcsoportokhoz való hozzárendelése ellentmond az előző javaslatnak, amely szerint nem használja a Microsoft Entra-azonosítót az engedélyezéshez. A BTP-ben még ebben az esetben is meghozzák az engedélyezési döntést, csak az, hogy a döntés most a Microsoft Entra ID-ban fenntartott csoporttagságon alapul.

A Microsoft Entra-csoport csoportazonosítóját javasoljuk a neve helyett, mert a csoportazonosító globálisan egyedi, nem módosítható, és később soha nem használható újra egy másik csoporthoz; mivel a csoportnév használata problémákat okozhat a név módosításakor, és fennáll a veszélye annak, hogy törölnek egy csoportot, és egy másikat ugyanazzal a névvel hoznak létre, de a benne lévő felhasználók nem férhetnek hozzá az alkalmazáshoz.

A megvalósítás összefoglalása

A Microsoft Entra-azonosítóban:

• Hozzon létre olyan csoportokat, amelyekhez olyan felhasználókat adhat hozzá, amelyeknek hozzáférésre van szükségük a BTP-ben található alkalmazásokhoz (például hozzon létre egy Microsoft Entra-csoportot minden BTP-szerepkörcsoporthoz).
• Az IAS-hez való összevonási kapcsolatot képviselő Microsoft Entra Enterprise-alkalmazásban konfigurálja az SAML felhasználói attribútumokat > jogcímeket a biztonsági csoportok csoportjogcímének hozzáadásához:

  • Állítsa a Forrás attribútumot a "Csoportazonosító" értékre, a nevet pedig a következőre Groups (pontosan így írja be, nagybetűvel: "G").

  • Továbbá annak érdekében, hogy a jogcímek hasznos adatai kicsik maradjanak, és ne fusson bele abba a korlátozásba, amelynek értelmében a Microsoft Entra ID a csoportos jogcímek számát 150-re korlátozza az SAML-állításokban, erősen javasoljuk, hogy a jogcímekben visszaadott csoportokat csak azokra a csoportokra korlátozza, amelyek kifejezetten hozzárendelve lettek:

    • A "Melyik felhasználóhoz társított csoportokat kell visszaadni a jogcímben?" válasz a "Az alkalmazáshoz rendelt csoportok" kérdésre. Ezután a jogcímként felvenni kívánt csoportokhoz rendelje őket a Vállalati alkalmazáshoz a "Felhasználók és csoportok" szakasz használatával, majd válassza a "Felhasználó/csoport hozzáadása" lehetőséget.

    

Az IAS-ben:

• A vállalati identitásszolgáltató konfigurációjában, az Identitás összevonási beállításai között győződjön meg arról, hogy letiltja az "Identitáshitelesítés felhasználói tároló használata" beállítást; ellenkező esetben a Microsoft Entra-azonosító csoportadatai nem maradnak meg az SAML-jogkivonatban a BTP felé, és az engedélyezés sikertelen lesz.

Feljegyzés

Ha az Identitáshitelesítés felhasználói tárolót kell használnia (például olyan jogcímek hozzáadásához, amelyek nem származhatnak a Microsoft Entra-azonosítóból, de amelyek elérhetők az IAS felhasználói tárában), ezt a beállítást engedélyezve tarthatja. Ebben az esetben azonban konfigurálnia kell az alkalmazásnak küldött alapértelmezett attribútumokat, hogy tartalmazzák a Microsoft Entra-azonosítóból származó releváns jogcímeket (például a ${corporateIdP.Groups} formátumot).

A BTP-ben:

• Az adott alfiókban lévő alkalmazások által használt szerepkörcsoportokon képezze le a szerepkör-gyűjteményeket a felhasználói csoportokhoz úgy, hogy hozzáad egy konfigurációt az IAS-identitásszolgáltatóhoz, és beállítja a Microsoft Entra-csoport csoportazonosítójának (objektumazonosítójának) a nevét.

Feljegyzés

Ha a Microsoft Entra-azonosítóban egy másik jogcímet használna, amely a BTP-ben használandó engedélyezési adatokat tartalmazza, nem kell használnia a Groups jogcím nevét. Ezt használja a BTP, amikor a szerepkör-gyűjteményeket a fenti módon a felhasználói csoportokhoz rendeli, de a szerepkör-gyűjteményeket felhasználói attribútumokra is leképezheti, ami nagyobb rugalmasságot biztosít.

4 – Egyetlen BTP-alfiók használata csak hasonló identitásigényű alkalmazásokhoz

Környezet

A BTP-n belül minden alfiók több alkalmazást is tartalmazhat. Az IAS szempontjából azonban a "csomagolt alkalmazás" egy teljes BTP-alfiók, nem pedig a részletesebb alkalmazások. Ez azt jelenti, hogy az IAS-ben a megbízhatósági beállítások, a hitelesítés és az access konfigurációja, valamint a védjegyzési és elrendezési beállítások az adott alfiókban lévő összes alkalmazásra vonatkoznak. Hasonlóképpen, a BTP összes megbízhatósági konfigurációja és szerepkörgyűjteménye az adott alfiókon belüli összes alkalmazásra is vonatkozik.

Mit ajánlunk?

Azt javasoljuk, hogy egyetlen BTP-alfiókban több alkalmazást is kombináljon, ha az identitás szintjén hasonló követelményekkel rendelkeznek (felhasználók, csoportok, identitásszolgáltatók, szerepkörök, megbízhatósági konfiguráció, védjegyezés, ...).

Miért ez a javaslat?

Ha több olyan alkalmazást egyesít, amelyek nagyon eltérő identitáskövetelményeket támasztanak egyetlen BTP-alfiókban, egy nem biztonságos vagy egyszerűbben konfigurálható konfigurációhoz vezethet. Ha például egy megosztott erőforrás, például egy identitásszolgáltató konfigurációja megváltozik egyetlen alkalmazáshoz a BTP-ben, ez a megosztott erőforrásra támaszkodó összes alkalmazást érinti.

A megvalósítás összefoglalása

Alaposan gondolja át, hogyan szeretne több alkalmazást csoportosítani a BTP alfiókjai között. További információkért tekintse meg az SAP-fiókmodell dokumentációját.

5 – Az Éles IAS-bérlő használata az összes végfelhasználói hitelesítéshez és engedélyezéshez

Környezet

Az IAS használatakor általában éles üzemű és dev/test bérlővel rendelkezik. A BTP különböző alfiókjaihoz vagy alkalmazásaihoz kiválaszthatja, hogy melyik identitásszolgáltatót (IAS-bérlőt) használja.

Mit ajánlunk?

Javasoljuk, hogy mindig az Éles IAS-bérlőt használja a végfelhasználókkal való bármilyen interakcióhoz, még abban az esetben is, ha az alkalmazás fejlesztői/tesztelési verzióját vagy környezetét be kell jelentkeznie.

Javasoljuk, hogy csak az identitással kapcsolatos konfiguráció teszteléséhez használjon más IAS-bérlőket, amelyeket az éles bérlőtől elkülönítve kell elvégezni.

Miért ez a javaslat?

Mivel az IAS a Microsoft Entra-azonosítóval való összevonásra beállított központosított összetevő, csak egyetlen helyen kell beállítani és karbantartani az összevonási és identitáskonfigurációt. Ha ezt más IAS-bérlőkben duplikálja, az a környezetek közötti végfelhasználói hozzáférés helytelen konfigurálásához vagy inkonzisztenciáihoz vezethet.

6 – SAML-aláíró tanúsítványok átállítási folyamatának definiálása

Környezet

A Microsoft Entra ID és az IAS, valamint az IAS és a BTP közötti összevonás konfigurálásakor az SAML-metaadatok cseréje X.509-tanúsítványokat tartalmaz a két fél között küldött SAML-jogkivonatok titkosításához és titkosítási aláírásához. Ezek a tanúsítványok lejárati dátumokkal rendelkeznek, és rendszeresen frissíteni kell őket (még vészhelyzetekben is, amikor például egy tanúsítványt feltörtek).

Megjegyzés: az SAML-állítások aláírásához használt kezdeti Microsoft Entra-tanúsítvány alapértelmezett érvényességi időtartama 3 év (és vegye figyelembe, hogy a tanúsítvány a nagyvállalati alkalmazásra vonatkozik, ellentétben az OpenID Csatlakozás és az OAuth 2.0 jogkivonatokkal, amelyeket egy globális tanúsítvány ír alá a Microsoft Entra ID-ban). Dönthet úgy, hogy egy másik lejárati dátummal rendelkező új tanúsítványt hoz létre, vagy saját tanúsítványt hoz létre és importál.

A tanúsítványok lejárata után már nem használhatók, és új tanúsítványokat kell konfigurálni. Ezért létre kell hozni egy folyamatot, amely a tanúsítványkonfigurációt naprakészen tartja a függő entitáson belül (amelynek ellenőriznie kell az aláírásokat) az SAML-jogkivonatok aláírásához használt tényleges tanúsítványokkal.

Bizonyos esetekben a függő entitás ezt automatikusan megteheti úgy, hogy egy metaadat-végpontot ad meg, amely dinamikusan adja vissza a legújabb metaadat-információkat – vagyis általában egy nyilvánosan elérhető URL-címet, amelyről a függő entitás rendszeres időközönként lekérheti a metaadatokat, és frissítheti a belső konfigurációs tárolóját.

Az IAS azonban csak a metaadatok XML-fájljának importálásával engedélyezi a vállalati identitásszolgáltatók beállítását, nem támogatja a Metaadat-végpont biztosítását a Microsoft Entra metaadatainak dinamikus lekéréséhez (például https://login.microsoftonline.com/my-azuread-tenant/federationmetadata/2007-06/federationmetadata.xml?appid=my-app-id). Hasonlóképpen, a BTP nem teszi lehetővé egy új megbízhatósági konfiguráció beállítását az IAS metaadat-végpontjáról (például https://my-ias-tenant.accounts.ondemand.com/saml2/metadata), és egy metaadat XML-fájl egyszeri feltöltésére is szükség van.

Mit ajánlunk?

Ha két rendszer (például a Microsoft Entra ID és az IAS, valamint az IAS és a BTP) közötti identitás-összevonást állít be, győződjön meg arról, hogy a használt tanúsítványok lejárati dátumát rögzíti. Győződjön meg arról, hogy ezeket a tanúsítványokat előre le lehet cserélni, és dokumentált folyamattal frissítheti az új metaadatokat az összes függő entitásban, amely ezektől a tanúsítványoktól függ.

Ahogy korábban említettük, javasoljuk, hogy állítson be egy megbízhatósági konfigurációt a BTP-ben az IAS felé, amely viszont úgy van beállítva, hogy összevonja a Microsoft Entra ID-t vállalati identitásszolgáltatóként. Ebben az esetben a következő tanúsítványok (amelyek saml-aláíráshoz és titkosításhoz használatosak) fontosak:

• A BTP alfióktanúsítványa: ha ez megváltozik, az alkalmazás SAML 2.0-s konfigurációját frissíteni kell az IAS-ben.
• A bérlői tanúsítványt az IAS-ben: ha ez megváltozik, a vállalati alkalmazás SAML 2.0-s konfigurációját a Microsoft Entra-azonosítóban és a BTP megbízhatósági konfigurációját is frissíteni kell.
• A Vállalati alkalmazás tanúsítványa a Microsoft Entra-azonosítóban: ha ez megváltozik, a vállalati identitásszolgáltató SAML 2.0 konfigurációját frissíteni kell az IAS-ben.

Az SAP példaalkalmazásokkal rendelkezik az ÜGYFÉLtanúsítvány-értesítésekhez az SAP Cloud Integration használatával és a hamarosan lejáró kezeléssel. Ezt az Azure Integration Services vagy a PowerAutomate használatával lehet módosítani. Ezeket azonban a kiszolgálótanúsítványok használatához kell igazítani. Az ilyen megközelítés egyéni megvalósítást igényel.

Miért ez a javaslat?

Ha a tanúsítványok lejárhatnak, vagy ha időben lecserélik őket, de a tőlük függő függő entitások nem frissülnek az új tanúsítványadatokkal, a felhasználók már nem tudnak majd az összevonáson keresztül bejelentkezni egyik alkalmazásba sem. Ez jelentős állásidőt jelenthet az összes felhasználó számára, miközben visszaállítja a szolgáltatást a metaadatok újrakonfigurálásával.

A megvalósítás összefoglalása

Adjon hozzá egy e-mail-értesítési címet a tanúsítvány lejáratához a Microsoft Entra-azonosítóban, és állítsa be egy csoportpostaládára, hogy az ne legyen elküldve egyetlen személynek (akinek már nincs fiókja a tanúsítvány lejáratának időpontjáig). Alapértelmezés szerint csak a nagyvállalati alkalmazást létrehozó felhasználó kap értesítést.

Fontolja meg az automatizálás kiépítését a teljes tanúsítványátállítási folyamat végrehajtásához. Például rendszeres időközönként ellenőrizheti a lejáró tanúsítványokat, és lecserélheti őket, miközben az összes függő entitást frissíti az új metaadatokkal.

Az Azure AD B2C használata identitásszolgáltatóként

Az Azure Active Directory B2C szolgáltatásként biztosítja az ügyfelek közötti identitást. Tekintettel arra, hogy az Azure AD B2C integrációja hasonló ahhoz, ahogyan lehetővé tenné a nagyvállalati felhasználók számára a Microsoft Entra-azonosítóval való bejelentkezést, a fenti javaslatok többnyire akkor is érvényesek, ha az Azure AD B2C-t szeretné használni ügyfelei, felhasználói vagy polgárai számára, és lehetővé teszi számukra az előnyben részesített közösségi, nagyvállalati vagy helyi fiókazonos identitások használatát.

Van azonban néhány fontos különbség. Az Azure AD B2C vállalati identitásszolgáltatóként való beállítása az IAS-ben és a két bérlő közötti összevonás konfigurálása részletesebben ebben a blogbejegyzésben olvasható.

SAML-alkalmazás regisztrálása az Azure AD B2C-ben

Az Azure AD B2C nem rendelkezik nagyvállalati alkalmazások gyűjteményével, amelyekkel egyszerűen konfigurálhatja a vállalati identitásszolgáltatóval való megbízhatósági kapcsolatot az IAS-ben. Ehelyett egyéni szabályzatokkalkell regisztrálnia egy SAML-alkalmazást az Azure AD B2C-ben. Ez az SAML-alkalmazás ugyanolyan logikai szerepet játszik, mint a Vállalati alkalmazás a Microsoft Entra ID-ban, így például az SAML-tanúsítványok bevezetésére vonatkozó útmutatás is érvényes.

Engedélyezés az Azure AD B2C-vel

Az Azure AD B2C natív módon nem támogatja a csoportok használatát olyan felhasználói gyűjtemények létrehozására, amelyekhez hozzáférést rendelhet, ami azt jelenti, hogy a Microsoft Entra-csoportok szerepkörgyűjteményeken keresztüli engedélyezéséhez a BTP-ben történő használatához szükséges útmutatást eltérően kell implementálni.

Szerencsére az Azure AD B2C nagymértékben testreszabható, így konfigurálhatja az IAS-nek küldött SAML-jogkivonatokat, hogy bármilyen egyéni információt tartalmazzon. Az engedélyezési jogcímek támogatásának különböző lehetőségeiért tekintse meg az Azure AD B2C-alkalmazásszerepkörök mintáját kísérő dokumentációt, de összefoglalva: az API-Csatlakozás a bővíthetőségi mechanizmuson keresztül lehetőség van csoportok, alkalmazásszerepkörök vagy akár egyéni adatbázisok használatára is annak meghatározására, hogy a felhasználó mit férhet hozzá.

Függetlenül attól, hogy honnan származnak az engedélyezési információk, azokat az SAML-jogkivonatban lévő attribútumként Groups is kibocsáthatja úgy, hogy ezt az attribútumnevet a jogcímséma alapértelmezett partner jogcímtípusaként konfigurálja, vagy felülírja a partner jogcímtípusát a kimeneti jogcímeken. Vegye figyelembe azonban, hogy a BTP lehetővé teszi a szerepkör-gyűjtemények felhasználói attribútumokra való leképezését, ami azt jelenti, hogy bármilyen attribútumnév használható engedélyezési döntésekhez, még akkor is, ha nem használja az Groups attribútum nevét.

Következő lépések

• További információ az oktatóanyag kezdeti beállításáról
• a Microsoft Entra üzembe helyezésének megtervezése az SAP-forrás- és célalkalmazásokkal való felhasználói kiépítéshez, és
• AZ SAP-alkalmazásokhoz való hozzáférés kezelése
• További SAP-integrációs forgatókönyvek felfedezése a Microsoft Entra-azonosítóval és azon túl