Dela via

Scenario – Använda Microsoft Entra-ID för att skydda åtkomsten till SAP-plattformar och -program

  • Artikel

Det här dokumentet innehåller råd om teknisk design och konfiguration av SAP-plattformar och -program när du använder Microsoft Entra-ID som den primära användarautentiseringstjänsten för SAP Cloud Identity Services. SAP Cloud Identity Services omfattar identitetsautentisering, identitetsetablering, identitetskatalog och auktoriseringshantering. Läs mer om den första konfigurationen för autentisering i självstudiekursen microsoft entra-integrering med enkel inloggning (SSO) med SAP Cloud Identity Services. Mer information om etablering och andra scenarier finns i Planera distribution av Microsoft Entra för användaretablering med SAP-käll- och målprogram och hantera åtkomst till dina SAP-program.

Terminologi som används i guiden

Förkortning beskrivning
BTP SAP Business Technology Platform är en innovationsplattform som är optimerad för SAP-program i molnet. De flesta AV SAP-teknikerna som beskrivs här är en del av BTP. De produkter som formellt kallas SAP Cloud Platform är en del av SAP BTP.
IAS SAP Cloud Identity Services – Identitetsautentisering, en komponent i SAP Cloud Identity Services, är en molntjänst för autentisering, enkel inloggning och användarhantering i SAP-moln och lokala program. IAS hjälper användare att autentisera till sina egna SAP BTP-tjänstinstanser som en proxy som integreras med enkel inloggning med Microsoft Entra.
IPS SAP Cloud Identity Services – Identity Provisioning, en komponent i SAP Cloud Identity Services, är en molntjänst som hjälper dig att etablera identiteter och deras auktorisering till SAP-moln och lokalt program.
XSUAA Utökade tjänster för Cloud Foundry-användarkonto och autentisering. Cloud Foundry, en plattform som en tjänst (PaaS) som kan distribueras i olika infrastrukturer, är den miljö där SAP byggde SAP Business Technology Platform. XSUAA är en multitenant OAuth-auktoriseringsserver som är den centrala infrastrukturkomponenten i Cloud Foundry-miljön. XSUAA tillhandahåller autentisering och auktorisering för företagsanvändare i SAP BTP.
Fiori Den webbaserade användarupplevelsen för SAP (i motsats till den skrivbordsbaserade upplevelsen).

Översikt

Det finns många tjänster och komponenter i SAP- och Microsoft-teknikstacken som spelar en roll i användarautentiserings- och auktoriseringsscenarier. De viktigaste tjänsterna visas i diagrammet nedan.

Översikt över SAP-liggande

Eftersom det finns många permutationer av möjliga scenarier som ska konfigureras fokuserar vi på ett scenario som är i linje med en Microsoft Entra-identitets första strategi. Vi gör följande antaganden:

  • Du vill styra alla dina identiteter centralt och endast från Microsoft Entra-ID.
  • Du vill minska underhållsinsatserna så mycket som möjligt och automatisera autentisering och appåtkomst i Microsoft och SAP.
  • Den allmänna vägledningen för Microsoft Entra-ID med IAS gäller för appar som distribueras i BTP- och SAP SaaS-appar som konfigurerats i IAS. Specifika rekommendationer kommer också att ges när det är tillämpligt för BTP (till exempel med rollmappningar med Microsoft Entra-grupper) och SAP SaaS-appar (till exempel att använda identitetsetableringstjänsten för rollbaserad auktorisering).
  • Vi förutsätter också att användare redan har etablerats i Microsoft Entra-ID och mot alla SAP-system som kräver att användare etableras för att fungera. Oavsett hur detta uppnåddes: etableringen kunde ha gått igenom manuellt, från lokal Active Directory via Microsoft Entra Connect eller via HR-system som SAP SuccessFactors. I det här dokumentet anses SuccessFactors därför vara ett program som alla andra som (befintliga) användare kommer att logga in på. Vi täcker inte faktisk etablering av användare från SuccessFactors till Microsoft Entra-ID. Mer information om hur du tar användare till Microsoft Entra-ID för användning med SAP-arbetsbelastningar finns i Planera distribution av Microsoft Entra för användaretablering med SAP-käll- och målprogram och hantera åtkomst till dina SAP-program.

Baserat på dessa antaganden fokuserar vi främst på de produkter och tjänster som presenteras i diagrammet nedan. Det här är de olika komponenter som är mest relevanta för autentisering och auktorisering i en molnbaserad miljö.

SAP-tjänster i omfång

Om du har använt SAP Identity Management (IDM) kan du migrera scenarier för identitetshantering från SAP IDM till Microsoft Entra. Mer information finns i Migrera scenarier för identitetshantering från SAP IDM till Microsoft Entra.

Kommentar

De flesta riktlinjerna här gäller även för Azure Active Directory B2C , men det finns några viktiga skillnader. Mer information finns i Använda Azure AD B2C som identitetsprovider.

Varning

Tänk på SAP SAML-kontrollbegränsningarna och effekten av längden på sap cloud foundry-rollsamlingsnamn och mängden samlingar som delas av grupper i SAP Cloud Identity Service. Mer information finns i SAP-2732890 i SAP for Me. Överskridna gränser resulterar i auktoriseringsproblem.

Rekommendationer

Sammanfattning

1 – Använda federerad autentisering i SAP Business Technology Platform och SAP SaaS-program via SAP Identity Authentication Service

Kontext

Dina program i BTP kan använda identitetsprovidrar via förtroendekonfigurationer för att autentisera användare med hjälp av SAML 2.0-protokollet mellan BTP/XSUAA och identitetsprovidern. Observera att endast SAML 2.0 stöds, även om OpenID Connect-protokollet används mellan själva programmet och BTP/XSUAA (inte relevant i den här kontexten).

I BTP kan du välja att konfigurera en förtroendekonfiguration mot SAP Cloud Identity Services – identitetsautentisering (vilket är standard) men när din auktoritativa användarkatalog är Microsoft Entra-ID kan du konfigurera federation så att användarna kan logga in med sina befintliga Microsoft Entra-konton.

Utöver federationen kan du även konfigurera användaretablering så att Microsoft Entra-användare etableras direkt i BTP. Det finns dock inget inbyggt stöd för detta (endast för Microsoft Entra ID –> SAP Identity Authentication Service); en integrerad lösning med inbyggt stöd skulle vara BTP Identity Provisioning Service. Etablering av användarkonton i förväg kan vara användbart i auktoriseringssyfte (till exempel för att lägga till användare i roller). Beroende på kraven kan du dock också uppnå detta med Microsoft Entra-grupper (se nedan) vilket kan innebära att du inte behöver användaretablering alls.

När du konfigurerar federationsrelationen finns det flera alternativ:

  • Du kan välja att federera mot Microsoft Entra-ID direkt från BTP/XSUAA.
  • Du kan välja att federera med IAS som i sin tur har konfigurerats för att federera med Microsoft Entra-ID som företagsidentitetsprovider (även kallat "SAML-proxying").

För SAP SaaS-program etableras IAS och förkonfigureras för enkel registrering av slutanvändare. (Exempel på detta är SuccessFactors, Marketing Cloud, Cloud for Customer, Sales Cloud med flera.) Det här scenariot är mindre komplext eftersom IAS är direkt anslutet till målappen och inte är kopplat till XSUAA. I vilket fall som helst gäller samma regler för den här konfigurationen som för Microsoft Entra-ID med IAS i allmänhet.

Vad rekommenderar vi?

När din auktoritativa användarkatalog är Microsoft Entra-ID rekommenderar vi att du konfigurerar en förtroendekonfiguration i BTP mot IAS. IAS har i sin tur konfigurerats för att federera med Microsoft Entra-ID som företagsidentitetsprovider.

Konfiguration av SAP-förtroende

I förtroendekonfigurationen i BTP rekommenderar vi att "Skapa skugganvändare under inloggning" är aktiverat. På så sätt får användare som ännu inte har skapats i BTP automatiskt ett konto när de loggar in via IAS/Microsoft Entra-ID för första gången. Om den här inställningen skulle inaktiveras skulle endast företablerade användare tillåtas logga in.

Varför den här rekommendationen?

När du använder federation kan du välja att definiera förtroendekonfigurationen på BTP-underkontonivå. I så fall måste du upprepa konfigurationen för varandras underkonton som du använder. Genom att använda IAS som en mellanliggande förtroendekonfiguration kan du dra nytta av centraliserad konfiguration över flera underkonton och du kan använda IAS-funktioner som riskbaserad autentisering och centraliserad berikning av kontrollattribut. För att skydda användarupplevelsen bör dessa avancerade säkerhetsfunktioner endast tillämpas på en enda plats. Detta kan antingen vara IAS eller när du behåller Microsoft Entra-ID som det enda auktoritativa användararkivet (som är premissen för det här dokumentet), skulle detta hanteras centralt av Microsoft Entra Conditional Access Management.

Obs! För IAS anses varje underkonto vara ett "program", även om ett eller flera program kan distribueras inom det underkontot. Inom IAS kan varje sådant program konfigureras för federation med samma företagsidentitetsprovider (Microsoft Entra-ID i det här fallet).

Sammanfattning av implementeringen

I Microsoft Entra-ID:

I Microsoft Entra ID och IAS:

  • Följ dokumentationen för att ansluta Microsoft Entra-ID till IAS i federationsläge (proxy) (SAP doc, Microsoft doc). Se upp för inställningen för NameID din SSO-konfiguration i Microsoft Entra-ID eftersom UPN inte nödvändigtvis är e-postadresser.
  • Konfigurera "Bundled Application" för att använda Microsoft Entra-ID genom att gå till sidan "Villkorsstyrd autentisering" och ange "Standardautentiseringsidentitetsprovider" till företagsidentitetsprovidern som representerar din Microsoft Entra-katalog.

I BTP:

  • Konfigurera en förtroendekonfiguration mot IAS (SAP-dokument) och se till att både "Available for User Logon" och "Create Shadow Users During Logon" (Skapa skugganvändare under inloggning) är aktiverade.
  • Du kan också inaktivera "Tillgänglig för användarinloggning" på standardkonfigurationen för "SAP ID Service" så att användarna alltid autentiserar via Microsoft Entra-ID och inte visas med en skärm för att välja sin identitetsprovider.

2 – Använda Microsoft Entra-ID för autentisering och IAS/BTP för auktorisering

Kontext

När BTP och IAS har konfigurerats för användarautentisering via federation mot Microsoft Entra-ID finns det flera alternativ för att konfigurera auktorisering:

  • I Microsoft Entra-ID kan du tilldela Microsoft Entra-användare och -grupper till företagsprogrammet som representerar din SAP IAS-instans i Microsoft Entra-ID.
  • I IAS kan du använda riskbaserad autentisering för att tillåta eller blockera inloggningar och genom att göra det förhindra åtkomst till programmet i BTP.
  • I BTP kan du använda rollsamlingar för att definiera vilka användare och grupper som kan komma åt programmet och få vissa roller.

Vad rekommenderar vi?

Vi rekommenderar att du inte ger någon auktorisering direkt i Själva Microsoft Entra och uttryckligen inaktiverar "Användartilldelning krävs" i Enterprise-programmet i Microsoft Entra-ID. Observera att för SAML-program är den här inställningen aktiverad som standard, så du måste vidta explicita åtgärder för att inaktivera den.

Varför den här rekommendationen?

När programmet federeras via IAS är användaren i princip "autentisera till IAS" när det gäller Microsoft Entra-ID under inloggningsflödet. Det innebär att Microsoft Entra-ID inte har någon information om vilket slutligt BTP-program som användaren försöker logga in på. Det innebär också att auktorisering i Microsoft Entra-ID endast kan användas för att utföra mycket grov auktorisering, till exempel att tillåta användaren att logga in på något program i BTP eller till inget. Detta betonar även SAP:s strategi för att isolera appar och autentiseringsmekanismer på BTP-underkontonivå.

Även om det kan vara ett giltigt skäl för att använda "Användartilldelning krävs" innebär det att det nu finns potentiellt två olika platser där auktoriseringsinformation måste underhållas: både i Microsoft Entra-ID i Enterprise-programmet (där det gäller för alla BTP-program) samt i varje BTP-underkonto. Detta kan leda till förvirring och felkonfigurationer där auktoriseringsinställningarna uppdateras på en plats men inte på den andra. Till exempel: en användare tilläts i BTP men tilldelades inte till programmet i Microsoft Entra-ID, vilket resulterade i en misslyckad autentisering.

Sammanfattning av implementeringen

I Microsoft Entra Enterprise-programmet som representerar federationsrelationen med IAS inaktiverar du "Användartilldelning krävs". Det innebär också att du på ett säkert sätt kan hoppa över tilldelningen av användare.

3 – Använda Microsoft Entra-grupper för auktorisering via rollsamlingar i IAS/BTP

Kontext

När du vill konfigurera auktorisering för dina BTP-program finns det flera alternativ:

  • Du kan konfigurera detaljerad åtkomstkontroll i själva programmet, baserat på den inloggade användaren.
  • Du kan ange åtkomst via Roller och rollsamlingar i BTP, baserat på användartilldelningar eller grupptilldelningar.

Den slutliga implementeringen kan använda en kombination av båda strategierna. För tilldelningen via rollsamlingar kan detta dock göras från användare till användare, eller så kan man använda grupper av den konfigurerade identitetsprovidern.

Vad rekommenderar vi?

Om du vill använda Microsoft Entra-ID som auktoritativ källa för detaljerad auktorisering rekommenderar vi att du använder Microsoft Entra-grupper och tilldelar dem till rollsamlingar i BTP. Att ge användare åtkomst till vissa program innebär helt enkelt att lägga till dem i relevanta Microsoft Entra-grupper utan ytterligare konfiguration som krävs i IAS/BTP.

Med den här konfigurationen rekommenderar vi att du använder Microsoft Entra-gruppens grupp-ID (objekt-ID) som unik identifierare för gruppen, inte visningsnamnet ("sAMAccountName"). Det innebär att du måste använda grupp-ID:t som "Grupper"-försäkran i SAML-token som utfärdats av Microsoft Entra ID. Dessutom används grupp-ID:t för tilldelningen till rollsamlingen i BTP.

Använda rollsamlingar i SAP

Varför den här rekommendationen?

Om du skulle tilldela användare direkt till rollsamlingar i BTP centraliserar du inte auktoriseringsbeslut i Microsoft Entra-ID. Det innebär också att användaren redan måste finnas i IAS innan de kan tilldelas till en rollsamling i BTP – och med tanke på att vi rekommenderar federation i stället för användaretablering innebär det att användarens skuggkonto kanske inte finns ännu i IAS vid den tidpunkt då du vill utföra användartilldelningen. Att använda Microsoft Entra-grupper och tilldela dem till rollsamlingar eliminerar dessa problem.

Att tilldela grupper till rollsamlingar kan tyckas strida mot den tidigare rekommendationen att inte använda Microsoft Entra-ID för auktorisering. Även i det här fallet fattas dock auktoriseringsbeslutet fortfarande i BTP, det är bara det att beslutet nu baseras på gruppmedlemskap som upprätthålls i Microsoft Entra-ID.

Vi rekommenderar att du använder Microsoft Entra-gruppens grupp-ID i stället för dess namn eftersom grupp-ID:t är globalt unikt, oföränderligt och aldrig kan återanvändas för en annan grupp senare. Användning av gruppnamnet kan leda till problem när namnet ändras, och det finns en säkerhetsrisk när en grupp tas bort och en annan skapas med samma namn, men med användare i den som inte bör ha åtkomst till programmet.

Sammanfattning av implementeringen

I Microsoft Entra-ID:

  • Skapa grupper där användare kan läggas till som behöver åtkomst till program i BTP (till exempel skapa en Microsoft Entra-grupp för varje rollsamling i BTP).
  • I Microsoft Entra Enterprise-programmet som representerar federationsrelationen med IAS konfigurerar du SAML-användarattributen och anspråken för att lägga till ett gruppanspråk för säkerhetsgrupper:

    • Ange källattributet till "Grupp-ID" och Namn till Groups (stavat exakt så här, med versaler "G").

    • För att hålla anspråksnyttolaster små och undvika att stöta på den begränsning där Microsoft Entra-ID:t begränsar antalet gruppanspråk till 150 i SAML-intyg rekommenderar vi starkt att du begränsar de grupper som returneras i anspråken till endast de grupper som uttryckligen tilldelades:

      • Under "Vilka grupper som är associerade med användaren ska returneras i anspråket?" svarar du med "Grupper tilldelade till programmet". För de grupper som du vill inkludera som anspråk tilldelar du dem till företagsprogrammet med hjälp av avsnittet "Användare och grupper" och väljer "Lägg till användare/grupp".

      Anspråkskonfiguration för Microsoft Entra-grupp

I IAS:

  • I konfigurationen för företagsidentitetsprovidern ser du till att du inaktiverar "Använd användararkiv för identitetsautentisering". Annars bevaras inte gruppinformationen från Microsoft Entra-ID:t i SAML-token mot BTP och auktoriseringen misslyckas.

Kommentar

Om du behöver använda användararkivet för identitetsautentisering (till exempel för att inkludera anspråk som inte kan hämtas från Microsoft Entra-ID men som är tillgängliga i IAS-användararkivet), kan du behålla den här inställningen aktiverad. I så fall måste du dock konfigurera standardattributen som skickas till programmet för att inkludera relevanta anspråk som kommer från Microsoft Entra-ID (till exempel med ${corporateIdP.Groups} formatet).

I BTP:

  • På rollsamlingarna som används av programmen i det underkontot mappar du rollsamlingarna till användargrupper genom att lägga till en konfiguration för IAS-identitetsprovidern och ange Namnet till grupp-ID (objekt-ID) för Microsoft Entra-gruppen.

Kommentar

Om du skulle ha ett annat anspråk i Microsoft Entra-ID för att innehålla den auktoriseringsinformation som ska användas i BTP behöver du inte använda anspråksnamnetGroups. Det här är vad BTP använder när du mappar rollsamlingarna till användargrupper som ovan, men du kan också mappa rollsamlingarna till användarattribut som ger dig lite mer flexibilitet.

4 – Använd endast ett enda BTP-underkonto för program som har liknande identitetskrav

Kontext

Inom BTP kan varje underkonto innehålla flera program. Från IAS-synpunkt är dock ett "paketerat program" ett fullständigt BTP-underkonto, inte de mer detaljerade programmen i det. Det innebär att alla inställningar för förtroende, autentisering och åtkomstkonfiguration samt alternativ för varumärkesanpassning och layout i IAS gäller för alla program inom det underkontot. På samma sätt gäller även alla förtroendekonfigurationer och rollsamlingar i BTP för alla program i det underkontot.

Vad rekommenderar vi?

Vi rekommenderar att du kombinerar flera program i ett enda BTP-underkonto endast om de har liknande krav på identitetsnivå (användare, grupper, identitetsprovidrar, roller, förtroendekonfiguration, varumärkesanpassning, ...).

Varför den här rekommendationen?

Genom att kombinera flera program som har mycket olika identitetskrav till ett enda underkonto i BTP kan du få en konfiguration som är osäker eller enklare kan felkonfigureras. Till exempel: när en konfigurationsändring till en delad resurs som en identitetsprovider görs för ett enda program i BTP påverkar detta alla program som förlitar sig på den här delade resursen.

Sammanfattning av implementeringen

Fundera noga över hur du vill gruppera flera program mellan underkonton i BTP. Mer information finns i dokumentationen om SAP-kontomodell.

5 – Använd IAS-klientorganisationen för produktion för all slutanvändarautentisering och auktorisering

Kontext

När du arbetar med IAS har du vanligtvis en produktions- och dev/test-klientorganisation. För olika underkonton eller program i BTP kan du välja vilken identitetsprovider (IAS-klient) som ska användas.

Vad rekommenderar vi?

Vi rekommenderar att du alltid använder IAS-klientorganisationen för produktion för all interaktion med slutanvändare, även i samband med en utvecklings-/testversion eller miljö för programmet som de måste logga in på.

Vi rekommenderar att du endast använder andra IAS-klienter för testning av identitetsrelaterad konfiguration, vilket måste göras isolerat från produktionsklientorganisationen.

Varför den här rekommendationen?

Eftersom IAS är den centraliserade komponenten som har konfigurerats för att federera med Microsoft Entra-ID finns det bara en enda plats där federations- och identitetskonfigurationen måste konfigureras och underhållas. Om du duplicerar detta i andra IAS-klienter kan det leda till felkonfigurationer eller inkonsekvenser i slutanvändares åtkomst mellan miljöer.

6 – Definiera en process för att distribuera SAML-signeringscertifikat

Kontext

När du konfigurerar federation mellan Microsoft Entra ID och IAS, samt mellan IAS och BTP, utbyts SAML-metadata som innehåller X.509-certifikat som används för kryptering och kryptografiska signaturer för SAML-token som skickas mellan båda parter. Dessa certifikat har förfallodatum och måste uppdateras regelbundet (även i nödsituationer när ett certifikat till exempel komprometterades).

Obs! Standard giltighetsperioden för det första Microsoft Entra-certifikatet som används för att signera SAML-intyg är 3 år (och observera att certifikatet är specifikt för Enterprise-programmet, till skillnad från OpenID Connect- och OAuth 2.0-token som är signerade av ett globalt certifikat i Microsoft Entra-ID). Du kan välja att generera ett nytt certifikat med ett annat förfallodatum eller skapa och importera ett eget certifikat.

När certifikaten upphör att gälla kan de inte längre användas och nya certifikat måste konfigureras. Därför måste en process upprättas för att hålla certifikatkonfigurationen inom den förlitande parten (som måste verifiera signaturerna) uppdaterad med de faktiska certifikat som används för att signera SAML-token.

I vissa fall kan den förlitande parten göra detta automatiskt genom att förse den med en metadataslutpunkt som returnerar den senaste metadatainformationen dynamiskt, det vill ex. vanligtvis en offentligt tillgänglig URL från vilken den förlitande parten regelbundet kan hämta metadata och uppdatera sitt interna konfigurationsarkiv.

IAS tillåter dock endast att företagsidentitetsprovidrar konfigureras via en import av XML-metadatafilen. Den har inte stöd för att tillhandahålla en metadataslutpunkt för dynamisk hämtning av Microsoft Entra-metadata (till exempel https://login.microsoftonline.com/my-azuread-tenant/federationmetadata/2007-06/federationmetadata.xml?appid=my-app-id). På samma sätt tillåter BTP inte att en ny förtroendekonfiguration konfigureras från IAS-metadataslutpunkten (till exempel https://my-ias-tenant.accounts.ondemand.com/saml2/metadata), utan behöver även en engångsuppladdning av en XML-metadatafil.

Vad rekommenderar vi?

När du konfigurerar identitetsfederation mellan två system (till exempel Microsoft Entra ID och IAS samt IAS och BTP) kontrollerar du att du registrerar förfallodatumet för de certifikat som används. Se till att dessa certifikat kan ersättas i god tid och att det finns en dokumenterad process för att uppdatera de nya metadata i alla förlitande parter som är beroende av dessa certifikat.

Som vi har diskuterat tidigare rekommenderar vi att du konfigurerar en förtroendekonfiguration i BTP mot IAS, som i sin tur har konfigurerats för att federera med Microsoft Entra-ID som företagsidentitetsprovider. I det här fallet är följande certifikat (som används för SAML-signering och kryptering) viktiga:

  • Underkontocertifikatet i BTP: När detta ändras måste programmets SAML 2.0-konfiguration i IAS uppdateras.
  • Klientcertifikatet i IAS: när detta ändras måste både SAML 2.0-konfigurationen för företagsprogrammet i Microsoft Entra-ID och förtroendekonfigurationen i BTP uppdateras.
  • Företagsprogramcertifikatet i Microsoft Entra-ID: När detta ändras måste företagsidentitetsproviderns SAML 2.0-konfiguration i IAS uppdateras.

Rulla över SAML-signeringscertifikat

SAP har exempelimplementeringar för klientcertifikatmeddelanden med SAP Cloud Integration och hantering nära förfallodatum. Detta kan anpassas med Azure Integration Services eller PowerAutomate. De skulle dock behöva anpassas för att fungera med servercertifikat. En sådan metod kräver en anpassad implementering.

Varför den här rekommendationen?

Om certifikaten tillåts upphöra att gälla, eller när de ersätts i tid men de förlitande parter som är beroende av dem inte uppdateras med den nya certifikatinformationen, kommer användarna inte längre att kunna logga in på något program via federation. Det kan innebära betydande stilleståndstid för alla användare när du återställer tjänsten genom att konfigurera om metadata.

Sammanfattning av implementeringen

Lägg till en e-postadress för certifikatets giltighetstid i Microsoft Entra-ID och ange den till en grupppostlåda så att den inte skickas till en enskild person (som kanske inte längre har ett konto när certifikatet snart upphör att gälla). Som standard får endast den användare som skapade enterprise-programmet ett meddelande.

Överväg att skapa automatisering för att köra hela processen för certifikatåterställning. Man kan till exempel regelbundet söka efter certifikat som upphör att gälla och ersätta dem när alla förlitande parter uppdateras med de nya metadata.

Använda Azure AD B2C som identitetsprovider

Azure Active Directory B2C tillhandahåller företags-till-kund-identitet som en tjänst. Med tanke på att integreringen med Azure AD B2C liknar hur du skulle tillåta företagsanvändare att logga in med Microsoft Entra-ID gäller rekommendationerna ovan fortfarande främst när du vill använda Azure AD B2C för dina kunder, konsumenter eller medborgare och låta dem använda sina önskade sociala, företags- eller lokala kontoidentiteter.

Det finns dock några viktiga skillnader. Du kan läsa mer i det här blogginlägget om att konfigurera Azure AD B2C som företagsidentitetsprovider i IAS och konfigurera federation mellan båda klienterna.

Registrera ett SAML-program i Azure AD B2C

Azure AD B2C har inte något galleri med företagsprogram som du kan använda för att enkelt konfigurera förtroenderelationen mot företagsidentitetsprovidern i IAS. I stället måste du använda anpassade principer för att registrera ett SAML-program i Azure AD B2C. Det här SAML-programmet spelar dock samma logiska roll som företagsprogrammet i Microsoft Entra-ID: t, så samma vägledning om redundansväxling av SAML-certifikat gäller till exempel.

Auktorisering med Azure AD B2C

Azure AD B2C stöder inte internt användning av grupper för att skapa samlingar av användare som du kan tilldela åtkomst till, vilket innebär att vägledningen för att använda Microsoft Entra-grupper för auktorisering via rollsamlingar i BTP måste implementeras på olika sätt.

Lyckligtvis är Azure AD B2C mycket anpassningsbart, så du kan konfigurera SAML-token som skickas till IAS för att inkludera anpassad information. Olika alternativ för stöd för auktoriseringsanspråk finns i dokumentationen som medföljer exemplet med Azure AD B2C-approller, men sammanfattningsvis: genom utökningsmekanismen för API Connector kan du fortfarande använda grupper, approller eller till och med en anpassad databas för att avgöra vad användaren har åtkomst till.

Oavsett var auktoriseringsinformationen kommer ifrån kan den Groups sedan genereras som attributet i SAML-token genom att konfigurera det attributnamnet som standardtyp för partneranspråk i anspråksschemat eller genom att åsidosätta partneranspråkstypen för utdataanspråken. Observera dock att BTP gör att du kan mappa rollsamlingar till användarattribut, vilket innebär att alla attributnamn kan användas för auktoriseringsbeslut, även om du inte använder Groups attributnamnet.

Nästa steg