Scenario: Microsoft Entra-id gebruiken om de toegang tot SAP-platforms en -toepassingen te beveiligen

Dit document biedt advies over het technische ontwerp en de configuratie van SAP-platforms en -toepassingen bij het gebruik van Microsoft Entra ID als primaire gebruikersverificatieservice voor SAP Cloud Identity Services. SAP Cloud Identity Services omvat identiteitsverificatie, identiteitsinrichting, identiteitsdirectory en autorisatiebeheer. Meer informatie over de eerste installatie voor verificatie in de zelfstudie eenmalige aanmelding van Microsoft Entra met SAP Cloud Identity Services. Zie voor meer informatie over het inrichten en andere scenario's het implementeren van Microsoft Entra voor het inrichten van gebruikers met SAP-bron- en doeltoepassingen en het beheren van de toegang tot uw SAP-toepassingen.

Terminologie die wordt gebruikt in deze handleiding

Afkorting	Beschrijving
BTP	SAP Business Technology Platform is een innovatieplatform dat is geoptimaliseerd voor SAP-toepassingen in de cloud. De meeste SAP-technologieën die hier worden besproken, maken deel uit van BTP. De producten die formeel bekend staan als SAP Cloud Platform maken deel uit van SAP BTP.
IAS	SAP Cloud Identity Services - Identiteitsverificatie, een onderdeel van SAP Cloud Identity Services, is een cloudservice voor verificatie, eenmalige aanmelding en gebruikersbeheer in SAP-cloud- en on-premises toepassingen. Met IAS kunnen gebruikers zich verifiëren bij hun eigen SAP BTP-service-exemplaren, als proxy die kan worden geïntegreerd met Eenmalige aanmelding van Microsoft Entra.
IPS	SAP Cloud Identity Services - Identity Provisioning, een onderdeel van SAP Cloud Identity Services, is een cloudservice waarmee u identiteiten en hun autorisatie kunt inrichten voor sap-cloud en on-premises toepassingen.
XSUAA	Uitgebreide services voor het Cloud Foundry-gebruikersaccount en -verificatie. Cloud Foundry, een PaaS (Platform as a Service) die kan worden geïmplementeerd op verschillende infrastructuren, is de omgeving waarop SAP Business Technology Platform is gebouwd. XSUAA is een multitenant OAuth-autorisatieserver die het centrale infrastructuuronderdeel van de Cloud Foundry-omgeving is. XSUAA biedt verificatie en autorisatie voor zakelijke gebruikers binnen sap BTP.
Fiori	De webgebruikerservaring van SAP (in tegenstelling tot de bureaubladervaring).

Overzicht

Er zijn veel services en onderdelen in de SAP- en Microsoft-technologiestack die een rol spelen in scenario's voor de gebruikersverificatie en autorisatie. De belangrijkste services worden vermeld in het onderstaande diagram.

Omdat er veel permutaties van mogelijke scenario's moeten worden geconfigureerd, richten we ons op één scenario dat in overeenstemming is met een Microsoft Entra Identity First-strategie. We maken de volgende veronderstellingen:

• U wilt al uw identiteiten centraal en alleen beheren vanuit Microsoft Entra-id.
• U wilt het onderhoud zoveel mogelijk verminderen en de verificatie- en app-toegang automatiseren in Microsoft en SAP.
• De algemene richtlijnen voor Microsoft Entra ID met IAS zijn van toepassing op apps die zijn geïmplementeerd in BTP- en SAP SaaS-apps die zijn geconfigureerd in IAS. Specifieke aanbevelingen worden ook gegeven indien van toepassing op BTP (bijvoorbeeld het gebruik van roltoewijzingen met Microsoft Entra-groepen) en SAP SaaS-apps (bijvoorbeeld het gebruik van identiteitsinrichtingsservice voor autorisatie op basis van rollen).
• We gaan er ook van uit dat gebruikers al zijn ingericht in Microsoft Entra ID en naar sap-systemen waarvoor gebruikers moeten worden ingericht om te functioneren. Hoe dat ook is bereikt: inrichting kan handmatig zijn uitgevoerd, van on-premises Active Directory via Microsoft Entra Connect of via HR-systemen zoals SAP SuccessFactors. In dit document wordt SuccessFactors daarom beschouwd als een toepassing zoals elke andere waarop (bestaande) gebruikers zich zullen aanmelden. We hebben geen betrekking op de daadwerkelijke inrichting van gebruikers van SuccessFactors in Microsoft Entra-id. Zie Het implementeren van Microsoft Entra voor gebruikersinrichting met SAP-bron- en doeltoepassingen en het beheren van de toegang tot uw SAP-toepassingen voor meer informatie over het overbrengen van gebruikers naar Microsoft Entra-id voor gebruik met SAP-workloads.

Op basis van deze veronderstellingen richten we ons voornamelijk op de producten en services die in het onderstaande diagram worden gepresenteerd. Dit zijn de verschillende onderdelen die het meest relevant zijn voor de verificatie en autorisatie in een cloudomgeving.

Als u SAP Identity Management (IDM) hebt gebruikt, kunt u scenario's voor identiteitsbeheer migreren van SAP IDM naar Microsoft Entra. Zie Scenario's voor identiteitsbeheer migreren van SAP IDM naar Microsoft Entra voor meer informatie.

Notitie

De meeste richtlijnen hier zijn ook van toepassing op Azure Active Directory B2C, maar er zijn een aantal belangrijke verschillen. Zie Azure AD B2C gebruiken als id-provider voor meer informatie.

Waarschuwing

Houd rekening met de SAP SAML-assertielimieten en -impact van de lengte van de namen van de sap Cloud Foundry-rolverzamelingen en de hoeveelheid verzamelingen die zijn geproxied door groepen in SAP Cloud Identity Service. Zie SAP-notitie 2732890 in SAP for Me voor meer informatie. Overschreden limieten leiden tot autorisatieproblemen.

Aanbevelingen

Samenvatting

• 1 - Gebruik de federatieve verificatie in SAP Business Technology Platform en SAP SaaS-toepassingen via SAP Identity Authentication Service
• 2 - Microsoft Entra-id gebruiken voor verificatie en IAS/BTP voor autorisatie
• 3 - Microsoft Entra-groepen gebruiken voor autorisatie via rolverzamelingen in IAS/BTP
• 4 - Gebruik een enkele BTP-subaccount alleen voor toepassingen met vergelijkbare identiteitsvereisten
• 5 - Gebruik de productie-IAS-tenant voor alle verificatie en autorisatie van eindgebruikers
• 6 - Een proces definiëren voor rollover van SAML-handtekeningcertificaten

1 - Gebruik de federatieve verificatie in SAP Business Technology Platform en SAP SaaS-toepassingen via SAP Identity Authentication Service

Context

Uw toepassingen in BTP kunnen id-providers gebruiken via Trust Configurations om gebruikers te verifiëren met behulp van het SAML 2.0-protocol tussen BTP/XSUAA en de id-provider. Houd er rekening mee dat alleen SAML 2.0 wordt ondersteund, ook al wordt het OpenID Connect-protocol gebruikt tussen de toepassing zelf en BTP/XSUAA (niet relevant in deze context).

In BTP kunt u ervoor kiezen om een vertrouwensconfiguratie in te stellen voor SAP Cloud Identity Services - Identiteitsverificatie (dit is de standaardinstelling), maar wanneer uw gezaghebbende gebruikersmap Microsoft Entra-id is, kunt u federatie instellen zodat gebruikers zich kunnen aanmelden met hun bestaande Microsoft Entra-accounts.

Boven op federatie kunt u eventueel ook inrichting van gebruikers instellen, zodat Microsoft Entra-gebruikers vooraf worden ingericht in BTP. Er is echter geen systeemeigen ondersteuning voor (alleen voor Microsoft Entra ID -> SAP Identity Authentication Service); een geïntegreerde oplossing met systeemeigen ondersteuning is de BTP Identity Provisioning Service. Het vooraf inrichten van gebruikersaccounts kan handig zijn voor autorisatiedoeleinden (bijvoorbeeld om gebruikers toe te voegen aan rollen). Afhankelijk van de vereisten kunt u dit echter ook bereiken met Microsoft Entra-groepen (zie hieronder), wat kan betekenen dat u helemaal geen gebruikersinrichting nodig hebt.

Bij het instellen van de federatierelatie zijn er meerdere opties:

• U kunt ervoor kiezen om rechtstreeks vanuit BTP/XSUAA naar Microsoft Entra ID te federeren.
• U kunt ervoor kiezen om te federeren met IAS die op zijn beurt is ingesteld om te federeren met Microsoft Entra ID als een corporate identity provider (ook wel bekend als 'SAML Proxying').

Voor SAP SaaS-toepassingen is IAS ingericht en vooraf geconfigureerd voor de eenvoudige onboarding van eindgebruikers. (Voorbeelden hiervan zijn SuccessFactors, Marketing Cloud, Cloud for Customer, Sales Cloud en andere.) Dit scenario is minder complex, omdat IAS rechtstreeks is verbonden met de doel-app en niet wordt geproxied met XSUAA. In elk geval gelden dezelfde regels voor deze installatie als voor Microsoft Entra-id met IAS in het algemeen.

Wat raden we aan?

Wanneer uw gezaghebbende gebruikersmap Microsoft Entra-id is, raden we u aan om een vertrouwensconfiguratie in BTP in te stellen voor IAS. IAS is op zijn beurt ingesteld om te federeren met Microsoft Entra ID als een zakelijke id-provider.

In de vertrouwensconfiguratie in BTP raden we u aan "Schaduwgebruikers maken tijdens het aanmelden" is ingeschakeld. Op deze manier krijgen gebruikers die nog niet in BTP zijn gemaakt, automatisch een account wanneer ze zich aanmelden via IAS/Microsoft Entra ID voor het eerst. Als deze instelling zou worden uitgeschakeld, mogen alleen vooraf ingerichte gebruikers zich aanmelden.

Waarom deze aanbeveling?

Wanneer u federatie gebruikt, kunt u ervoor kiezen de vertrouwensconfiguratie te definiëren op het niveau van het BTP-subaccount. In dat geval moet u de configuratie herhalen voor elk ander Subaccount dat u gebruikt. Door IAS te gebruiken als een tussenliggende vertrouwensconfiguratie, profiteert u van de gecentraliseerde configuratie in meerdere subaccounts en kunt u IAS-functies gebruiken, zoals op risico gebaseerde verificatie en gecentraliseerde verrijking van assertiekenmerken. Om de gebruikerservaring te beschermen, moeten deze geavanceerde beveiligingsfuncties alleen op één locatie worden afgedwongen. Dit kan IAS zijn of wanneer Microsoft Entra-id wordt bewaard als het enige gezaghebbende gebruikersarchief (zoals het uitgangspunt van dit document), wordt dit centraal afgehandeld door Microsoft Entra Conditional Access Management.

Opmerking: voor IAS wordt elk subaccount beschouwd als een 'toepassing', ook al kunnen binnen dat Subaccount een of meer toepassingen worden geïmplementeerd. Binnen IAS kan elke dergelijke toepassing worden ingesteld voor federatie met dezelfde zakelijke id-provider (Microsoft Entra-id in dit geval).

Samenvatting van de implementatie

In Microsoft Entra ID:

• Configureer eventueel Microsoft Entra ID voor naadloze eenmalige aanmelding (naadloze eenmalige aanmelding), waarmee gebruikers automatisch worden aangemeld wanneer ze zich op hun bedrijfsapparaten bevinden die zijn verbonden met uw bedrijfsnetwerk. Wanneer de functie is ingeschakeld, hoeven gebruikers hun wachtwoord niet in te typen om zich aan te melden bij Microsoft Entra ID en hun gebruikersnaam ook meestal niet.

In Microsoft Entra ID en IAS:

• Volg de documentatie om Microsoft Entra-id te verbinden met IAS in de federatiemodus (proxy) (SAP-document, Microsoft-document). Let op de instelling voor uw NameID configuratie voor eenmalige aanmelding in Microsoft Entra-id, omdat UPN's niet noodzakelijkerwijs e-mailadressen zijn.
• Configureer de 'gebundelde toepassing' om Microsoft Entra-id te gebruiken door naar de pagina Voorwaardelijke verificatie te gaan en de 'Standaardverificatie-id-provider' in te stellen op de bedrijfsidentiteitsprovider die uw Microsoft Entra-directory vertegenwoordigt.

In BTP:

• Stel een vertrouwensconfiguratie in voor IAS (SAP doc) en zorg ervoor dat 'Beschikbaar voor gebruikersaanmelding' en 'Create Shadow Users During Logon' beide zijn ingeschakeld.
• Schakel desgewenst 'Beschikbaar voor gebruikersaanmelding' uit in de standaardvertrouwensconfiguratie SAP ID-service, zodat gebruikers altijd verifiëren via Microsoft Entra-id en geen scherm zien om hun id-provider te kiezen.

2 - Microsoft Entra-id gebruiken voor verificatie en IAS/BTP voor autorisatie

Context

Wanneer BTP en IAS zijn geconfigureerd voor gebruikersverificatie via federatie naar Microsoft Entra-id, zijn er meerdere opties voor het configureren van autorisatie:

• In Microsoft Entra-id kunt u Microsoft Entra-gebruikers en -groepen toewijzen aan de ondernemingstoepassing die uw SAP IAS-exemplaar vertegenwoordigt in Microsoft Entra-id.
• In IAS kunt u op risico gebaseerde verificatie gebruiken om aanmeldingen toe te staan of te blokkeren. Dit doet u om de toegang tot de toepassing in BTP te voorkomen.
• In BTP kunt u rolverzamelingen gebruiken om te definiëren welke gebruikers en groepen toegang hebben tot de toepassing en om bepaalde rollen op te halen.

Wat raden we aan?

U wordt aangeraden geen autorisatie rechtstreeks in Microsoft Entra zelf te plaatsen en expliciet 'Gebruikerstoewijzing vereist' uit te schakelen voor de Enterprise Application in Microsoft Entra ID. Houd er rekening mee dat deze instelling voor SAML-toepassingen standaard is ingeschakeld, dus u moet expliciet actie ondernemen om deze uit te schakelen.

Waarom deze aanbeveling?

Wanneer de toepassing wordt gefedereerd via IAS, is de gebruiker vanuit het oogpunt van Microsoft Entra ID in wezen 'verifiëren bij IAS' tijdens de aanmeldingsstroom. Dit betekent dat Microsoft Entra ID geen informatie heeft over de uiteindelijke BTP-toepassing waarmee de gebruiker zich probeert aan te melden. Dat impliceert ook dat autorisatie in Microsoft Entra ID alleen kan worden gebruikt om zeer grof autorisatie uit te voeren, bijvoorbeeld om de gebruiker toe te staan zich aan te melden bij een toepassing in BTP of geen. Dit benadrukt ook de strategie van SAP om apps en verificatiemechanismen te isoleren op het niveau van het BTP-subaccount.

Hoewel dit een geldige reden kan zijn voor het gebruik van 'Gebruikerstoewijzing vereist', betekent dit dat er nu mogelijk twee verschillende plaatsen zijn waar autorisatiegegevens moeten worden onderhouden: zowel in Microsoft Entra-id op de bedrijfstoepassing (waar deze van toepassing is op alle BTP-toepassingen), als in elk BTP-subaccount. Dit kan leiden tot verwarring en onjuiste configuraties waarbij de autorisatie-instellingen op de ene plaats worden bijgewerkt, maar niet op de andere. Bijvoorbeeld: een gebruiker is toegestaan in BTP, maar niet toegewezen aan de toepassing in Microsoft Entra-id, wat resulteert in een mislukte verificatie.

Samenvatting van de implementatie

Schakel 'Gebruikerstoewijzing vereist' uit in de Microsoft Entra Enterprise-toepassing die de federatierelatie met IAS vertegenwoordigt. Dit betekent ook dat u de toewijzing van gebruikers veilig kunt overslaan.

3 - Microsoft Entra-groepen gebruiken voor autorisatie via rolverzamelingen in IAS/BTP

Context

Wanneer u de autorisatie wilt configureren voor uw BTP-toepassingen bestaan er meerdere opties:

• U kunt fijnmazig toegangsbeheer in de toepassing zelf configureren op basis van de aangemelde gebruiker.
• U kunt toegang opgeven via rollen en rolverzamelingen in BTP, op basis van gebruikers- of groepstoewijzingen.

De uiteindelijke implementatie kan een combinatie van beide strategieën gebruiken. Voor de toewijzing via rolverzamelingen kan dit echter per gebruiker worden gedaan of kan een groep van de geconfigureerde id-provider worden gebruikt.

Wat raden we aan?

Als u Microsoft Entra-id wilt gebruiken als gezaghebbende bron voor fijnmazige autorisatie, raden we u aan Microsoft Entra-groepen te gebruiken en deze toe te wijzen aan rolverzamelingen in BTP. Het verlenen van gebruikers toegang tot bepaalde toepassingen betekent dan gewoon dat ze worden toegevoegd aan de relevante Microsoft Entra-groep(en) zonder verdere configuratie die vereist is in IAS/BTP.

Met deze configuratie raden we u aan de groeps-id (object-id) van de Microsoft Entra-groep te gebruiken als de unieke id van de groep, niet de weergavenaam (sAMAccountName). Dit betekent dat u de groeps-id moet gebruiken als de assertie 'Groepen' in het SAML-token dat is uitgegeven door Microsoft Entra ID. Daarnaast wordt de groeps-id gebruikt voor de toewijzing aan de rolverzameling in BTP.

Waarom deze aanbeveling?

Als u gebruikers rechtstreeks aan rolverzamelingen in BTP toewijst, centraliseert u geen autorisatiebeslissingen in Microsoft Entra-id. Dit betekent ook dat de gebruiker al in IAS moet bestaan voordat deze kan worden toegewezen aan een rolverzameling in BTP. Aangezien we federatie in plaats van gebruikersinrichting aanbevelen, betekent dit dat het schaduwaccount van de gebruiker mogelijk nog niet bestaat in IAS op het moment dat u de gebruikerstoewijzing wilt uitvoeren. Als u Microsoft Entra-groepen gebruikt en deze toewijst aan rolverzamelingen, worden deze problemen geëlimineerd.

Het toewijzen van groepen aan rolverzamelingen lijkt mogelijk in strijd te zijn met de eerdere aanbeveling om Microsoft Entra-id niet te gebruiken voor autorisatie. Zelfs in dit geval wordt de autorisatiebeslissing nog steeds genomen in BTP, het is alleen dat de beslissing nu is gebaseerd op groepslidmaatschap dat in Microsoft Entra ID wordt gehandhaafd.

We raden u aan de groeps-id van de Microsoft Entra-groep te gebruiken in plaats van de naam, omdat de groeps-id wereldwijd uniek, onveranderbaar is en later nooit opnieuw kan worden gebruikt voor een andere groep; overwegende dat het gebruik van de groepsnaam kan leiden tot problemen wanneer de naam wordt gewijzigd en er een beveiligingsrisico bestaat bij het verwijderen van een groep en een andere die wordt gemaakt met dezelfde naam, maar met gebruikers erin die geen toegang tot de toepassing moeten hebben.

Samenvatting van de implementatie

In Microsoft Entra ID:

• Maak groepen waaraan gebruikers kunnen worden toegevoegd die toegang nodig hebben tot toepassingen in BTP (maak bijvoorbeeld een Microsoft Entra-groep voor elke rolverzameling in BTP).
• Configureer in de Microsoft Entra Enterprise-toepassing die de federatierelatie met IAS vertegenwoordigt de SAML-gebruikerskenmerken en -claims om een groepsclaim toe te voegen voor beveiligingsgroepen:

  • Stel het Bronkenmerk in op 'Groeps-id' en de naam Groups op (precies zoals deze wordt gespeld, met hoofdletter 'G').

  • Om de nettoladingen van claims klein te houden en te voorkomen dat microsoft Entra ID het aantal groepsclaims beperkt tot 150 in SAML-asserties, raden we u ten zeerste aan om de groepen die in de claims worden geretourneerd, te beperken tot alleen de groepen die expliciet zijn toegewezen:

    • Onder 'Welke groepen die aan de gebruiker zijn gekoppeld, moeten worden geretourneerd in de claim?'-antwoord met 'Groepen toegewezen aan de toepassing'. Voor de groepen die u wilt opnemen als claims, wijst u deze toe aan de ondernemingstoepassing met behulp van de sectie Gebruikers en groepen en selecteert u 'Gebruiker/groep toevoegen'.

    

In IAS:

• Zorg ervoor dat u in de configuratie van de bedrijfsidentiteitsprovider onder de opties Voor identiteitsfederatie 'Gebruikersarchief voor identiteitsverificatie gebruiken' uitschakelt. Anders zou de groepsinformatie van Microsoft Entra-id niet behouden blijven in het SAML-token voor BTP en de autorisatie mislukt.

Notitie

Als u het gebruikersarchief voor identiteitsverificatie moet gebruiken (als u bijvoorbeeld claims wilt opnemen die niet kunnen worden opgehaald uit Microsoft Entra-id, maar die beschikbaar zijn in het IAS-gebruikersarchief), kunt u deze instelling ingeschakeld laten. In dat geval moet u echter de standaardkenmerken configureren die naar de toepassing worden verzonden om de relevante claims op te nemen die afkomstig zijn van Microsoft Entra-id (bijvoorbeeld met de ${corporateIdP.Groups} indeling).

In BTP:

• Wijs in de rolverzamelingen die door de toepassingen in dat subaccount worden gebruikt, de rolverzamelingen toe aan gebruikersgroepen door een configuratie voor de IAS-id-provider toe te voegen en de naam in te stellen op de groeps-id (object-id) van de Microsoft Entra-groep.

Notitie

Als u een andere claim in Microsoft Entra-id zou hebben om de autorisatiegegevens te bevatten die moeten worden gebruikt in BTP, hoeft u de Groups claimnaam niet te gebruiken. Dit is wat BTP gebruikt wanneer u de rolverzamelingen toe te wijzen aan gebruikersgroepen zoals hierboven, maar u kunt ook de rolverzamelingen toewijzen aan gebruikerskenmerken, waardoor u wat meer flexibiliteit hebt.

4 - Gebruik een enkele BTP-subaccount alleen voor toepassingen met vergelijkbare identiteitsvereisten

Context

Binnen BTP kan elk subaccount meerdere toepassingen bevatten. Vanuit het IAS-oogpunt is een gebundelde toepassing echter een volledig BTP-subaccount, niet de meer gedetailleerde toepassingen in het account. Dit betekent dat alle vertrouwensinstellingen, verificatie en toegangsconfiguratie en opties voor huisstijl en indeling in IAS van toepassing zijn op alle toepassingen binnen dat Subaccount. Zo zijn ook alle vertrouwensconfiguraties en rolverzamelingen in BTP van toepassing op alle toepassingen binnen dat subaccount.

Wat raden we aan?

We raden u aan meerdere toepassingen te combineren in een enkele BTP-subaccount als ze vergelijkbare vereisten hebben op identiteitsniveau (gebruikers, groepen, id-providers, rollen, vertrouwensconfiguratie, huisstijl, ...).

Waarom deze aanbeveling?

Door meerdere toepassingen met zeer verschillende identiteitsvereisten te combineren in één subaccount in BTP, kunt u uiteindelijk een configuratie krijgen die onveilig is of eenvoudiger onjuist kan worden geconfigureerd. Bijvoorbeeld: wanneer een configuratiewijziging in een gedeelde resource, zoals een id-provider, wordt aangebracht voor één toepassing in BTP, heeft dit een invloed op alle toepassingen die afhankelijk zijn van deze gedeelde resource.

Samenvatting van de implementatie

Overweeg zorgvuldig hoe u meerdere toepassingen wilt groeperen in Subaccounts in BTP. Raadpleeg de SAP accountmodel documentatie voor meer informatie.

5 - Gebruik de productie-IAS-tenant voor alle verificatie en autorisatie van eindgebruikers

Context

Wanneer u met IAS werkt, hebt u doorgaans een Productie- en Dev/Test-tenant. Voor verschillende subaccounts of toepassingen in BTP kunt u kiezen welke id-provider (IAS-tenant) u wilt gebruiken.

Wat raden we aan?

We raden u aan altijd de Production IAS-tenant te gebruiken voor elke interactie met eindgebruikers, zelfs in de context van een ontwikkelings-/testversie of -omgeving van de toepassing waarmee ze zich moeten aanmelden.

Het is raadzaam andere IAS-tenants alleen te gebruiken voor het testen van de identiteitsgerelateerde configuratie, die geïsoleerd van de productie-tenant moet worden uitgevoerd.

Waarom deze aanbeveling?

Omdat IAS het gecentraliseerde onderdeel is dat is ingesteld voor federatie met Microsoft Entra-id, is er slechts één plaats waar de federatie- en identiteitsconfiguratie moet worden ingesteld en onderhouden. Het dupliceren hiervan in andere IAS-tenants kan leiden tot onjuiste configuraties of inconsistenties in de toegang van eindgebruikers tussen omgevingen.

6 - Een proces definiëren voor rollover van SAML-handtekeningcertificaten

Context

Bij het configureren van federatie tussen Microsoft Entra-id en IAS, evenals tussen IAS en BTP, worden SAML-metagegevens uitgewisseld die X.509-certificaten bevatten die worden gebruikt voor versleuteling en cryptografische handtekeningen van de SAML-tokens die tussen beide partijen worden verzonden. Deze certificaten hebben vervaldatums en moeten periodiek worden bijgewerkt (zelfs in situaties waarin een certificaat is aangetast).

Opmerking: de standaard geldigheidsperiode van het eerste Microsoft Entra-certificaat dat wordt gebruikt voor het ondertekenen van SAML-asserties is drie jaar (en houd er rekening mee dat het certificaat specifiek is voor de bedrijfstoepassing, in tegenstelling tot OpenID Connect- en OAuth 2.0-tokens die zijn ondertekend door een globaal certificaat in Microsoft Entra-id). U kunt ervoor kiezen een nieuw certificaat met een andere vervaldatum te genereren of uw eigen certificaat te maken en te importeren.

Wanneer certificaten verlopen, kunnen ze niet meer worden gebruikt en moeten nieuwe certificaten worden geconfigureerd. Daarom moet een proces tot stand worden gebracht om de certificaatconfiguratie binnen de relying party (die de handtekeningen moet valideren) up-to-date te houden met de werkelijke certificaten die worden gebruikt om de SAML-tokens te ondertekenen.

In sommige gevallen kan de relying party dit automatisch doen door het op te geven met een metagegevenseindpunt dat dynamisch de meest recente metagegevensgegevens retourneert, dat wil bijvoorbeeld een openbaar toegankelijke URL waaruit de relying party periodiek de metagegevens kan ophalen en het interne configuratiearchief kan bijwerken.

IAS staat echter alleen toe dat zakelijke id-providers worden ingesteld via een import van het XML-bestand met metagegevens. Het biedt geen ondersteuning voor het bieden van een eindpunt voor metagegevens voor dynamisch ophalen van de Microsoft Entra-metagegevens (bijvoorbeeld https://login.microsoftonline.com/my-azuread-tenant/federationmetadata/2007-06/federationmetadata.xml?appid=my-app-id). Zo staat BTP ook niet toe dat er een nieuwe vertrouwensconfiguratie wordt ingesteld vanuit het IAS-metagegevenseindpunt (bijvoorbeeld https://my-ias-tenant.accounts.ondemand.com/saml2/metadata), moet er ook een eenmalige upload van een XML-bestand met metagegevens worden uitgevoerd.

Wat raden we aan?

Bij het instellen van identiteitsfederatie tussen twee systemen (bijvoorbeeld Microsoft Entra-id en IAS en IAS en BTP), moet u ervoor zorgen dat u de vervaldatum van de gebruikte certificaten vastlegt. Zorg ervoor dat deze certificaten ruim van tevoren kunnen worden vervangen en dat er een gedocumenteerd proces is om de nieuwe metagegevens bij te werken in alle relying party's die afhankelijk zijn van deze certificaten.

Zoals eerder besproken, raden we u aan om een vertrouwensconfiguratie in BTP in te stellen voor IAS, die op zijn beurt is ingesteld om te federeren met Microsoft Entra-id als een zakelijke id-provider. In dit geval zijn de volgende certificaten (die worden gebruikt voor SAML-ondertekening en -versleuteling) belangrijk:

• Het subaccount-certificaat in BTP: wanneer dit wordt gewijzigd, moet de SAML 2.0-configuratie van de toepassing in IAS worden bijgewerkt.
• Het tenantcertificaat in IAS: wanneer dit wordt gewijzigd, moeten zowel de SAML 2.0-configuratie van de bedrijfstoepassing in Microsoft Entra-id als de vertrouwensconfiguratie in BTP worden bijgewerkt.
• Het certificaat van de bedrijfstoepassing in Microsoft Entra-id: wanneer deze wijziging wordt gewijzigd, moet de SAML 2.0-configuratie van de corporate identity provider in IAS worden bijgewerkt.

SAP heeft voorbeeld-implementaties voor clientcertificaatmeldingen met SAP Cloud Integration en verwerking van bijna verlopen. Dit kan worden aangepast met Azure Integration Services of PowerAutomate. Ze moeten echter worden aangepast om te kunnen werken met servercertificaten. Een dergelijke aanpak vereist een aangepaste implementatie.

Waarom deze aanbeveling?

Als de certificaten mogen verlopen of als ze op tijd worden vervangen, maar de relying party's die ervan afhankelijk zijn, niet worden bijgewerkt met de nieuwe certificaatgegevens, kunnen gebruikers zich niet meer aanmelden bij een toepassing via federatie. Dit kan resulteren in aanzienlijke downtime voor alle gebruikers terwijl u de service herstelt door de metagegevens opnieuw te configureren.

Samenvatting van de implementatie

Voeg een e-mailmeldingsadres toe voor het verlopen van certificaten in Microsoft Entra-id en stel het in op een groepspostvak, zodat het niet naar één persoon wordt verzonden (die mogelijk zelfs geen account meer heeft wanneer het certificaat bijna verloopt). Standaard ontvangt alleen de gebruiker die de bedrijfstoepassing heeft gemaakt een melding.

Overweeg automatisering in te stellen om het volledige rollover-proces van de certificaten uit te voeren. U kunt bijvoorbeeld periodiek controleren op verlopende certificaten en deze vervangen tijdens het bijwerken van alle relying party's met de nieuwe metagegevens.

Met behulp van Azure AD B2C als de id-provider

Azure Active Directory B2C biedt business-to-customer-identificatie als een service. Aangezien de integratie met Azure AD B2C vergelijkbaar is met de manier waarop zakelijke gebruikers zich kunnen aanmelden met Microsoft Entra ID, zijn de bovenstaande aanbevelingen nog steeds voornamelijk van toepassing wanneer u Azure AD B2C wilt gebruiken voor uw klanten, consumenten of burgers en toestaan dat ze hun voorkeursidentiteiten voor sociale, ondernemings- of lokale accounts gebruiken.

Er zijn echter een aantal belangrijke verschillen. Het instellen van Azure AD B2C als een zakelijke id-provider in IAS en het configureren van federatie tussen beide tenants wordt in dit blogbericht uitgebreider beschreven.

Een SAML-toepassing registreren in Azure AD B2C

Azure AD B2C beschikt niet over een galerie met bedrijfstoepassingen die u kunt gebruiken om de vertrouwensrelatie eenvoudig te configureren voor de corporate identity provider in IAS. In plaats daarvan moet u een aangepast beleid gebruiken om een SAML-toepassing te registreren in Azure AD B2C. Deze SAML-toepassing speelt echter dezelfde logische rol als de bedrijfstoepassing in Microsoft Entra ID, dus dezelfde richtlijnen voor de rollover van SAML-certificaten zijn bijvoorbeeld van toepassing.

Autorisatie met Azure AD B2C

Azure AD B2C biedt geen systeemeigen ondersteuning voor het gebruik van groepen voor het maken van verzamelingen gebruikers waartoe u toegang kunt toewijzen. Dit betekent dat de richtlijnen voor het gebruik van Microsoft Entra-groepen voor autorisatie via rollenverzamelingen in BTP anders moeten worden geïmplementeerd.

Gelukkig is Azure AD B2C zeer aanpasbaar, zodat u de SAML-tokens kunt configureren die naar IAS worden verzonden om aangepaste gegevens op te nemen. Voor verschillende opties voor het ondersteunen van autorisatieclaims raadpleegt u de documentatie bij het voorbeeld Azure AD B2C-app-rollen, maar kortom: via het uitbreidbaarheidsmechanisme van de API Connector kunt u desgewenst nog steeds groepen, app-rollen of zelfs een aangepaste database gebruiken om te bepalen waartoe de gebruiker toegang heeft.

Ongeacht waar de autorisatiegegevens vandaan komen, kunnen deze vervolgens worden verzonden als het Groups kenmerk in het SAML-token door die kenmerknaam te configureren als het standaard claimtype van de partner in het claimschema of door het claimtype van de partner te overschrijven op de uitvoerclaims. Houd er echter rekening mee dat u met BTP rolverzamelingen kunt toewijzen aan gebruikerskenmerken. Dit betekent dat elke kenmerknaam kan worden gebruikt voor autorisatiebeslissingen, zelfs als u de Groups kenmerknaam niet gebruikt.

Volgende stappen

• Meer informatie over de eerste installatie in deze zelfstudie
• Microsoft Entra implementeren voor het inrichten van gebruikers met SAP-bron- en doeltoepassingen en
• toegang tot uw SAP-toepassingen beheren
• Ontdek aanvullende SAP-integratiescenario's met Microsoft Entra-id en verder