Delen via

Opties voor SAML-id-provider configureren met Azure Active Directory B2C

  • Artikel

Azure Active Directory B2C (Azure AD B2C) ondersteunt federatie met SAML 2.0-id-providers. In dit artikel wordt beschreven hoe u de beveiligingsverklaringen parseert en de configuratieopties die beschikbaar zijn bij het inschakelen van aanmelding met een SAML-id-provider.

Voordat u begint, gebruikt u de selector Een beleidstype kiezen om het type beleid te kiezen dat u instelt. U kunt in Azure Active Directory B2C op twee manieren definiëren hoe gebruikers met uw toepassingen communiceren: via vooraf gedefinieerde gebruikersstromen of via volledig configureerbaar aangepast beleid. De stappen die in dit artikel zijn vereist, verschillen voor elke methode.

Deze functie is alleen beschikbaar voor aangepast beleid. Voor configuratiestappen selecteert u Aangepast beleid in de voorgaande selector.

Claimtoewijzing

Het element OutputClaims bevat een lijst met claims die worden geretourneerd door de SAML-id-provider. U moet de naam van de claim die is gedefinieerd in uw beleid toewijzen aan de naam die is gedefinieerd in de id-provider. Controleer uw id-provider op de lijst met claims (asserties). U kunt ook de inhoud controleren van het SAML-antwoord dat uw id-provider retourneert. Zie Fouten opsporen in de SAML-berichten voor meer informatie. Als u een claim wilt toevoegen, definieert u eerst een claim en voegt u vervolgens de claim toe aan de verzameling uitvoerclaims.

U kunt ook claims opnemen die niet worden geretourneerd door de id-provider, zolang u het DefaultValue kenmerk instelt. De standaardwaarde kan statisch of dynamisch zijn, met behulp van contextclaims.

Het element van de uitvoerclaim bevat de volgende kenmerken:

  • ClaimTypeReferenceId is de verwijzing naar een claimtype.
  • PartnerClaimType is de naam van de eigenschap die SAML-assertie wordt weergegeven.
  • DefaultValue is een vooraf gedefinieerde standaardwaarde. Als de claim leeg is, wordt de standaardwaarde gebruikt. U kunt ook claimomzetters gebruiken met een contextuele waarde, zoals de correlatie-id of het IP-adres van de gebruiker.

Onderwerpnaam

Als u de SAML-assertie NameId in het Onderwerp wilt lezen als een genormaliseerde claim, stelt u de claim PartnerClaimType in op de waarde van het SPNameQualifier kenmerk. Als het SPNameQualifierkenmerk niet wordt weergegeven, stelt u de claim PartnerClaimType in op de waarde van het NameQualifier kenmerk.

SAML-bewering:

<saml:Subject>
  <saml:NameID SPNameQualifier="http://your-idp.com/unique-identifier" Format="urn:oasis:names:tc:SAML:2.0:nameid-format:transient">david@contoso.com</saml:NameID>
  <SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
    <SubjectConfirmationData InResponseTo="_cd37c3f2-6875-4308-a9db-ce2cf187f4d1" NotOnOrAfter="2020-02-15T16:23:23.137Z" Recipient="https://<your-tenant>.b2clogin.com/<your-tenant>.onmicrosoft.com/B2C_1A_TrustFrameworkBase/samlp/sso/assertionconsumer" />
    </SubjectConfirmation>
  </saml:SubjectConfirmation>
</saml:Subject>

De uitvoerclaim:

<OutputClaim ClaimTypeReferenceId="issuerUserId" PartnerClaimType="http://your-idp.com/unique-identifier" />

Als beide SPNameQualifier of NameQualifier kenmerken niet worden weergegeven in de SAML-assertie, stelt u de claim PartnerClaimType in op assertionSubjectName. Zorg ervoor dat de NameId de eerste waarde in assertie XML is. Wanneer u meer dan één bewering definieert, kiest Azure AD B2C de onderwerpwaarde uit de allerlaatste assertie.

SAML-protocolbindingen configureren

De SAML-aanvragen worden verzonden naar de id-provider zoals opgegeven in het metagegevenselement SingleSignOnService van de id-provider. De meeste autorisatieaanvragen van de id-providers worden rechtstreeks in de URL-queryreeks van een HTTP GET-aanvraag meegenomen (omdat de berichten relatief kort zijn). Raadpleeg de documentatie van uw id-provider voor het configureren van de bindingen voor beide SAML-aanvragen.

De volgende XML is een voorbeeld van een service voor eenmalige aanmelding van Microsoft Entra metagegevens met twee bindingen. De HTTP-Redirect heeft voorrang op de HTTP-POST omdat deze als eerste wordt weergegeven in de metagegevens van de SAML-id-provider.

<IDPSSODescriptor protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">
  ...
  <SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" Location="https://login.microsoftonline.com/00000000-0000-0000-0000-000000000000/saml2"/>
  <SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://login.microsoftonline.com/00000000-0000-0000-0000-000000000000/saml2"/>
</IDPSSODescriptor>

Assertion Consumer Service

Assertion Consumer Service (of ACS) is waar de SAML-antwoorden van de id-provider worden verzonden en ontvangen door Azure AD B2C. SAML-antwoorden worden verzonden naar Azure AD B2C via HTTP POST-binding. De ACS-locatie verwijst naar het basisbeleid van uw relying party. Als het relying-beleid bijvoorbeeld B2C_1A_signup_signin is, is acs het basisbeleid van de B2C_1A_signup_signin, zoals B2C_1A_TrustFrameworkBase.

De volgende XML is een voorbeeld van een Azure AD B2C-beleidsmetagegevens assertion consumer service-element.

<SPSSODescriptor AuthnRequestsSigned="true" protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">
  ...
  <AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://your-tenant.b2clogin.com/your-tenant/B2C_1A_TrustFrameworkBase/samlp/sso/assertionconsumer" index="0" isDefault="true"/>
</SPSSODescriptor>

De handtekening van de SAML-aanvraag configureren

Azure AD B2C ondertekent alle uitgaande verificatieaanvragen met behulp van de cryptografische sleutel SamlMessageSigning. Als u de handtekening van de SAML-aanvraag wilt uitschakelen, stelt u WantsSignedRequests in op false. Als de metagegevens zijn ingesteld op false, worden de parameters SigAlg en Signature (querytekenreeks of postparameter) weggelaten uit de aanvraag.

Deze metagegevens bepalen ook het kenmerk AuthnRequestsSigned, dat deel uitmaakt van de metagegevens van het technische profiel Azure AD B2C dat wordt gedeeld met de id-provider. Azure AD B2C de aanvraag niet ondertekent als de waarde van WantsSignedRequests in de metagegevens van het technische profiel is ingesteld op false en de metagegevens van de id-provider WantAuthnRequestsSigned is ingesteld op false of niet is opgegeven.

In het volgende voorbeeld wordt de handtekening uit de SAML-aanvraag verwijderd.

<Metadata>
  ...
  <Item Key="WantsSignedRequests">false</Item>
</Metadata>

Handtekening-algoritme

Azure AD B2C gebruikt Sha1 om de SAML-aanvraag te ondertekenen. Gebruik de metagegevens van XmlSignatureAlgorithm om het te gebruiken algoritme te configureren. Mogelijke waarden zijn Sha256, Sha384, Sha512of Sha1 (standaard). Deze metagegevens bepalen de waarde van de parameter SigAlg (queryreeks of postparameter) in de SAML-aanvraag. Zorg dat u het handtekeningalgoritmen aan beide zijden met dezelfde waarde configureert. Gebruik slechts het algoritme dat door uw certificaat wordt ondersteund.

Belangrijke informatie opnemen

Wanneer de id-provider aangeeft dat Azure AD B2C-binding is ingesteld op HTTP-POST, Azure AD B2C de handtekening en het algoritme in de hoofdtekst van de SAML-aanvraag opneemt. U kunt Microsoft Entra-id ook configureren om de openbare sleutel van het certificaat op te nemen wanneer de binding is ingesteld op HTTP-POST. Gebruik de metagegevens van IncludeKeyInfo voor true, of false. In het volgende voorbeeld bevat Microsoft Entra id niet de openbare sleutel van het certificaat.

<Metadata>
  ...
  <Item Key="IncludeKeyInfo">false</Item>
</Metadata>

Id van SAML-aanvraagnaam configureren

Het element SAML-autorisatieaanvraag <NameID> geeft de indeling van de SAML-naam-id aan. In deze sectie wordt de standaardconfiguratie beschreven en hoe u het naam-id-element aanpast.

Voorkeursgebruikersnaam

Tijdens een gebruikerstraject voor aanmelden kan een relying party-toepassing zich richten op een specifieke gebruiker. met Azure AD B2C kunt u een voorkeursgebruikersnaam verzenden naar de SAML-id-provider. Het element InputClaims wordt gebruikt om een NameId te verzenden binnen het onderwerp van de SAML-autorisatieaanvraag.

Als u de onderwerpnaam-id wilt opnemen in de autorisatieaanvraag, voegt u het volgende <InputClaims> element direct na de <CryptographicKeys>toe. Het PartnerClaimType moet worden ingesteld op subject.

<InputClaims>
  <InputClaim ClaimTypeReferenceId="signInName" PartnerClaimType="subject" />
</InputClaims>

In dit voorbeeld verzendt Azure AD B2C de waarde van de claim signInName met NameId binnen het onderwerp van de SAML-autorisatieaanvraag.

<samlp:AuthnRequest ... >
  ...
  <saml:Subject>
    <saml:NameID>sam@contoso.com</saml:NameID>
  </saml:Subject>
</samlp:AuthnRequest>

U kunt contextclaims gebruiken, zoals {OIDC:LoginHint} om de claimwaarde in te vullen.

<Metadata>
  ...
  <Item Key="IncludeClaimResolvingInClaimsHandling">true</Item>
</Metadata>
  ...
<InputClaims>
  <InputClaim ClaimTypeReferenceId="signInName" PartnerClaimType="subject" DefaultValue="{OIDC:LoginHint}" AlwaysUseDefaultValue="true" />
</InputClaims>

Indeling van naam-id-beleid

Standaard geeft de SAML-autorisatieaanvraag het urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified beleid op. Deze naam-id geeft aan dat elk type id dat wordt ondersteund door de id-provider voor het aangevraagde onderwerp kan worden gebruikt.

Als u dit gedrag wilt wijzigen, raadpleegt u de documentatie van uw id-provider voor richtlijnen over welk naam-id-beleid wordt ondersteund. Voeg vervolgens de NameIdPolicyFormat metagegevens toe in de bijbehorende beleidsindeling. Bijvoorbeeld:

<Metadata>
  ...
  <Item Key="NameIdPolicyFormat">urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress</Item>
</Metadata>

De volgende SAML-autorisatieaanvraag bevat het naam-id-beleid.

<samlp:AuthnRequest ... >
  ...
  <samlp:NameIDPolicy Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress" />
</samlp:AuthnRequest>

Het maken van nieuwe accounts toestaan

Als u de beleidsindeling Naam-id opgeeft, kunt u ook de AllowCreate eigenschap van NameIDPolicy opgeven om aan te geven of de id-provider een nieuw account mag maken tijdens de aanmeldingsstroom. Raadpleeg de documentatie van uw id-provider voor ondersteuning.

Azure AD B2C laat de AllowCreate eigenschap standaard weg. U kunt dit gedrag wijzigen met behulp van de NameIdPolicyAllowCreate metagegevens. De waarde van deze metagegevens is true of false.

In het volgende voorbeeld ziet u hoe u de eigenschap van NameIDPolicy instelt AllowCreate op true.

<Metadata>
  ...
  <Item Key="NameIdPolicyFormat">urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress</Item>
  <Item Key="NameIdPolicyAllowCreate">true</Item>
</Metadata>

In het volgende voorbeeld ziet u een autorisatieaanvraag met AllowCreate van het element NameIDPolicy in de autorisatieaanvraag.

<samlp:AuthnRequest ... >
  ...
  <samlp:NameIDPolicy 
      Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress" 
      AllowCreate="true" />
</samlp:AuthnRequest>

Verificatie afdwingen

U kunt afdwingen dat de externe SAML-IDP de gebruiker om verificatie vraagt door de ForceAuthN eigenschap door te geven in de SAML-verificatieaanvraag. Uw id-provider moet deze eigenschap ook ondersteunen.

De ForceAuthN eigenschap is een Booleaanse true waarde of false waarde. Standaard stelt Azure AD B2C de waarde ForceAuthN in op false. Als de sessie vervolgens opnieuw wordt ingesteld (bijvoorbeeld met behulp van de prompt=login in OIDC), wordt de ForceAuthN waarde ingesteld op true. Als u de ForceAuthN metagegevens instelt op, true wordt de waarde voor alle aanvragen naar de externe IDP gelegerd.

In het volgende voorbeeld ziet u de ForceAuthN eigenschap die is ingesteld op true:

<Metadata>
  ...
  <Item Key="ForceAuthN">true</Item>
  ...
</Metadata>

In het volgende voorbeeld ziet u de ForceAuthN eigenschap in een autorisatieaanvraag:

<samlp:AuthnRequest AssertionConsumerServiceURL="https://..."  ...
                    ForceAuthN="true">
  ...
</samlp:AuthnRequest>

Providernaam

U kunt het ProviderName kenmerk desgewenst opnemen in de SAML-autorisatieaanvraag. Stel de ProviderName metagegevens in om de providernaam op te nemen voor alle aanvragen voor de externe SAML IDP. In het volgende voorbeeld ziet u de ProviderName eigenschap die is ingesteld op Contoso app:

<Metadata>
  ...
  <Item Key="ProviderName">Contoso app</Item>
  ...
</Metadata>

In het volgende voorbeeld ziet u de ProviderName eigenschap in een autorisatieaanvraag:

<samlp:AuthnRequest AssertionConsumerServiceURL="https://..."  ...
                    ProviderName="Contoso app">
  ...
</samlp:AuthnRequest>

Verwijzingen naar verificatiecontextklasse opnemen

Een SAML-autorisatieaanvraag kan een AuthnContext-element bevatten, waarmee de context van een autorisatieaanvraag wordt opgegeven. Het -element kan een verwijzing naar de verificatiecontextklasse bevatten, die de SAML-id-provider vertelt welk verificatiemechanisme aan de gebruiker moet worden weergegeven.

Als u de verwijzingen naar de verificatiecontextklasse wilt configureren, voegt u metagegevens van IncludeAuthnContextClassReferences toe. Geef in de waarde een of meer URI-verwijzingen op die verificatiecontextklassen identificeren. Geef de meerdere URI's op als een door komma's gescheiden lijst. Raadpleeg de documentatie van uw id-provider voor hulp bij de ondersteunde AuthnContextClassRef-URI's .

In het volgende voorbeeld kunnen gebruikers zich aanmelden met zowel gebruikersnaam als wachtwoord, en zich aanmelden met gebruikersnaam en wachtwoord via een beveiligde sessie (SSL/TLS).

<Metadata>
  ...
  <Item Key="IncludeAuthnContextClassReferences">urn:oasis:names:tc:SAML:2.0:ac:classes:Password,urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport</Item>
</Metadata>

De volgende SAML-autorisatieaanvraag bevat de verwijzingen naar de verificatiecontextklasse.

<samlp:AuthnRequest ... >
  ...
  <samlp:RequestedAuthnContext>
    <saml:AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:Password</saml:AuthnContextClassRef>
    <saml:AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport</saml:AuthnContextClassRef>
  </samlp:RequestedAuthnContext>
</samlp:AuthnRequest>

Aangepaste gegevens opnemen in de autorisatieaanvraag

U kunt desgewenst protocolberichtuitbreidingselementen opnemen die zijn overeengekomen door zowel Azure AD B2C als uw id-provider. De extensie wordt weergegeven in een XML-indeling. U neemt extensie-elementen op door XML-gegevens toe te voegen in het CDATA-element <![CDATA[Your Custom XML]]>. Controleer documentatie van uw id-provider om te zien of het uitbreidingselement wordt ondersteund.

In het volgende voorbeeld ziet u het gebruik van extensiegegevens:

<Metadata>
  ...
  <Item Key="AuthenticationRequestExtensions"><![CDATA[
            <ext:MyCustom xmlns:ext="urn:ext:custom">
              <ext:AssuranceLevel>1</ext:AssuranceLevel>
              <ext:AssuranceDescription>Identity verified to level 1.</ext:AssuranceDescription>
            </ext:MyCustom>]]></Item>
</Metadata>

Notitie

Volgens de SAML-specificatie moeten de extensiegegevens naamruimte-gekwalificeerde XML zijn (bijvoorbeeld urn:ext:custom weergegeven in het voorbeeld) en mogen ze niet een van de SAML-specifieke naamruimten zijn.

Met de berichtextensie van het SAML-protocol ziet het SAML-antwoord eruit als in het volgende voorbeeld:

<samlp:AuthnRequest ... >
  ...
  <samlp:Extensions>
    <ext:MyCustom xmlns:ext="urn:ext:custom">
      <ext:AssuranceLevel>1</ext:AssuranceLevel>
      <ext:AssuranceDescription>Identity verified to level 1.</ext:AssuranceDescription>
    </ext:MyCustom>
  </samlp:Extensions>
</samlp:AuthnRequest>

Ondertekende SAML-antwoorden vereisen

Azure AD B2C moeten alle binnenkomende asserties worden ondertekend. U kunt deze vereiste verwijderen door WantsSignedAssertions in te stellen op false. De id-provider mag de asserties in dit geval niet ondertekenen, maar zelfs als dit het geval is, valideert Azure AD B2C de handtekening niet.

De metagegevens van WantsSignedAssertions bepalen de SAML-metagegevensvlag WantAssertionsSigned, die is opgenomen in de metagegevens van het technische profiel Azure AD B2C dat wordt gedeeld met de id-provider.

<SPSSODescriptor AuthnRequestsSigned="true" WantAssertionsSigned="true" protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">

Als u de validatie van asserties uitschakelt, wilt u mogelijk ook de validatie van de handtekening van het antwoordbericht uitschakelen. Stel de responsesSigned-metagegevens in op false. De id-provider mag het SAML-antwoordbericht in dit geval niet ondertekenen, maar zelfs als dit het geval is, Azure AD B2C de handtekening niet valideert.

In het volgende voorbeeld worden zowel het bericht als de assertiehandtekening verwijderd:

<Metadata>
  ...
  <Item Key="WantsSignedAssertions">false</Item>
  <Item Key="ResponsesSigned">false</Item>
</Metadata>

Versleutelde SAML-antwoorden vereisen

Als u wilt vereisen dat alle binnenkomende asserties worden versleuteld, stelt u de metagegevens van WantsEncryptedAssertions in. Wanneer versleuteling is vereist, gebruikt de id-provider een openbare sleutel van een versleutelingscertificaat in een Azure AD technisch B2C-profiel. Azure AD B2C ontsleutelt de antwoordbevestiging met behulp van het privégedeelte van het versleutelingscertificaat.

Als u de versleuteling van asserties inschakelt, moet u mogelijk ook de validatie van de antwoordhandtekening uitschakelen (zie Ondertekende SAML-antwoorden vereisen voor meer informatie.

Wanneer de metagegevens van WantsEncryptedAssertions zijn ingesteld op true, bevatten de metagegevens van het technische profiel Azure AD B2C de sectie versleuteling. De id-provider leest deze metagegevens en versleutelt de SAML-antwoordverklaring met de openbare sleutel die is opgegeven in de metagegevens van het Azure AD B2C-technisch profiel.

In dit volgende voorbeeld ziet u de sectie Sleuteldescriptor van de SAML-metagegevens die worden gebruikt voor versleuteling:

<SPSSODescriptor AuthnRequestsSigned="true"  protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">
  <KeyDescriptor use="encryption">
    <KeyInfo xmlns="https://www.w3.org/2000/09/xmldsig#">
      <X509Data>
        <X509Certificate>valid certificate</X509Certificate>
      </X509Data>
    </KeyInfo>
  </KeyDescriptor>
  ...
</SPSSODescriptor>

Om de SAML-antwoordverklaring te versleutelen:

  1. Maak een beleidssleutel met een unieke id. Bijvoorbeeld B2C_1A_SAMLEncryptionCert.

  2. In uw verzameling Cryptografische sleutels in uw technische SAML-profiel. Stel StorageReferenceId in op de naam van de beleidssleutel die u in de eerste stap hebt gemaakt. De SamlAssertionDecryption id geeft het gebruik van de cryptografische sleutel aan voor het versleutelen en ontsleutelen van de assertie van het SAML-antwoord.

    <CryptographicKeys>
        ...
  <Key Id="SamlAssertionDecryption" StorageReferenceId="B2C_1A_SAMLEncryptionCert"/>
</CryptographicKeys>

  3. Stel metagegevens van het technische profiel WantsEncryptedAssertions in op true.

    <Metadata>
  ...
  <Item Key="WantsEncryptedAssertions">true</Item>
</Metadata>

  4. Werk uw id-provider bij met de nieuwe Azure AD metagegevens van het technische B2C-profiel. U ziet de KeyDescriptor met de eigenschap Use ingesteld op encryption die de openbare sleutel van uw certificaat bevat.

Gebruik van contextclaims inschakelen

In de verzameling invoer- en uitvoerclaims kunt u claims opnemen die niet worden geretourneerd door de id-provider, zolang u het DefaultValue kenmerk instelt. U kunt ook contextclaims gebruiken om in het technische profiel te worden opgenomen. Een contextclaim gebruiken:

  1. Voeg een claimtype toe aan het element ClaimsSchema in BuildingBlocks.

  2. Voeg een uitvoerclaim toe aan de invoer- of uitvoerverzameling. In het volgende voorbeeld stelt de eerste claim de waarde van de id-provider in. De tweede claim maakt gebruik van de ip-adrescontextclaims van de gebruiker.

    <OutputClaims>
  <OutputClaim ClaimTypeReferenceId="identityProvider" DefaultValue="contoso.com" AlwaysUseDefaultValue="true" />
  <OutputClaim ClaimTypeReferenceId="IpAddress" DefaultValue="{Context:IPAddress}" AlwaysUseDefaultValue="true" />
</OutputClaims>

Eenmalige afmelding uitschakelen

Bij een afmeldingsaanvraag van de toepassing probeert Azure AD B2C zich af te melden bij uw SAML-id-provider. Zie afmelden van B2C-sessie Azure AD voor meer informatie. Als u het gedrag voor eenmalige afmelding wilt uitschakelen, stelt u de metagegevens van SingleLogoutEnabled in op false.

<Metadata>
  ...
  <Item Key="SingleLogoutEnabled">false</Item>
</Metadata>

Fouten opsporen in SAML-protocol

Als u federatie met een SAML-id-provider wilt configureren en fouten wilt opsporen, kunt u een browserextensie voor het SAML-protocol gebruiken, zoals de EXTENSIE SAML DevTools voor Chrome, SAML-tracer voor FireFox of Microsoft Edge of IE Ontwikkelhulpprogramma's.

Met deze hulpprogramma's kunt u de integratie tussen Azure AD B2C en uw SAML-id-provider controleren. Bijvoorbeeld:

  • Controleer of de SAML-aanvraag een handtekening bevat en bepaal welk algoritme wordt gebruikt om de autorisatieaanvraag aan te melden.
  • Haal de claims (asserties) op in de AttributeStatement sectie .
  • Controleer of de id-provider een foutbericht retourneert.
  • Controleer of de assertiesectie is versleuteld.

Voorbeelden van SAML-aanvragen en -antwoorden

Security Assertion Markup Language (SAML) is een open standaard voor het uitwisselen van verificatie- en autorisatiegegevens tussen een id-provider en een serviceprovider. Wanneer Azure AD B2C in een federatief verband met een SAML-id-provider wordt gebruikt, fungeert deze als een serviceprovider die een SAML-aanvraag start bij de SAML-id-provider en wacht op een SAML-antwoord.

Een geslaagd SAML-antwoord bevat beveiligingsverklaringen die instructies zijn die zijn gemaakt door de externe SAML-id-providers. Azure AD B2C parseert en wijst de asserties toe in claims.

Autorisatieaanvraag

Als u een gebruikersverificatie wilt aanvragen, verzendt Azure AD B2C een AuthnRequest element naar de externe SAML-id-provider. Een voorbeeld van een SAML 2.0-AuthnRequest kan eruitzien als in het volgende voorbeeld:

<samlp:AuthnRequest 
    xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" 
    ID="_11111111-0000-0000-0000-000000000000" 
    Version="2.0" 
    IssueInstant="2023-03-20T07:10:00.0000000Z" 
    Destination="https://fabrikam.com/saml2" 
    ForceAuthn="false" 
    IsPassive="false" 
    ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" 
    AssertionConsumerServiceURL="https://contoso.b2clogin.com/contoso.onmicrosoft.com/B2C_1A_TrustFrameworkBase/samlp/sso/assertionconsumer" 
    ProviderName="https://fabrikam.com" 
    xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol">
    <saml:Issuer 
        Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity">https://contoso.b2clogin.com/contoso.onmicrosoft.com/B2C_1A_TrustFrameworkBase
    </saml:Issuer>
</samlp:AuthnRequest>

Antwoord

Wanneer een aangevraagde aanmelding is voltooid, plaatst de externe SAML-id-provider een antwoord op Azure AD B2C assertion consumer service-eindpunt. Een antwoord op een geslaagde aanmeldingspoging ziet eruit als in het volgende voorbeeld:

<samlp:Response 
    ID="_98765432-0000-0000-0000-000000000000" 
    Version="2.0" 
    IssueInstant="2023-03-20T07:11:30.0000000Z" 
    Destination="https://contoso.b2clogin.com/contoso.onmicrosoft.com/B2C_1A_TrustFrameworkBase/samlp/sso/assertionconsumer" 
    InResponseTo="_11111111-0000-0000-0000-000000000000" 
    xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol">
    <Issuer 
        xmlns="urn:oasis:names:tc:SAML:2.0:assertion">https://fabrikam.com/
    </Issuer>
    <samlp:Status>
        <samlp:StatusCode 
            Value="urn:oasis:names:tc:SAML:2.0:status:Success"/>
    </samlp:Status>
    <Assertion 
        ID="_55555555-0000-0000-0000-000000000000" 
        IssueInstant="2023-03-20T07:40:45.505Z" 
        Version="2.0" 
        xmlns="urn:oasis:names:tc:SAML:2.0:assertion">
        <Issuer>https://fabrikam.com/</Issuer>
        <Signature 
            xmlns="http://www.w3.org/2000/09/xmldsig#">
            ...
        </Signature>
        <Subject>
            <NameID 
                Format="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent">ABCDEFG
            </NameID>
            ...
        </Subject>
        <AttributeStatement>
            <Attribute Name="uid">
                <AttributeValue>12345</AttributeValue>
            </Attribute>
            <Attribute Name="displayname">
                <AttributeValue>David</AttributeValue>
            </Attribute>
            <Attribute Name="email">
                <AttributeValue>david@contoso.com</AttributeValue>
            </Attribute>
            ....
        </AttributeStatement>
        <AuthnStatement 
            AuthnInstant="2023-03-20T07:40:45.505Z" 
            SessionIndex="_55555555-0000-0000-0000-000000000000">
            <AuthnContext>
                <AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:Password</AuthnContextClassRef>
            </AuthnContext>
        </AuthnStatement>
    </Assertion>
</samlp:Response>

Afmeldingsaanvraag

Bij een afmeldingsaanvraag van de toepassing probeert Azure AD B2C zich af te melden bij uw SAML-id-provider. Azure AD B2C stuurt een LogoutRequest bericht naar de externe IDP om aan te geven dat een sessie is beëindigd. In het volgende fragment ziet u een voorbeeldelement van LogoutRequest.

De waarde van het NameID element komt overeen met de NameID van de gebruiker die wordt afgemeld. Het SessionIndex -element komt overeen met het SessionIndex kenmerk van AuthnStatement in het SAML-antwoord voor aanmelding.

<samlp:LogoutRequest 
    xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" 
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
    ID="_22222222-0000-0000-0000-000000000000" 
    Version="2.0" 
    IssueInstant="2023-03-20T08:21:07.3679354Z" 
    Destination="https://fabrikam.com/saml2/logout" 
    xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol">
    <saml:Issuer 
        Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity">https://contoso.b2clogin.com/contoso.onmicrosoft.com/B2C_1A_TrustFrameworkBase
    </saml:Issuer>
    <saml:NameID>ABCDEFG</saml:NameID>
    <samlp:SessionIndex>_55555555-0000-0000-0000-000000000000</samlp:SessionIndex>
</samlp:LogoutRequest>

Volgende stappen

  • Meer informatie over het diagnosticeren van problemen met uw aangepaste beleid met behulp van Application Insights.