Opcje rejestrowania aplikacji SAML w usłudze Azure AD B2C

2025-05-02

Ważne

Od 1 maja 2025 r. usługa Azure AD B2C nie będzie już dostępna do zakupu dla nowych klientów. Dowiedz się więcej w naszych często zadawanych pytaniach.

W tym artykule opisano opcje konfiguracji, które są dostępne podczas łączenia usługi Azure Active Directory B2C (Azure AD B2C) z aplikacją Security Assertion Markup Language (SAML).

Przed rozpoczęciem użyj selektora Wybierz typ zasad w górnej części tej strony, aby wybrać typ konfigurowanych zasad. Usługa Azure Active Directory B2C oferuje dwie metody definiowania sposobu interakcji użytkowników z aplikacjami: za pomocą wstępnie zdefiniowanych przepływów użytkowników lub w pełni konfigurowalnych zasad niestandardowych. Kroki wymagane w tym artykule są różne dla każdej metody.

Ta funkcja jest dostępna tylko dla zasad niestandardowych. Aby uzyskać instrukcje konfiguracji, wybierz pozycję Zasady niestandardowe w poprzednim selektorze.

Określanie podpisu odpowiedzi SAML

Możesz określić certyfikat, który ma być używany do podpisywania komunikatów SAML. Komunikat jest elementem <samlp:Response> w odpowiedzi SAML wysyłanej do aplikacji.

Jeśli nie masz jeszcze klucza zasad, utwórz go. Następnie skonfiguruj SamlMessageSigning element metadanych w profilu technicznym wystawcy tokenu SAML. StorageReferenceId musi odwoływać się do nazwy klucza zasad.

<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>

Algorytm podpisu

Możesz skonfigurować algorytm podpisu używany do podpisywania asercji SAML. Możliwe wartości to Sha256, Sha384, Sha512lub Sha1. Upewnij się, że profil techniczny i aplikacja używają tego samego algorytmu podpisu. Użyj tylko algorytmu obsługiwanego przez certyfikat.

Skonfiguruj algorytm podpisu przy użyciu XmlSignatureAlgorithm klucza metadanych w elemecie jednostki Metadata uzależnionej.

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

Sprawdź podpis asercji SAML

Upewnij się, że dostawca usług SAML ustawił wartość WantAssertionsSigned na true, kiedy aplikacja oczekuje podpisania sekcji asercji SAML. Jeśli jest ona ustawiona na false lub nie istnieje, sekcja asercji nie zostanie podpisana.

Poniższy przykład przedstawia metadane dostawcy usług SAML, z WantAssertionsSigned ustawionym na 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>

Certyfikat podpisu

Zasady muszą określać certyfikat, który ma być używany do podpisywania sekcji asercji w odpowiedzi SAML. Jeśli nie masz jeszcze klucza zasad, utwórz go. Następnie skonfiguruj SamlAssertionSigning element metadanych w profilu technicznym wystawcy tokenu SAML. StorageReferenceId musi odwoływać się do nazwy klucza zasad.

<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>

Włączanie szyfrowania w asercji SAML

Gdy aplikacja oczekuje, że asercji SAML będą w formacie zaszyfrowanym, upewnij się, że szyfrowanie jest włączone w zasadach usługi Azure AD B2C.

Usługa Azure AD B2C używa certyfikatu klucza publicznego dostawcy usług do szyfrowania asercji SAML. Klucz publiczny musi istnieć w punkcie końcowym metadanych aplikacji SAML z wartością KeyDescriptoruse ustawioną na Encryption, jak pokazano w poniższym przykładzie:

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

Aby umożliwić usłudze Azure AD B2C wysyłanie zaszyfrowanych asercji, ustaw WantsEncryptedAssertion element metadanych na true wartość w profilu technicznym jednostki uzależnionej. Można również skonfigurować algorytm używany do szyfrowania asercji SAML.

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

Metoda szyfrowania

Aby skonfigurować metodę szyfrowania używaną do szyfrowania danych asercji SAML, ustaw DataEncryptionMethod klucz metadanych w ramach jednostki uzależnionej. Możliwe wartości to Aes256 (wartość domyślna), Aes192, Sha512lub Aes128. Metadane steruje wartością <EncryptedData> elementu w odpowiedzi SAML.

Aby skonfigurować metodę szyfrowania dla kopii klucza użytego do szyfrowania danych asercji SAML, ustaw klucz metadanych KeyEncryptionMethod w uczestniku zaufania. Dopuszczalne wartości:

Rsa15 (ustawienie domyślne): Algorytm PKCS (RsA Public Key Cryptography Standard) w wersji 1.5.
RsaOaep: Algorytm wypełniania szyfrowania RSA OAEP (Optimal Asymmetric Encryption Padding).

Metadane steruje wartością <EncryptedKey> elementu w odpowiedzi SAML.

Poniższy przykład przedstawia sekcję EncryptedAssertion asercji SAML. Zaszyfrowana metoda danych to Aes128, a zaszyfrowana metoda klucza to 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>

Format zaszyfrowanych asercji można zmienić. Aby skonfigurować format szyfrowania, ustaw klucz metadanych UseDetachedKeys w ramach strony polegającej. Możliwe wartości: true lub false (wartość domyślna). Gdy wartość jest ustawiona na true, odłączone klucze dodają zaszyfrowaną asercję jako element podrzędny EncryptedAssertion zamiast EncryptedData.

Skonfiguruj metodę i format szyfrowania przy użyciu kluczy metadanych w profilu technicznym podmiotu polegającego:

<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>

Skonfiguruj przepływ inicjowany przez dostawcę tożsamości

Gdy aplikacja oczekuje otrzymania asercji SAML bez uprzedniego wysłania żądania AuthN SAML do dostawcy tożsamości ,należy skonfigurować usługę Azure AD B2C dla przepływu inicjowanego przez dostawcę tożsamości.

W przepływie inicjowanym przez dostawcę tożsamości dostawca tożsamości (Azure AD B2C) rozpoczyna proces logowania. Dostawca tożsamości wysyła niezwiązaną z żądaniem odpowiedź SAML do dostawcy usług (Twoja aplikacja relying party).

Obecnie nie obsługujemy scenariuszy, w których inicjującym dostawcą tożsamości jest zewnętrzny dostawca tożsamości, z którym Azure AD B2C jest sfederowany, takich jak usługi Active Directory Federation Services lub Salesforce. Przepływ inicjowany przez dostawcę tożsamości jest obsługiwany tylko w przypadku uwierzytelniania konta lokalnego w usłudze Azure AD B2C.

Aby włączyć przepływ inicjowany przez dostawcę tożsamości (IdP), ustaw element metadanych na IdpInitiatedProfileEnabled w profilu technicznym strony polegającej.

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

Aby logować się lub rejestrować użytkownika przez proces inicjowany przez dostawcę tożsamości, użyj następującego adresu URL:

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

Zastąp następujące wartości:

Zastąp <tenant-name> nazwą dzierżawy.
Zastąp <policy-name> nazwą polityki partnera zależnego SAML.
Zastąp <app-identifier-uri> wartością identifierUris w pliku metadanych, na przykład https://contoso.onmicrosoft.com/app-name.
[Opcjonalnie] zastąp <relay-state> wartością uwzględnioną w żądaniu autoryzacji, która jest również zwracana w odpowiedzi tokenu. Parametr relay-state służy do kodowania informacji o stanie użytkownika w aplikacji przed wystąpieniem żądania uwierzytelnienia, na przykład strony, na której się znajdowały.

Przykładowe zasady

Aby przetestować aplikację testową SAML, możesz użyć pełnych przykładowych zasad:

Pobierz przykładowe zasady logowania inicjowane przez dostawcę usługi SAML-SP.
Zaktualizuj TenantId, aby dopasować nazwę dzierżawcy. W tym artykule użyto przykładowego contoso.b2clogin.com.
Zachowaj nazwę polityki B2C_1A_signup_signin_saml.

Skonfiguruj okres istnienia odpowiedzi SAML

Można skonfigurować czas, przez który odpowiedź SAML pozostaje prawidłowa. Ustaw okres istnienia przy użyciu TokenLifeTimeInSeconds elementu metadanych w profilu technicznym wystawcy tokenu SAML. Ta wartość to liczba sekund, które mogą upłynąć od sygnatury czasowej NotBefore, obliczona w momencie wystawienia tokenu. Domyślny okres istnienia to 300 sekund (pięć minut).

<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>

Konfigurowanie niesymetryczności czasu odpowiedzi SAML

Możesz skonfigurować odchylenie czasu zastosowane do znacznika czasu odpowiedzi NotBefore SAML. Ta konfiguracja gwarantuje, że jeśli czasy między dwiema platformami nie są zsynchronizowane, asercja SAML nadal będzie uważana za prawidłową, gdy mieści się w tym okresie odchylenia czasu.

Ustaw przesunięcie czasowe przy użyciu elementu metadanych TokenNotBeforeSkewInSeconds w profilu technicznym wystawcy tokenu SAML. Wartość niesymetryczności jest podana w sekundach z wartością domyślną 0. Maksymalna wartość to 3600 (jedna godzina).

Na przykład, gdy TokenNotBeforeSkewInSeconds jest ustawiona na 120 sekundy:

Token jest wystawiany o godzinie 13:05:10 CZASU UTC.
Token jest prawidłowy od 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>

Usuń milisekundy z daty i godziny

Możesz określić, czy milisekundy zostaną usunięte z wartości daty i godziny w odpowiedzi SAML. (Te wartości obejmują IssueInstant, NotBefore, NotOnOrAfter, i AuthnInstant.) Aby usunąć milisekundy, ustaw klucz metadanych RemoveMillisecondsFromDateTime w ramach strony polegającej. Możliwe wartości: false (wartość domyślna) lub 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>

Użyj identyfikatora wystawcy, aby zastąpić adres URI wystawcy

Jeśli masz wiele aplikacji SAML, które zależą od różnych wartości entityID, możesz zastąpić wartość IssuerUri w pliku strony ufającej. Aby zastąpić identyfikator URI wystawcy, skopiuj profil techniczny z identyfikatorem Saml2AssertionIssuer z pliku podstawowego i zastąp wartość IssuerUri.

Wskazówka

Skopiuj sekcję <ClaimsProviders> z bazy i zachowaj te elementy w dostawcy oświadczeń: <DisplayName>Token Issuer</DisplayName>, <TechnicalProfile Id="Saml2AssertionIssuer">i <DisplayName>Token Issuer</DisplayName>.

Przykład:

   <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>
     …

Zarządzanie sesją

Sesję między usługą Azure AD B2C i aplikacją jednostki uzależnionej SAML można zarządzać przy użyciu UseTechnicalProfileForSessionManagement elementu i samlSSOSessionProvider.

Wymuszanie ponownego uwierzytelnienia użytkowników

Aby wymusić ponowne uwierzytelnienie użytkowników, aplikacja może uwzględnić ForceAuthn atrybut w żądaniu uwierzytelniania SAML. Atrybut ForceAuthn jest wartością logiczną. Gdy zostanie ustawiona wartość true, sesja użytkownika zostanie unieważniona w usłudze Azure AD B2C, a użytkownik zostanie zmuszony do ponownego uwierzytelnienia.

Następujące żądanie uwierzytelniania SAML pokazuje, jak ustawić ForceAuthn atrybut na true.

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

Podpisywanie metadanych SAML dostawcy tożsamości usługi Azure AD B2C

Możesz poinstruować usługę Azure AD B2C o podpisaniu dokumentu metadanych dostawcy tożsamości SAML, jeśli wymaga tego aplikacja. Jeśli nie masz jeszcze klucza zasad, utwórz go. Następnie skonfiguruj MetadataSigning element metadanych w profilu technicznym wystawcy tokenu SAML. StorageReferenceId musi odwoływać się do nazwy klucza zasad.

<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>

Debugowanie protokołu SAML

Aby ułatwić konfigurowanie i debugowanie integracji z dostawcą usług, możesz użyć rozszerzenia przeglądarki dla protokołu SAML. Rozszerzenia przeglądarki obejmują rozszerzenie SAML DevTools dla programu Chrome, narzędzia SAML-tracer dla przeglądarki Firefox oraz narzędzia deweloperskie dla przeglądarki Edge lub Internet Explorer.

Korzystając z tych narzędzi, możesz sprawdzić integrację między aplikacją a usługą Azure AD B2C. Przykład:

Sprawdź, czy żądanie SAML zawiera podpis i określ, jaki algorytm jest używany do logowania się do żądania autoryzacji.
Sprawdź, czy usługa Azure AD B2C zwraca komunikat o błędzie.
Sprawdź, czy sekcja asercji jest zaszyfrowana.

Dalsze kroki

Więcej informacji na temat protokołu SAML można znaleźć na stronie internetowej OASIS.
Pobierz testową aplikację internetową SAML z repozytorium społeczności GitHub Azure AD B2C.