Opcje rejestrowania aplikacji SAML w usłudze Azure AD B2C

Artykuł
10/18/2023

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

Sprawdzanie podpisu asercji SAML

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

W poniższym przykładzie przedstawiono metadane dostawcy usług SAML z ustawioną wartością WantAssertionsSigned 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 SAML 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 na potrzeby szyfrowania kopii klucza, który został użyty do szyfrowania danych asercji SAML, ustaw KeyEncryptionMethod klucz metadanych w ramach jednostki uzależnionej. Dopuszczalne wartości:

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

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 UseDetachedKeys klucz metadanych w ramach jednostki uzależnionej. Możliwe wartości: true lub false (wartość domyślna). Gdy wartość jest ustawiona na truewartość , 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 jednostki uzależnionej:

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

Konfigurowanie przepływu inicjowane 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 nieproszną odpowiedź SAML do dostawcy usług (aplikacja jednostki uzależnionej).

Obecnie nie obsługujemy scenariuszy, w których inicjowanie dostawcy tożsamości jest zewnętrznym dostawcą tożsamości federacyjnym z usługą Azure AD B2C, takimi 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, ustaw IdpInitiatedProfileEnabled element metadanych na true wartość w profilu technicznym jednostki uzależnionej.

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

Aby zalogować się lub zarejestrować użytkownika za pośrednictwem przepływu inicjowanego 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> ciąg nazwą dzierżawy.
Zastąp <policy-name> ciąg nazwą zasad jednostki uzależnionej SAML.
Zastąp <app-identifier-uri> ciąg wartością identifierUris w pliku metadanych, taką jak https://contoso.onmicrosoft.com/app-name.
[Opcjonalnie] zastąp <relay-state> element wartością uwzględniną 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żawy. W tym artykule użyto przykładowego contoso.b2clogin.com.
Zachowaj nazwę zasad B2C_1A_signup_signin_saml.

Konfigurowanie okresu 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ąć z sygnatury czasowej NotBefore obliczonej w czasie wystawiania 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ć niesymetryczność czasu zastosowaną do sygnatury czasowej odpowiedzi NotBefore SAML. Ta konfiguracja gwarantuje, że jeśli czasy między dwiema platformami nie są zsynchronizowane, asercji SAML będzie nadal uważana za prawidłową, gdy będzie w tym czasie niesymetryczna.

Ustaw niesymetryczność czasu przy użyciu TokenNotBeforeSkewInSeconds elementu metadanych 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, , NotOnOrAfterNotBeforei AuthnInstant.) Aby usunąć milisekundy, ustaw RemoveMillisecondsFromDateTime klucz metadanych w ramach jednostki uzależnionej. 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żywanie identyfikatora wystawcy do zastępowania identyfikatora URI wystawcy

Jeśli masz wiele aplikacji SAML, które zależą od różnych entityID wartości, możesz zastąpić IssuerUri wartość w pliku jednostki uzależnionej. Aby zastąpić identyfikator URI wystawcy, skopiuj profil techniczny z identyfikatorem Saml2AssertionIssuer z pliku podstawowego i przesłoń IssuerUri wartość.

Napiwek

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

Jeśli aplikacja wymaga, możesz poinstruować usługę Azure AD B2C o podpisaniu dokumentu metadanych dostawcy tożsamości SAML. 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 programistyczne 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.

Następne 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 usługi GitHub usługi Azure AD B2C.

Udostępnij za pośrednictwem