Alternativ för att registrera ett SAML-program i Azure AD B2C

Den här artikeln beskriver de konfigurationsalternativ som är tillgängliga när du ansluter Azure Active Directory B2C (Azure AD B2C) med ditt SAML-program (Security Assertion Markup Language).

Innan du börjar använder du väljaren Välj en principtyp för att välja den typ av princip som du konfigurerar. Azure Active Directory B2C erbjuder två metoder för att definiera hur användare interagerar med dina program: via fördefinierade användarflöden eller genom fullständigt konfigurerbara anpassade principer. De steg som krävs i den här artikeln skiljer sig åt för varje metod.

Den här funktionen är endast tillgänglig för anpassade principer. För installationssteg väljer du Anpassad princip i föregående väljare.

Ange en SAML-svarssignatur

Du kan ange ett certifikat som ska användas för att signera SAML-meddelanden. Meddelandet är elementet <samlp:Response> i SAML-svaret som skickas till programmet.

Om du inte redan har en principnyckel skapar du en. Konfigurera SamlMessageSigning sedan metadataobjektet i den tekniska profilen för SAML Token Issuer. StorageReferenceId måste referera till principnyckelnamnet.

<ClaimsProvider>
  <DisplayName>Token Issuer</DisplayName>
  <TechnicalProfiles>
    <!-- SAML Token Issuer technical profile -->
    <TechnicalProfile Id="Saml2AssertionIssuer">
      <DisplayName>Token Issuer</DisplayName>
      <Protocol Name="SAML2"/>
      <OutputTokenFormat>SAML2</OutputTokenFormat>
        ...
      <CryptographicKeys>
        <Key Id="SamlMessageSigning" StorageReferenceId="B2C_1A_SamlMessageCert"/>
        ...
      </CryptographicKeys>
    ...
    </TechnicalProfile>

Signaturalgoritm

Du kan konfigurera signaturalgoritmen som används för att signera SAML-försäkran. Möjliga värden är Sha256, Sha384, Sha512eller Sha1. Kontrollera att den tekniska profilen och programmet använder samma signaturalgoritm. Använd endast den algoritm som certifikatet stöder.

Konfigurera signaturalgoritmen med hjälp av metadatanyckeln XmlSignatureAlgorithm i det förlitande partelementet Metadata .

<RelyingParty>
  <DefaultUserJourney ReferenceId="SignUpOrSignIn" />
  <TechnicalProfile Id="PolicyProfile">
    <DisplayName>PolicyProfile</DisplayName>
    <Protocol Name="SAML2"/>
    <Metadata>
      <Item Key="XmlSignatureAlgorithm">Sha256</Item>
    </Metadata>
   ..
  </TechnicalProfile>
</RelyingParty>

Kontrollera SAML-försäkransignaturen

När programmet förväntar sig att SAML-kontrollavsnittet ska signeras kontrollerar du att SAML-tjänstleverantören har angett WantAssertionsSigned till true. Om den är inställd på false eller inte finns, signeras inte kontrollavsnittet.

I följande exempel visas metadata för en SAML-tjänstprovider med WantAssertionsSigned värdet true.

<EntityDescriptor ID="id123456789" entityID="https://samltestapp2.azurewebsites.net" validUntil="2099-12-31T23:59:59Z" xmlns="urn:oasis:names:tc:SAML:2.0:metadata">
  <SPSSODescriptor WantAssertionsSigned="true" AuthnRequestsSigned="false" protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">
  ...
  </SPSSODescriptor>
</EntityDescriptor>

Signaturcertifikat

Principen måste ange ett certifikat som ska användas för att signera avsnittet SAML-försäkran i SAML-svaret. Om du inte redan har en principnyckel skapar du en. Konfigurera SamlAssertionSigning sedan metadataobjektet i den tekniska profilen för SAML Token Issuer. StorageReferenceId måste referera till principnyckelnamnet.

<ClaimsProvider>
  <DisplayName>Token Issuer</DisplayName>
  <TechnicalProfiles>
    <!-- SAML Token Issuer technical profile -->
    <TechnicalProfile Id="Saml2AssertionIssuer">
      <DisplayName>Token Issuer</DisplayName>
      <Protocol Name="SAML2"/>
      <OutputTokenFormat>SAML2</OutputTokenFormat>
        ...
      <CryptographicKeys>
        <Key Id="SamlAssertionSigning" StorageReferenceId="B2C_1A_SamlMessageCert"/>
        ...
      </CryptographicKeys>
    ...
    </TechnicalProfile>

Aktivera kryptering i SAML-försäkran

När ditt program förväntar sig att SAML-försäkran ska vara i ett krypterat format kontrollerar du att kryptering är aktiverat i Azure AD B2C-principen.

Azure AD B2C använder tjänstleverantörens offentliga nyckelcertifikat för att kryptera SAML-försäkran. Den offentliga nyckeln måste finnas i SAML-programmets metadataslutpunkt med KeyDescriptoruse värdet inställt på Encryption, enligt följande exempel:

<KeyDescriptor use="encryption">
  <KeyInfo xmlns="https://www.w3.org/2000/09/xmldsig#">
    <X509Data>
      <X509Certificate>valid certificate</X509Certificate>
    </X509Data>
  </KeyInfo>
</KeyDescriptor>

Om du vill göra det möjligt för Azure AD B2C att skicka krypterade intyg anger du WantsEncryptedAssertion metadataobjektet till true i den förlitande partens tekniska profil. Du kan också konfigurera algoritmen som används för att kryptera SAML-försäkran.

<RelyingParty>
  <DefaultUserJourney ReferenceId="SignUpOrSignIn" />
  <TechnicalProfile Id="PolicyProfile">
    <DisplayName>PolicyProfile</DisplayName>
    <Protocol Name="SAML2"/>
    <Metadata>
      <Item Key="WantsEncryptedAssertions">true</Item>
    </Metadata>
   ..
  </TechnicalProfile>
</RelyingParty>

Krypteringsmetod

Om du vill konfigurera krypteringsmetoden som används för att kryptera SAML-kontrolldata anger du metadatanyckeln DataEncryptionMethod inom den förlitande parten. Möjliga värden är Aes256 (standard), Aes192, Sha512, eller Aes128. Metadata styr värdet för elementet <EncryptedData> i SAML-svaret.

Om du vill konfigurera krypteringsmetoden för att kryptera kopian av nyckeln som användes för att kryptera SAML-kontrolldata anger du KeyEncryptionMethod metadatanyckeln inom den förlitande parten. Möjliga värden är:

  • Rsa15 (standard): algoritmen RSA Public Key Cryptography Standard (PKCS) version 1.5.
  • RsaOaep: RSA Optimal Asymmetrisk krypteringsutfyllnadsalgoritm (OAEP).

Metadata styr värdet för elementet <EncryptedKey> i SAML-svaret.

I följande exempel visas avsnittet i EncryptedAssertion en SAML-försäkran. Den krypterade datametoden är Aes128, och den krypterade nyckelmetoden är Rsa15.

<saml:EncryptedAssertion>
  <xenc:EncryptedData xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"
    xmlns:dsig="http://www.w3.org/2000/09/xmldsig#" Type="http://www.w3.org/2001/04/xmlenc#Element">
    <xenc:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#aes128-cbc" />
    <dsig:KeyInfo>
      <xenc:EncryptedKey>
        <xenc:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-1_5" />
        <xenc:CipherData>
          <xenc:CipherValue>...</xenc:CipherValue>
        </xenc:CipherData>
      </xenc:EncryptedKey>
    </dsig:KeyInfo>
    <xenc:CipherData>
      <xenc:CipherValue>...</xenc:CipherValue>
    </xenc:CipherData>
  </xenc:EncryptedData>
</saml:EncryptedAssertion>

Du kan ändra formatet för de krypterade försäkran. Konfigurera krypteringsformatet genom att ange metadatanyckeln UseDetachedKeys inom den förlitande parten. Möjliga värden: true eller false (standard). När värdet är inställt på truelägger de frånkopplade nycklarna till den krypterade försäkran som underordnad EncryptedAssertion i stället för EncryptedData.

Konfigurera krypteringsmetoden och formatet med hjälp av metadatanycklarna i den förlitande partens tekniska profil:

<RelyingParty>
  <DefaultUserJourney ReferenceId="SignUpOrSignIn" />
  <TechnicalProfile Id="PolicyProfile">
    <DisplayName>PolicyProfile</DisplayName>
    <Protocol Name="SAML2"/>
    <Metadata>
      <Item Key="DataEncryptionMethod">Aes128</Item>
      <Item Key="KeyEncryptionMethod">Rsa15</Item>
      <Item Key="UseDetachedKeys">false</Item>
    </Metadata>
   ..
  </TechnicalProfile>
</RelyingParty>

Konfigurera IdP-initierat flöde

När ditt program förväntar sig att få en SAML-försäkran utan att först skicka en SAML AuthN-begäran till identitetsprovidern (IdP) måste du konfigurera Azure AD B2C för IdP-initierat flöde.

I IdP-initierat flöde startar identitetsprovidern (Azure AD B2C) inloggningsprocessen. Identitetsprovidern skickar ett oönskat SAML-svar till tjänstleverantören (ditt förlitande partprogram).

Vi stöder för närvarande inte scenarier där den initierande identitetsprovidern är en extern identitetsprovider federerad med Azure AD B2C, till exempel Active Directory Federation Services (AD FS) eller Salesforce. IdP-initierat flöde stöds endast för lokal kontoautentisering i Azure AD B2C.

Om du vill aktivera IdP-initierat flöde anger du IdpInitiatedProfileEnabled metadataobjektet till true i den förlitande partens tekniska profil.

<RelyingParty>
  <DefaultUserJourney ReferenceId="SignUpOrSignIn" />
  <TechnicalProfile Id="PolicyProfile">
    <DisplayName>PolicyProfile</DisplayName>
    <Protocol Name="SAML2"/>
    <Metadata>
      <Item Key="IdpInitiatedProfileEnabled">true</Item>
    </Metadata>
   ..
  </TechnicalProfile>
</RelyingParty>

Om du vill logga in eller registrera en användare via IdP-initierat flöde använder du följande URL:

https://<tenant-name>.b2clogin.com/<tenant-name>.onmicrosoft.com/<policy-name>/generic/login?EntityId=<app-identifier-uri>&RelayState=<relay-state> 

Ersätt följande värden:

  • Ersätt <tenant-name> med ditt klientnamn.
  • Ersätt <policy-name> med namnet på din SAML-förlitande partprincip.
  • Ersätt <app-identifier-uri> med identifierUris värdet i metadatafilen, till exempel https://contoso.onmicrosoft.com/app-name.
  • [Valfritt] ersätt <relay-state> med ett värde som ingår i auktoriseringsbegäran som också returneras i tokensvaret. Parametern relay-state används för att koda information om användarens tillstånd i appen innan autentiseringsbegäran inträffade, till exempel sidan de var på.

Exempel-princip

Du kan använda en fullständig exempelprincip för testning med SAML-testappen:

  1. Ladda ned den SAML-SP-initierade inloggningsexempelprincipen.
  2. Uppdatera TenantId för att matcha klientorganisationens namn. Den här artikeln använder exemplet contoso.b2clogin.com.
  3. Behåll principnamnet B2C_1A_signup_signin_saml.

Konfigurera livslängden för SAML-svar

Du kan konfigurera hur lång tid SAML-svaret förblir giltigt. Ange livslängden TokenLifeTimeInSeconds med hjälp av metadataobjektet i den tekniska profilen för SAML Token Issuer. Det här värdet är det antal sekunder som kan förflutit från NotBefore tidsstämpeln, beräknat vid tokenutfärdingstiden. Standardlivslängden är 300 sekunder (fem minuter).

<ClaimsProvider>
  <DisplayName>Token Issuer</DisplayName>
  <TechnicalProfiles>
    <TechnicalProfile Id="Saml2AssertionIssuer">
      <DisplayName>Token Issuer</DisplayName>
      <Protocol Name="SAML2"/>
      <OutputTokenFormat>SAML2</OutputTokenFormat>
      <Metadata>
        <Item Key="TokenLifeTimeInSeconds">400</Item>
      </Metadata>
      ...
    </TechnicalProfile>

Konfigurera tidsförskjutning för ett SAML-svar

Du kan konfigurera tidsförskjutning som tillämpas på SAML-svarstidsstämpeln NotBefore . Den här konfigurationen säkerställer att om tiderna mellan två plattformar inte är synkroniserade anses SAML-försäkran fortfarande vara giltig när den är inom den här tiden skev.

Ange tidsförskjutning med hjälp TokenNotBeforeSkewInSeconds av metadataobjektet i den tekniska profilen för SAML Token Issuer. Snedställningsvärdet anges i sekunder med standardvärdet 0. Det maximala värdet är 3600 (en timme).

Till exempel när TokenNotBeforeSkewInSeconds är inställt på 120 sekunder:

  • Token utfärdas kl. 13:05:10 UTC.
  • Token är giltig från 13:03:10 UTC.
<ClaimsProvider>
  <DisplayName>Token Issuer</DisplayName>
  <TechnicalProfiles>
    <TechnicalProfile Id="Saml2AssertionIssuer">
      <DisplayName>Token Issuer</DisplayName>
      <Protocol Name="SAML2"/>
      <OutputTokenFormat>SAML2</OutputTokenFormat>
      <Metadata>
        <Item Key="TokenNotBeforeSkewInSeconds">120</Item>
      </Metadata>
      ...
    </TechnicalProfile>

Ta bort millisekunder från datum och tid

Du kan ange om millisekunder ska tas bort från datum- och tidsvärden i SAML-svaret. (Dessa värden inkluderar IssueInstant, NotBefore, NotOnOrAfteroch AuthnInstant.) Om du vill ta bort millisekunderna anger du metadatanyckeln RemoveMillisecondsFromDateTime inom den förlitande parten. Möjliga värden: false (standard) eller true.

  <RelyingParty>
    <DefaultUserJourney ReferenceId="SignUpOrSignIn" />
    <TechnicalProfile Id="PolicyProfile">
      <DisplayName>PolicyProfile</DisplayName>
      <Protocol Name="SAML2" />
      <Metadata>
        <Item Key="RemoveMillisecondsFromDateTime">true</Item>
      </Metadata>
      <OutputClaims>
             ...
      </OutputClaims>
      <SubjectNamingInfo ClaimType="objectId" ExcludeAsClaim="true" />
    </TechnicalProfile>
  </RelyingParty>

Använda ett utfärdar-ID för att åsidosätta en utfärdar-URI

Om du har flera SAML-program som är beroende av olika entityID värden kan du åsidosätta IssuerUri värdet i den förlitande partfilen. Om du vill åsidosätta utfärdarens URI kopierar du den tekniska profilen med Saml2AssertionIssuer ID:t från basfilen och åsidosätter IssuerUri värdet.

Dricks

<ClaimsProviders> Kopiera avsnittet från basen och bevara dessa element i anspråksprovidern: <DisplayName>Token Issuer</DisplayName>, <TechnicalProfile Id="Saml2AssertionIssuer">och <DisplayName>Token Issuer</DisplayName>.

Exempel:

   <ClaimsProviders>   
    <ClaimsProvider>
      <DisplayName>Token Issuer</DisplayName>
      <TechnicalProfiles>
        <TechnicalProfile Id="Saml2AssertionIssuer">
          <DisplayName>Token Issuer</DisplayName>
          <Metadata>
            <Item Key="IssuerUri">customURI</Item>
          </Metadata>
        </TechnicalProfile>
      </TechnicalProfiles>
    </ClaimsProvider>
  </ClaimsProviders>
  <RelyingParty>
    <DefaultUserJourney ReferenceId="SignUpInSAML" />
    <TechnicalProfile Id="PolicyProfile">
      <DisplayName>PolicyProfile</DisplayName>
      <Protocol Name="SAML2" />
      <Metadata>
     …

Hantera en session

Du kan hantera sessionen mellan Azure AD B2C och det SAML-förlitande partprogrammet med hjälp av elementet UseTechnicalProfileForSessionManagement och SamlSSOSessionProvider.

Tvinga användare att autentisera igen

Om du vill tvinga användare att autentisera igen kan programmet inkludera ForceAuthn attributet i SAML-autentiseringsbegäran. Attributet ForceAuthn är ett booleskt värde. När den är inställd truepå kommer användarens session att ogiltigförklaras i Azure AD B2C och användaren tvingas autentisera igen.

Följande SAML-autentiseringsbegäran visar hur du anger ForceAuthn attributet till true.

<samlp:AuthnRequest 
       Destination="https://contoso.b2clogin.com/contoso.onmicrosoft.com/B2C_1A_SAML2_signup_signin/samlp/sso/login"
       ForceAuthn="true" ...>
    ...
</samlp:AuthnRequest>

Signera Azure AD B2C IdP SAML-metadata

Du kan instruera Azure AD B2C att signera dess metadatadokument för SAML-identitetsprovidern om programmet kräver det. Om du inte redan har en principnyckel skapar du en. Konfigurera MetadataSigning sedan metadataobjektet i den tekniska profilen för SAML Token Issuer. StorageReferenceId måste referera till principnyckelnamnet.

<ClaimsProvider>
  <DisplayName>Token Issuer</DisplayName>
  <TechnicalProfiles>
    <!-- SAML Token Issuer technical profile -->
    <TechnicalProfile Id="Saml2AssertionIssuer">
      <DisplayName>Token Issuer</DisplayName>
      <Protocol Name="SAML2"/>
      <OutputTokenFormat>SAML2</OutputTokenFormat>
        ...
      <CryptographicKeys>
        <Key Id="MetadataSigning" StorageReferenceId="B2C_1A_SamlMetadataCert"/>
        ...
      </CryptographicKeys>
    ...
    </TechnicalProfile>

Felsöka SAML-protokollet

För att konfigurera och felsöka integreringen med tjänstleverantören kan du använda ett webbläsartillägg för SAML-protokollet. Webbläsartillägg inkluderar SAML DevTools-tillägget för Chrome, SAML-tracer för Firefox och Utvecklarverktyg för Edge eller Internet Explorer.

Genom att använda dessa verktyg kan du kontrollera integreringen mellan ditt program och Azure AD B2C. Till exempel:

  • Kontrollera om SAML-begäran innehåller en signatur och avgör vilken algoritm som används för att logga in auktoriseringsbegäran.
  • Kontrollera om Azure AD B2C returnerar ett felmeddelande.
  • Kontrollera om kontrollavsnittet är krypterat.

Nästa steg