Optionen zum Registrieren einer SAML-Anwendung in Azure AD B2C

Dieses Feature ist nur für benutzerdefinierte Richtlinien verfügbar. Wählen Sie für Setupschritte im vorherigen Selektor die Option "Benutzerdefinierte Richtlinie " aus.

Angeben einer SAML-Antwortsignatur

Sie können ein Zertifikat angeben, das zum Signieren der SAML-Nachrichten verwendet werden soll. Die Nachricht ist das <samlp:Response> Element innerhalb der SAML-Antwort, die an die Anwendung gesendet wird.

Wenn Sie noch nicht über einen Richtlinienschlüssel verfügen, erstellen Sie einen. Konfigurieren Sie dann das SamlMessageSigning Metadatenelement im technischen Profil des SAML-Tokenausstellers. StorageReferenceId muss auf den Namen des Richtlinienschlüssels verweisen.

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

Signaturalgorithmus

Sie können den zum Signieren der SAML-Assertion verwendeten Signaturalgorithmus konfigurieren. Mögliche Werte lauten Sha256, Sha384, Sha512 oder Sha1. Stellen Sie sicher, dass das technische Profil und die Anwendung denselben Signaturalgorithmus verwenden. Verwenden Sie nur den Algorithmus, den Ihr Zertifikat unterstützt.

Konfigurieren Sie den Signaturalgorithmus, indem Sie den XmlSignatureAlgorithm Metadatenschlüssel innerhalb des Elements der vertrauenden Partei Metadata verwenden.

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

Überprüfen der SAML-Assertion-Signatur

Wenn Ihre Anwendung erwartet, dass der SAML-Assertionsabschnitt signiert wird, stellen Sie sicher, dass der SAML-Dienstanbieter die WantAssertionsSigned auf truefestgelegt hat. Wenn er auf false gesetzt ist oder nicht vorhanden ist, wird der Assertion-Abschnitt nicht signiert.

Im folgenden Beispiel sind die Metadaten für einen SAML-Dienstanbieter dargestellt, in denen WantAssertionsSigned auf true festgelegt ist.

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

Signatur-Zertifikat

Ihre Richtlinie muss ein Zertifikat angeben, das zum Signieren des SAML-Assertions-Abschnitts der SAML-Antwort verwendet werden soll. Wenn Sie noch nicht über einen Richtlinienschlüssel verfügen, erstellen Sie einen. Konfigurieren Sie dann das SamlAssertionSigning Metadatenelement im technischen Profil des SAML-Tokenausstellers. StorageReferenceId muss auf den Namen des Richtlinienschlüssels verweisen.

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

Aktivieren der Verschlüsselung in SAML-Assertionen

Wenn Ihre Anwendung erwartet, dass SAML-Assertionen in einem verschlüsselten Format vorliegen, stellen Sie sicher, dass die Verschlüsselung in der Azure AD B2C-Richtlinie aktiviert ist.

Azure AD B2C verwendet das Zertifikat mit öffentlichem Schlüssel des Dienstanbieters, um die SAML-Assertion zu verschlüsseln. Der öffentliche Schlüssel muss im Metadatenendpunkt der SAML-Anwendung vorhanden sein, wobei der KeyDescriptoruse Wert auf Encryptionfestgelegt ist, wie im folgenden Beispiel gezeigt:

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

Um Azure AD B2C das Senden verschlüsselter Assertionen zu ermöglichen, legen Sie das WantsEncryptedAssertion Metadatenelement im true auf fest. Sie können auch den Algorithmus konfigurieren, der zum Verschlüsseln der SAML-Assertion verwendet wird.

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

Verschlüsselungsmethode

Um die Verschlüsselungsmethode zu konfigurieren, die zum Verschlüsseln der SAML-Assertionsdaten verwendet wird, legen Sie den DataEncryptionMethod Metadatenschlüssel in der vertrauenden Seite fest. Mögliche Werte sind Aes256 (Standard), Aes192, Sha512oder Aes128. Die Metadaten bestimmen den Wert des <EncryptedData>-Elements in der SAML-Antwort.

Um die Verschlüsselungsmethode für die Verschlüsselung der Kopie des Schlüssels zu konfigurieren, der zum Verschlüsseln der SAML-Assertionsdaten verwendet wurde, legen Sie den KeyEncryptionMethod Metadatenschlüssel in der vertrauenden Seite fest. Mögliche Werte:

• Rsa15 (Standardwert): RSA PKCS-Algorithmus (Public Key Cryptography Standards), Version 1.5.
• RsaOaep: RSA Optimal Asymmetric Encryption Padding (OAEP)-Verschlüsselungsalgorithmus.

Die Metadaten bestimmen den Wert des <EncryptedKey>-Elements in der SAML-Antwort.

Das folgende Beispiel zeigt den EncryptedAssertion Abschnitt einer SAML-Assertion. Die verschlüsselte Datenmethode ist Aes128, und die verschlüsselte Schlüsselmethode ist 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>

Sie können das Format der verschlüsselten Assertionen ändern. Um das Verschlüsselungsformat zu konfigurieren, legen Sie den UseDetachedKeys Metadatenschlüssel in der vertrauenden Seite fest. Mögliche Werte: true und false (Standardwert). Wenn der Wert auf truegesetzt ist, fügen die getrennten Schlüssel die verschlüsselte Assertion als untergeordnetes Element von EncryptedAssertion anstelle von EncryptedDatahinzu.

Konfigurieren Sie die Verschlüsselungsmethode und das Verschlüsselungsformat mithilfe der Metadatenschlüssel im technischen Profil der vertrauenden Seite:

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

Konfigurieren des IdP-initiierten Flows

Wenn Ihre Anwendung erwartet, eine SAML-Assertion zu empfangen, ohne zuerst eine SAML-Authentifizierungsanforderung an den Identitätsanbieter (IdP) zu senden, müssen Sie Azure AD B2C für den IdP-initiierten Ablauf konfigurieren.

Im IdP-initiierten Ablauf startet der Identitätsanbieter (Azure AD B2C) den Anmeldevorgang. Der Identitätsanbieter sendet eine unverlangte SAML-Antwort an den Dienstleister (Ihre vertrauende Anwendung).

Szenarien werden derzeit nicht unterstützt, in denen es sich bei dem initiierenden Identitätsanbieter um einen externen Identitätsanbieter handelt, der mit Azure AD B2C verbunden ist, z. B. Active Directory-Verbunddienste oder Salesforce. Der vom IdP initiierte Ablauf wird nur für die Authentifizierung lokaler Konten in Azure AD B2C unterstützt.

Um den IdP-initiierten Flow zu aktivieren, legen Sie das IdpInitiatedProfileEnabled Metadatenelement im true auf fest.

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

Verwenden Sie die folgende URL, um sich anzumelden oder einen Benutzer über den vom IdP initiierten Flow zu registrieren:

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

Ersetzen Sie die folgenden Werte:

• Ersetzen Sie <tenant-name> durch den Namen Ihres Mandanten.
• Ersetzen Sie <policy-name> durch den Namen Ihrer SAML-Richtlinie für die vertrauende Seite.
• Ersetzen Sie <app-identifier-uri> durch den identifierUris-Wert in der Metadatendatei, zum Beispiel https://contoso.onmicrosoft.com/app-name.
• [Optional] Ersetzen Sie <relay-state> ihn durch einen Wert, der in der Autorisierungsanforderung enthalten ist und auch in der Tokenantwort zurückgegeben wird. Der relay-state Parameter wird verwendet, um Informationen über den Status des Benutzers in der App zu codieren, bevor die Authentifizierungsanforderung aufgetreten ist, z. B. die Seite, auf der er sich befand.

Beispielrichtlinie

Sie können eine vollständige Beispielrichtlinie für Tests mit der SAML-Test-App verwenden:

1. Laden Sie die Beispielrichtlinie für die SAML-SP-initiierte Anmeldung herunter.
2. Geben Sie für TenantId den Namen Ihres Mandanten an. In diesem Artikel wird das Beispiel contoso.b2clogin.com verwendet.
3. Behalten Sie den Richtliniennamen B2C_1A_signup_signin_saml bei.

Konfigurieren der Lebensdauer der SAML-Antwort

Sie können konfigurieren, wie lange die SAML-Antwort gültig bleibt. Legen Sie die Lebensdauer fest, indem Sie das TokenLifeTimeInSeconds Metadatenelement im technischen Profil des SAML-Tokenausstellers verwenden. Dieser Wert ist die Anzahl der Sekunden, die ab dem NotBefore Zeitstempel verstreichen können, berechnet zum Zeitpunkt der Tokenausstellung. Die Standardlebensdauer beträgt 300 Sekunden (fünf Minuten).

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

Konfigurieren der Zeitverschiebung einer SAML-Antwort

Sie können die Zeitabweichung konfigurieren, die auf den SAML-Antwortzeitstempel NotBefore angewendet wird. Diese Konfiguration stellt sicher, dass die SAML-Assertion auch dann als gültig gilt, wenn die Zeiten zwischen zwei Plattformen nicht synchron sind, wenn sie sich innerhalb dieser Zeitabweichung befindet.

Legen Sie die Zeitverschiebung mithilfe des TokenNotBeforeSkewInSeconds Metadatenelements im technischen Profil des SAML-Tokenausstellers fest. Der Verzerrungswert wird in Sekunden angegeben, mit einem Standardwert von 0. Der Höchstwert ist 3.600 (eine Stunde).

Zum Beispiel, wenn TokenNotBeforeSkewInSeconds auf 120 Sekunden festgelegt ist:

• Der Token wird um 13:05:10 UTC ausgegeben.
• Das Token ist ab 13:03:10 UTC gültig.

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

Entfernen von Millisekunden aus Datum und Uhrzeit

Sie können angeben, ob Millisekunden aus Datums- und Zeitwerten in der SAML-Antwort entfernt werden. (Zu diesen Werten gehören IssueInstant, NotBefore, NotOnOrAfterund AuthnInstant.) Um die Millisekunden zu entfernen, legen Sie den RemoveMillisecondsFromDateTime Metadatenschlüssel in der vertrauenden Seite fest. Mögliche Werte: false (Standard) oder 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>

Verwenden einer Aussteller-ID zum Überschreiben eines Aussteller-URIs

Wenn Sie über mehrere SAML-Anwendungen verfügen, die von unterschiedlichen entityID Werten abhängen, können Sie den Wert in der IssuerUri Datei der vertrauenden Seite überschreiben. Um den Aussteller-URI zu überschreiben, kopieren Sie das technische Profil mit der Saml2AssertionIssuer ID aus der Basisdatei und überschreiben Sie den IssuerUri Wert.

Beispiel:

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

Verwalten einer Sitzung

Sie können die Sitzung zwischen Azure AD B2C und der SAML-Anwendung der vertrauenden Seite verwalten, indem Sie das UseTechnicalProfileForSessionManagement Element und SamlSSOSessionProvider verwenden.

Erzwingen einer erneuten Authentifizierung von Benutzern

Um Benutzer zur erneuten Authentifizierung zu zwingen, kann die Anwendung das ForceAuthn Attribut in die SAML-Authentifizierungsanforderung aufnehmen. Bei dem ForceAuthn Attribut handelt es sich um einen booleschen Wert. Wenn sie auf truefestgelegt ist, wird die Sitzung des Benutzers in Azure AD B2C ungültig, und der Benutzer wird gezwungen, sich erneut zu authentifizieren.

Die folgende SAML-Authentifizierungsanforderung zeigt, wie das ForceAuthn Attribut auf truefestgelegt wird.

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

Signieren der SAML-IdP-Metadaten von Azure AD B2C

Sie können Azure AD B2C anweisen, das Metadatendokument für den SAML-Identitätsanbieter zu signieren, wenn die Anwendung dies erfordert. Wenn Sie noch nicht über einen Richtlinienschlüssel verfügen, erstellen Sie einen. Konfigurieren Sie dann das MetadataSigning Metadatenelement im technischen Profil des SAML-Tokenausstellers. StorageReferenceId muss auf den Namen des Richtlinienschlüssels verweisen.

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

Debuggen des SAML-Protokolls

Um die Integration mit Ihrem Dienstanbieter zu konfigurieren und zu debuggen, können Sie eine Browsererweiterung für das SAML-Protokoll verwenden. Zu den Browsererweiterungen gehören die SAML DevTools-Erweiterung für Chrome, SAML-tracer für Firefox und Entwicklertools für Edge oder Internet Explorer.

Mithilfe dieser Tools können Sie die Integration zwischen Ihrer Anwendung und Azure AD B2C überprüfen. Beispiel:

• Überprüfen Sie, ob die SAML-Anforderung eine Signatur enthält, und bestimmen Sie, welcher Algorithmus für die Anmeldung bei der Autorisierungsanforderung verwendet wird.
• Überprüfen Sie, ob Azure AD B2C eine Fehlermeldung zurückgibt.
• Überprüfen Sie, ob der Assertionsabschnitt verschlüsselt ist.

Nächste Schritte

• Weitere Informationen zum SAML-Protokoll finden Sie auf der OASIS-Website.
• Rufen Sie die SAML-Testweb-App aus dem GitHub-Communityrepository von Azure AD B2C ab.