Freigeben über

Konfigurieren des Sitzungsverhaltens in Azure Active Directory B2C

  • Artikel

Vorbereitung: Wählen Sie mithilfe des Selektors Richtlinientyp auswählen den Typ der einzurichtenden Richtlinie aus. Azure Active Directory B2C bietet zwei Methoden zum Definieren der Benutzerinteraktion mit Ihren Anwendungen: vordefinierte Benutzerflows oder vollständig konfigurierbare benutzerdefinierte Richtlinien. Die Schritte, die in diesem Artikel erforderlich sind, unterscheiden sich für jede Methode.

Mit dem einmaligen Anmelden (Single Sign-On, SSO) ist für Sicherheit und Komfort gesorgt, wenn sich Benutzer anwendungsübergreifend in Azure Active Directory B2C (Azure AD B2C) anmelden. In diesem Artikel werden die Methoden für das einmalige Anmelden beschrieben, die in Azure AD B2C verwendet werden. Sie erhalten zudem Hilfestellung beim Auswählen der am besten geeigneten SSO-Methode zum Konfigurieren Ihrer Anwendungen.

Mit der einmaligen Anmeldung melden sich Benutzer einmal mit einem einzigen Konto an und erhalten Zugriff auf mehrere Anwendungen. Dabei kann es sich unabhängig von Plattform oder Domänennamen um eine mobile Anwendung bzw. eine Web- oder Single-Page-Anwendung handeln.

Wenn sich der Benutzer anfänglich bei einer Anwendung anmeldet, speichert Azure AD B2C eine cookiebasierte Sitzung. Bei nachfolgenden Authentifizierungsanforderungen liest und überprüft Azure AD B2C die cookiebasierte Sitzung und gibt ein Zugriffstoken aus, ohne den Benutzer zur erneuten Anmeldung aufzufordern. Wenn die cookiebasierte Sitzung abläuft oder ungültig wird, wird der Benutzer zur erneuten Anmeldung aufgefordert.

Voraussetzungen

Übersicht über Azure AD B2C-Sitzungen

Die Integration mit Azure AD B2C beinhaltet drei SSO-Sitzungstypen:

  • Azure AD B2C: Sitzung wird von Azure AD B2C verwaltet
  • Verbundidentitätsanbieter: Sitzung wird vom Identitätsanbieter (z. B. Facebook, Salesforce oder Microsoft-Konto) verwaltet
  • Anwendung: Sitzung wird von der mobilen Anwendung bzw. der Web- oder Single-Page-Anwendung verwaltet

SSO session

Azure AD B2C-Sitzung

Wenn sich ein Benutzer erfolgreich mit einem lokalen oder Social Media-Konto authentifiziert, speichert Azure AD B2C eine cookiebasierte Sitzung im Browser des Benutzers. Das Cookie wird unter dem Domänennamen des Azure AD B2C-Mandanten gespeichert, z. B. https://contoso.b2clogin.com.

Wenn sich ein Benutzer mit einem Verbundkonto anmeldet, beginnt ein Sitzungszeitfenster, auch bekannt als Time-to-Live (TTL). Wenn sich der Benutzer bei derselben oder einer anderen Anwendung innerhalb dieses TTL anmeldet, versucht Azure AD B2C, ein neues Zugriffstoken vom Verbundidentitätsanbieter abzurufen. Wenn die Verbundidentitätsanbieter-Sitzung abgelaufen ist oder ungültig wird, fordert der Verbundidentitätsanbieter den Benutzer zur Eingabe seiner Anmeldeinformationen auf. Wenn die Sitzung des Benutzers fortgesetzt wird oder der Benutzer mit einem lokalen Konto anstelle eines Verbundkontos angemeldet ist, autorisiert Azure AD B2C den Benutzer und verhindert weitere Eingabeaufforderungen.

Sie können das Sitzungsverhalten konfigurieren. Dazu zählen auch die Gültigkeitsdauer der Sitzung und die Art, wie Azure AD B2C die Sitzung über Richtlinien und Anwendungen freigibt.

Sitzung eines Verbundidentitätsanbieters

Ein Social Media- oder Unternehmensidentitätsanbieter verwaltet seine eigene Sitzung. Das Cookie wird unter dem Domänennamen des Identitätsanbieters gespeichert, z. B. https://login.salesforce.com. Die Verbundidentitätsanbieter-Sitzung wird nicht von Azure AD B2C gesteuert. Das Sitzungsverhalten wird stattdessen vom Verbundidentitätsanbieter bestimmt.

Nehmen Sie das folgende Szenario als Beispiel:

  1. Ein Benutzer meldet sich bei Facebook an, um seinen Feed zu überprüfen.
  2. Zu einem späteren Zeitpunkt öffnet der Benutzer Ihre Anwendung und startet den Anmeldevorgang. Die Anwendung leitet den Benutzer zu Azure AD B2C um, um den Anmeldevorgang abzuschließen.
  3. Auf der Registrierungs- oder Anmeldeseite von Azure AD B2C wählt der Benutzer die Anmeldung mit seinem Facebook-Konto aus. Der Benutzer wird zu Facebook umgeleitet. Wenn es eine aktive Sitzung bei Facebook gibt, wird der Benutzer nicht aufgefordert, seine Anmeldedaten einzugeben und wird sofort mit einem Facebook-Token zu Azure AD B2C weitergeleitet.

Anwendungssitzung

Ein OAuth2-Zugriffstoken, ID-Token oder SAML-Token kann eine Web-, Mobil- oder Einzelseitenanwendung schützen. Wenn ein Benutzer versucht, auf eine geschützte Ressource in der Anwendung zuzugreifen, prüft die Anwendung, ob auf der Anwendungsseite eine aktive Sitzung vorhanden ist. Wenn keine Anwendungssitzung vorhanden ist oder die Sitzung abläuft, leitet die Anwendung den Benutzer zur Azure AD B2C-Anmeldeseite weiter.

Die Anwendungssitzung kann eine cookiebasierte Sitzung sein, die unter dem Domänennamen der Anwendung gespeichert wird, z. B. https://contoso.com. Mobile Anwendungen speichern die Sitzung möglicherweise anders, verwenden aber einen ähnlichen Ansatz.

Konfigurieren des Verhaltens von Azure AD B2C-Sitzungen

Sie können das Verhalten der Azure AD B2C-Sitzung konfigurieren, einschließlich:

  • Lebensdauer der Web-App-Sitzung (Minuten): die Zeitspanne, in der das Azure AD B2C-Sitzungscookie nach erfolgreicher Authentifizierung im Browser des Benutzers gespeichert wird. Die Sitzungslebensdauer kann auf bis zu 24 Stunden festgelegt werden.

  • Timeout für Web-App-Sitzung: Gibt an, wie eine Sitzung durch die Einstellung der Sitzungslebensdauer oder durch die Einstellung „Angemeldet bleiben“ (Keep Me Signed In, KMSI) verlängert wird.

    • Rollierend: Gibt an, dass die Sitzung jedes Mal verlängert wird, wenn der Benutzer eine cookiebasierte Authentifizierung ausführt (Standardeinstellung).
    • Absolut – Gibt an, dass sich der Benutzer nach dem angegebenen Zeitraum erneut authentifizieren muss.

  • SSO-Konfiguration: Die Azure AD B2C-Sitzung kann mit den folgenden Bereichen konfiguriert werden:

    • Mandant: Dies ist die Standardeinstellung. Mit dieser Einstellung können mehrere Anwendungen und Benutzerflows in Ihrem B2C-Mandanten die gleiche Benutzersitzung gemeinsam nutzen. Beispiel: Sobald sich ein Benutzer bei einer Anwendung angemeldet hat, kann er sich auch beim Zugriff auf eine andere Anwendung nahtlos anmelden.
    • Anwendung: Mit dieser Einstellung können Sie eine Benutzersitzung ausschließlich für eine Anwendung beibehalten, unabhängig von anderen Anwendungen. Beispiel: Diese Einstellung können Sie verwenden, wenn sich der Benutzer bei Contoso Pharmacy anmelden soll, auch wenn er sich bereits bei Contoso Groceries angemeldet hat.
    • Richtlinie: Mit dieser Einstellung können Sie eine Benutzersitzung ausschließlich für einen Benutzerflow beibehalten, unabhängig von den Anwendungen, die diesen verwenden. Beispielsweise gewährt Azure AD B2C dem Benutzer Zugriff auf Sicherheitsteile mehrerer Anwendungen, wenn sich der Benutzer bereits angemeldet und einen mehrstufigen Authentifizierungsschritt (MFA) abgeschlossen hat. Dieser Zugriff wird fortgesetzt, solange die Sitzung, die dem Benutzerablauf zugeordnet ist, aktiv bleibt.
    • Unterdrückt: Diese Einstellung zwingt den Benutzer, bei jeder Ausführung der Richtlinie den gesamten Benutzerflow zu durchlaufen.

Konfigurieren des Benutzerflows

Führen Sie die folgenden Schritte aus, um das Sitzungsverhalten in Ihrem Benutzerflow zu konfigurieren:

  1. Melden Sie sich beim Azure-Portal an.
  2. Wenn Sie Zugriff auf mehrere Mandanten haben, wählen Sie das Symbol Einstellungen im Menü oben aus, um über das Menü Verzeichnisse + Abonnements zu Ihrem Azure AD B2C-Mandanten zu wechseln.
  3. Wählen Sie links oben im Azure-Portal die Option Alle Dienste aus, suchen Sie nach Azure AD B2C, und wählen Sie dann diese Option aus.
  4. Wählen Sie Benutzerflows aus.
  5. Öffnen Sie den Benutzerflow, den Sie zuvor erstellt haben.
  6. Wählen Sie Eigenschaften aus.
  7. Konfigurieren Sie Lebensdauer der Web-App-Sitzung (Minuten) , Timeout für Web-App-Sitzung, Konfiguration des einmaligen Anmeldens und ID-Token in Abmeldeanforderungen erforderlich nach Bedarf.
  8. Klicken Sie auf Speichern.

Konfigurieren der benutzerdefinierten Richtlinie

Führen Sie die folgenden Schritte aus, um das Sitzungsverhalten in Ihrer benutzerdefinierten Richtlinie zu konfigurieren:

  1. Öffnen Sie die RP-Datei (Relying Party, vertrauende Seite), z. B. SignUpOrSignin.xml.

  2. Wenn noch keine vorhanden ist, fügen Sie dem <RelyingParty>-Element das folgende <UserJourneyBehaviors>-Element hinzu. Er muss direkt nach <DefaultUserJourney ReferenceId="UserJourney Id"/> angeordnet werden.

    <UserJourneyBehaviors>
  <SingleSignOn Scope="Application" />
  <SessionExpiryType>Absolute</SessionExpiryType>
  <SessionExpiryInSeconds>86400</SessionExpiryInSeconds>
</UserJourneyBehaviors>

    Nachdem Sie die User Journey-Verhaltenselemente hinzugefügt haben, sollte das RelyingParty-Element wie im folgenden Beispiel aussehen:

    <RelyingParty>
  <DefaultUserJourney ReferenceId="SignUpOrSignIn" />
  <UserJourneyBehaviors>
    <SingleSignOn Scope="Application" />
    <SessionExpiryType>Absolute</SessionExpiryType>
    <SessionExpiryInSeconds>86400</SessionExpiryInSeconds>
  </UserJourneyBehaviors>
  <TechnicalProfile Id="PolicyProfile">
    <DisplayName>PolicyProfile</DisplayName>
    <Protocol Name="OpenIdConnect" />
    <OutputClaims>
      <OutputClaim ClaimTypeReferenceId="displayName" />
      <OutputClaim ClaimTypeReferenceId="givenName" />
      ...
    </OutputClaims>
    <SubjectNamingInfo ClaimType="sub" />
  </TechnicalProfile>
</RelyingParty>

  3. Ändern Sie den Wert des Scope-Attributs in einen der möglichen Werte: Suppressed, Tenant, Application oder Policy. Weitere Informationen finden Sie im Referenzartikel zu relyingParty.

  4. Legen Sie das SessionExpiryType-Element auf Rolling oder Absolute fest. Weitere Informationen finden Sie im Referenzartikel zu relyingParty.

  5. Legen Sie das SessionExpiryInSeconds-Element auf einen numerischen Wert zwischen 900 Sekunden (15 Minuten) und 86.400 Sekunden (24 Stunden) fest. Weitere Informationen finden Sie im Referenzartikel zu relyingParty.

Aktivieren von „Angemeldet bleiben“

Sie können das Feature „Angemeldet bleiben“ für Benutzer Ihrer webbasierten und nativen Anwendungen aktivieren, die über lokale Konten in Ihrem Azure AD B2C-Verzeichnis verfügen. Wenn Sie das Feature aktivieren, haben Benutzer die Möglichkeit, angemeldet zu bleiben, was dazu führt, dass die Sitzung auch nach dem Schließen des Browsers aktiv bleibt. Die Sitzung wird durch Festlegen eines persistenten Cookies verwaltet. Benutzer, die die Option „Angemeldet bleiben“ auswählen, können den Browser erneut öffnen, ohne zur Eingabe ihres Benutzernamens und Kennworts aufgefordert zu werden. Dieser Zugriff (persistentes Cookie) wird widerrufen, wenn sich ein Benutzer abmeldet. Weitere Informationen finden Sie in der Livedemo.

Example sign-up sign-in page showing a Keep me signed in checkbox

„Angemeldet bleiben“ kann auf der Ebene individueller Benutzerflows konfiguriert werden. Beachten Sie Folgendes, bevor Sie „Angemeldet bleiben“ für Ihre Benutzerflows aktivieren:

  • „Angemeldet bleiben“ wird nur für die empfohlenen Versionen der Benutzerflows für Registrierung und Anmeldung (Sign-Up/Sign-In, SUSI), Anmeldung und Profilbearbeitung unterstützt. Wenn Sie derzeit Standard- (Legacy) oder Legacy-Vorschau – v2-Versionen dieser Benutzerströme haben und KMSI aktivieren möchten, müssen Sie neue, empfohlene Versionen dieser Benutzerströme erstellen.
  • KMSI wird nicht für das Zurücksetzen von Passwörtern oder die Anmeldung von Benutzern unterstützt.
  • Wenn Sie „Angemeldet bleiben“ für alle Anwendungen in Ihrem Mandanten aktivieren möchten, empfiehlt es sich, „Angemeldet bleiben“ für alle Benutzerflows in Ihrem Mandanten zu aktivieren. Da einem Benutzer im Zuge einer Sitzung mehrere Richtlinien begegnen können, kann es vorkommen, dass ein Benutzer auf eine Richtlinie trifft, für die „Angemeldet bleiben“ nicht aktiviert ist, was dazu führen würde, dass das Cookie für „Angemeldet bleiben“ aus der Sitzung entfernt wird.
  • KMSI sollte auf öffentlichen Computern nicht aktiviert sein.

Konfigurieren von „Angemeldet bleiben“ für einen Benutzerflow

So aktivieren Sie „Angemeldet bleiben“ für Ihren Benutzerflow:

  1. Melden Sie sich beim Azure-Portal an.

  2. Wenn Sie Zugriff auf mehrere Mandanten haben, wählen Sie das Symbol Einstellungen im Menü oben aus, um über das Menü Verzeichnisse + Abonnements zu Ihrem Azure AD B2C-Mandanten zu wechseln.

  3. Wählen Sie links oben im Azure-Portal die Option Alle Dienste aus, suchen Sie nach Azure AD B2C, und wählen Sie dann diese Option aus.

  4. Wählen Sie Benutzerflows (Richtlinien) aus.

  5. Öffnen Sie den Benutzerflow, den Sie zuvor erstellt haben.

  6. Wählen Sie Eigenschaften aus.

  7. Wählen Sie unterSitzungsverhalten die Option „Angemeldet bleiben“ in Sitzung aktivieren aus. Geben Sie als Nächstes neben Bei Sitzung angemeldet bleiben (Tage) einen Wert zwischen 1 und 90 ein, um die Anzahl von Tagen anzugeben, für die eine Sitzung geöffnet bleiben kann.

    Enable keep me signed in session

Benutzer sollten diese Option auf öffentlichen Computern nicht aktivieren.

Konfigurieren des Seitenbezeichners

Legen Sie zum Aktivieren von KMSI das DataUri-Element für die Inhaltsdefinition auf Seitenbezeichnerunifiedssp und die Seitenversion auf 1.1.0 oder höher fest.

  1. Öffnen Sie die Erweiterungsdatei Ihrer Richtlinie. Beispielsweise SocialAndLocalAccounts/TrustFrameworkExtensions.xml. Diese Erweiterungsdatei ist eine der Richtliniendateien, die im Starterpaket für benutzerdefinierte Richtlinien enthalten sind, das Sie unter der Voraussetzung Erste Schritte mit benutzerdefinierten Richtlinien erhalten.

  2. Suchen Sie nach dem Element BuildingBlocks. Wenn das Element nicht vorhanden ist, fügen Sie es hinzu.

  3. Fügen Sie das ContentDefinitions-Element dem Element BuildingBlocks der Richtlinie hinzu.

    Ihre benutzerdefinierte Richtlinie sollte wie der folgende Codeausschnitt aussehen:

    <BuildingBlocks>
  <ContentDefinitions>
    <ContentDefinition Id="api.signuporsignin">
      <DataUri>urn:com:microsoft:aad:b2c:elements:unifiedssp:1.1.0</DataUri>
    </ContentDefinition>
  </ContentDefinitions>
</BuildingBlocks>

Hinzufügen der Metadaten zum selbstbestätigten technischen Profil

Um das Kontrollkästchen KMSI zur Registrierungs-und Anmeldeseite hinzuzufügen, legen Sie die setting.enableRememberMe-Metadaten auf TRUE fest. Überschreiben Sie in der Erweiterungsdatei die technischen Profile in SelfAsserted-LocalAccountSignin-Email.

  1. Suchen Sie das ClaimsProviders-Element. Wenn das Element nicht vorhanden ist, fügen Sie es hinzu.

  2. Fügen Sie dem ClaimsProviders-Element die folgenden Anspruchsanbieter hinzu:

    <ClaimsProvider>
  <DisplayName>Local Account</DisplayName>
  <TechnicalProfiles>
    <TechnicalProfile Id="SelfAsserted-LocalAccountSignin-Email">
      <Metadata>
        <Item Key="setting.enableRememberMe">True</Item>
      </Metadata>
    </TechnicalProfile>
  </TechnicalProfiles>
</ClaimsProvider>

  3. Speichern Sie die Erweiterungsdatei.

Konfigurieren einer Datei der vertrauenden Seite

Aktualisieren Sie als Nächstes die Datei der vertrauenden Seite, mit der die erstellte User Journey initiiert wird. Mit diesem keepAliveInDays-Parameter können Sie festlegen, wie lange das Sitzungscookie „Keep me signed in/Ich bleibe eingeloggt“ (KMSI) bestehen bleiben soll. Wenn Sie den Wert beispielsweise auf 30 setzen, bleibt der KMSI-Sitzungscookie 30 Tage lang bestehen. Der zulässige Bereich für diesen Wert liegt zwischen 1 und 90 Tagen. Durch Festlegen des Werts auf 0 wird die Funktion „Angemeldet bleiben“ deaktiviert.

  1. Öffnen Sie Ihre benutzerdefinierte Richtliniendatei. Beispiel: SignUpOrSignin.xml.

  2. Fügen Sie dem Knoten <RelyingParty> einen untergeordneten Knoten <UserJourneyBehaviors> hinzu, falls dieser noch nicht vorhanden ist. Er muss direkt nach <DefaultUserJourney ReferenceId="User journey Id" /> angeordnet werden. Beispiel: <DefaultUserJourney ReferenceId="SignUpOrSignIn" />.

  3. Fügen Sie den folgenden Knoten als untergeordnetes Element des <UserJourneyBehaviors>-Elements hinzu.

    <UserJourneyBehaviors>
  <SingleSignOn Scope="Tenant" KeepAliveInDays="30" />
  <SessionExpiryType>Absolute</SessionExpiryType>
  <SessionExpiryInSeconds>1200</SessionExpiryInSeconds>
</UserJourneyBehaviors>

Sie legen sowohl „KeepAliveInDays“ als auch „SessionExpiryInSeconds“ fest. Wenn ein Benutzer während der Anmeldung KMSI aktiviert, wird „keepAliveInDays“ verwendet, um die Cookies festzulegen. Andernfalls wird der im Parameter „SessionExpiryInSeconds“ angegebene Wert verwendet. Es wird empfohlen, den Wert von „SessionExpiryInSeconds“ auf einen kurzen Zeitraum (1200 Sekunden) und den Wert von „KeepAliveInDays“ auf einen relativ langen Zeitraum (30 Tage) festzulegen. Dies ist im folgenden Beispiel dargestellt:

<RelyingParty>
  <DefaultUserJourney ReferenceId="SignUpOrSignIn" />
  <UserJourneyBehaviors>
    <SingleSignOn Scope="Tenant" KeepAliveInDays="30" />
    <SessionExpiryType>Absolute</SessionExpiryType>
    <SessionExpiryInSeconds>1200</SessionExpiryInSeconds>
  </UserJourneyBehaviors>
  <TechnicalProfile Id="PolicyProfile">
    <DisplayName>PolicyProfile</DisplayName>
    <Protocol Name="OpenIdConnect" />
    <OutputClaims>
      <OutputClaim ClaimTypeReferenceId="displayName" />
      <OutputClaim ClaimTypeReferenceId="givenName" />
      <OutputClaim ClaimTypeReferenceId="surname" />
      <OutputClaim ClaimTypeReferenceId="email" />
      <OutputClaim ClaimTypeReferenceId="objectId" PartnerClaimType="sub"/>
      <OutputClaim ClaimTypeReferenceId="identityProvider" />
      <OutputClaim ClaimTypeReferenceId="tenantId" AlwaysUseDefaultValue="true" DefaultValue="{Policy:TenantObjectId}" />
    </OutputClaims>
    <SubjectNamingInfo ClaimType="sub" />
  </TechnicalProfile>
</RelyingParty>

Abmelden

Wenn Sie den Benutzer bei der Anwendung abmelden möchten, reicht es nicht aus, die Cookies der Anwendung zu löschen oder die Sitzung mit dem Benutzer auf andere Weise zu beenden. Sie müssen den Benutzer für die Abmeldung zu Azure AD B2C umleiten. Andernfalls kann sich der Benutzer möglicherweise erneut bei Ihren Anwendungen authentifizieren, ohne seine Anmeldedaten erneut einzugeben.

Auf die Abmeldeanforderung reagiert Azure AD B2C wie folgt:

  1. Die cookiebasierte Azure AD B2C-Sitzung wird für ungültig erklärt.
  2. Azure AD B2C versucht, den Benutzer vom Verbundidentitätsanbieter abzumelden.
  1. Die cookiebasierte Azure AD B2C-Sitzung wird für ungültig erklärt.
  2. Azure AD B2C versucht, den Benutzer vom Verbundidentitätsanbieter abzumelden:
    • OpenId Connect, wenn der bekannte Konfigurationsendpunkt des Identitätsanbieters eine end_session_endpoint-Adresse angibt. Die Abmeldeanforderung übergibt den id_token_hint-Parameter nicht. Wenn der Anbieter der Verbundidentität diesen Parameter verlangt, schlägt die Abmeldeanfrage fehl.
    • OAuth2, wenn die Metadaten des Identitätsanbieters die end_session_endpoint-Adresse enthalten.
    • SAML, wenn die Metadaten des Identitätsanbieters die SingleLogoutService-Adresse enthalten.
  3. Optional nimmt Azure AD B2C die Abmeldung bei anderen Anwendungen vor. Weitere Informationen finden Sie im Abschnitt Einmaliges Abmelden.

Hinweis

Sie können das Abmelden vom Verbundidentitätsanbieter deaktivieren, indem Sie die Metadaten SingleLogoutEnabled im technischen Profil des Identitätsanbieters auf false festlegen.

Bei der Abmeldung wird zwar der SSO-Status des Benutzers bei Azure AD B2C gelöscht, der Benutzer wird möglicherweise jedoch nicht von seiner Sitzung beim Social Media-Identitätsanbieter abgemeldet. Wenn der Benutzer bei einer nachfolgenden Anmeldung den gleichen Identitätsanbieter auswählt, kann er sich möglicherweise ohne Eingabe seiner Anmeldeinformationen erneut authentifizieren. Wenn sich ein Benutzer von der Anwendung abmelden möchte, bedeutet dies nicht unbedingt, dass er sich auch vollständig von seinem Facebook-Konto abmelden möchte. Wenn jedoch lokale Konten verwendet werden, wird die Sitzung des Benutzers ordnungsgemäß beendet.

Einmaliges Abmelden

Wenn Sie den Benutzer zum Azure AD B2C-Abmeldeendpunkt (für OAuth2 und OpenID Connect) umleiten oder eine LogoutRequest senden (für SAML), löscht Azure AD B2C die Sitzung des Benutzers im Browser. Allerdings kann der Benutzer weiterhin bei anderen Anwendungen angemeldet sein, die Azure AD B2C für die Authentifizierung verwenden. Um den Benutzer von allen Anwendungen abzumelden, für die eine Sitzung aktiv ist, unterstützt Azure AD B2C einmaliges Abmelden, auch als Single Log-Out (SLO) bekannt.

Bei der Abmeldung sendet Azure AD B2C gleichzeitig eine HTTP-Anforderung an die registrierte Abmelde-URL aller Anwendungen, bei denen der Benutzer aktuell angemeldet ist.

Konfigurieren Ihrer benutzerdefinierten Richtlinie

Um das einmalige Abmelden zu unterstützen, müssen die technischen Profile des Tokenausstellers für JWT und SAML Folgendes angeben:

  • Protokollname, z. B. <Protocol Name="OpenIdConnect" />
  • Verweis auf das technische Profil für die Sitzung, z. B. UseTechnicalProfileForSessionManagement ReferenceId="SM-jwt-issuer" />.

Das folgende Beispiel veranschaulicht die JWT- und SAML-Tokenaussteller mit einmaligem Abmelden:

<ClaimsProvider>
  <DisplayName>Local Account SignIn</DisplayName>
  <TechnicalProfiles>
    <!-- JWT Token Issuer -->
    <TechnicalProfile Id="JwtIssuer">
      <DisplayName>JWT token Issuer</DisplayName>
      <Protocol Name="OpenIdConnect" />
      <OutputTokenFormat>JWT</OutputTokenFormat>
      ...    
      <UseTechnicalProfileForSessionManagement ReferenceId="SM-jwt-issuer" />
    </TechnicalProfile>

    <!-- Session management technical profile for OIDC based tokens -->
    <TechnicalProfile Id="SM-jwt-issuer">
      <DisplayName>Session Management Provider</DisplayName>
      <Protocol Name="Proprietary" Handler="Web.TPEngine.SSO.OAuthSSOSessionProvider, Web.TPEngine, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" />
    </TechnicalProfile>

    <!--SAML token issuer-->
    <TechnicalProfile Id="Saml2AssertionIssuer">
      <DisplayName>SAML token issuer</DisplayName>
      <Protocol Name="SAML2" />
      <OutputTokenFormat>SAML2</OutputTokenFormat>
      ...
      <UseTechnicalProfileForSessionManagement ReferenceId="SM-Saml-issuer" />
    </TechnicalProfile>

    <!-- Session management technical profile for SAML based tokens -->
    <TechnicalProfile Id="SM-Saml-issuer">
      <DisplayName>Session Management Provider</DisplayName>
      <Protocol Name="Proprietary" Handler="Web.TPEngine.SSO.SamlSSOSessionProvider, Web.TPEngine, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" />
    </TechnicalProfile>
  </TechnicalProfiles>
</ClaimsProvider>

Konfigurieren der Anwendung

Konfigurieren einer Anwendung für einmaliges Abmelden:

  • Konfigurieren Sie für SAML-Dienstanbieter die Anwendung mit dem SingleLogoutService-Speicherort im SAML-Metadatendokument. Sie können auch die App-Registrierung logoutUrl konfigurieren. Weitere Informationen finden Sie unter Festlegen der Abmelde-URL.
  • Legen Sie für OpenID Connect- oder OAuth2-Anwendungen das logoutUrl-Attribut Ihres App-Registrierungsmanifests fest. Konfigurieren der Abmelde-URL:
    1. Wählen Sie im Azure AD B2C-Menü die Option App-Registrierungen.
    2. Wählen Sie Ihre Anwendungsregistrierung aus.
    3. Wählen Sie unter Verwalten die Option Authentifizierung aus.
    4. Konfigurieren Sie unter der Front-Channel-Abmelde-URL Ihre Abmelde-URL.

Verarbeiten von Anforderungen für einmaliges Abmelden

Wenn Azure AD B2C die Abmeldeanforderung empfängt, wird ein Front-Channel-HTML-iFrame verwendet, um eine HTTP-Anforderung an die registrierte Abmelde-URL jeder konfigurierten Anwendung zu senden, bei der der Benutzer aktuell angemeldet ist. Beachten Sie, dass die Anwendung, welche die Abmeldeanforderung auslöst, diese Abmeldenachricht erhält. Die Anwendungen müssen auf die Abmeldeanforderung mit dem Löschen der Anwendungssitzung reagieren, die den Benutzer identifiziert.

  • Bei OpenID Connect- und OAuth2-Anwendungen sendet Azure AD B2C eine HTTP GET-Anforderung an die registrierte Abmelde-URL.
  • Bei SAML-Anwendungen sendet Azure AD B2C eine SAML-Abmeldeanforderung an die registrierte Abmelde-URL.

Wenn Azure AD B2C alle Anwendungen über die Abmeldung benachrichtigt, wird eine der folgenden Aktionen ausgeführt:

  • Bei OpenID Connect- oder OAuth2-Anwendungen leitet es den Benutzer zu der angeforderten post_logout_redirect_uri weiter, einschließlich des (optionalen) state-Parameters, der in der ursprünglichen Anfrage angegeben wurde. Beispiel: https://contoso.com/logout?state=foo.
  • Bei SAML-Anwendungen sendet es eine SAML-Abmeldeantwort per HTTP POST an die Anwendung, welche die Abmeldeanfrage ursprünglich gesendet hat.

Sichern der Umleitung beim Abmelden

Nach der Abmeldung wird der Benutzer zu der im post_logout_redirect_uri-Parameter angegebenen URI umgeleitet, unabhängig von den Antwort-URLs, die Sie für die Anwendung angeben. Wenn jedoch ein gültiger id_token_hint-Wert übergeben wird und die Option ID-Token in Abmeldeanforderungen erforderlich aktiviert ist, überprüft Azure AD B2C, ob der Wert von post_logout_redirect_uri einem der für die Anwendung konfigurierten Umleitungs-URIs entspricht, bevor die Umleitung ausgeführt wird. Wenn für die Anwendung keine passende Antwort-URL konfiguriert wurde, wird eine Fehlermeldung angezeigt und der Benutzer wird nicht weitergeleitet.

So erzwingen Sie ein ID-Token in Abmeldeanforderungen

  1. Melden Sie sich beim Azure-Portal an.
  2. Wenn Sie Zugriff auf mehrere Mandanten haben, wählen Sie das Symbol Einstellungen im Menü oben aus, um über das Menü Verzeichnisse + Abonnements zu Ihrem Azure AD B2C-Mandanten zu wechseln.
  3. Wählen Sie links oben im Azure-Portal die Option Alle Dienste aus, suchen Sie nach Azure AD B2C, und wählen Sie dann diese Option aus.
  4. Wählen Sie Benutzerflows aus.
  5. Öffnen Sie den Benutzerflow, den Sie zuvor erstellt haben.
  6. Wählen Sie Eigenschaften aus.
  7. Aktivieren Sie die Option ID-Token in Abmeldeanforderungen erforderlich.

Um festzulegen, dass ein ID-Token in Abmeldeanforderungen erforderlich ist, fügen Sie innerhalb des RelyingParty-Elements ein UserJourneyBehaviors-Element hinzu. Legen Sie dann den EnforceIdTokenHintOnLogout-Wert des SingleSignOn-Elements auf true fest. Weitere Informationen finden Sie in der Livedemo. Das UserJourneyBehaviors-Element sollte wie im folgenden Beispiel aussehen:

<UserJourneyBehaviors>
  <SingleSignOn Scope="Tenant" EnforceIdTokenHintOnLogout="true"/>
</UserJourneyBehaviors>

Gehen Sie wie folgt vor, um die Abmelde-URL Ihrer Anwendung zu konfigurieren:

  1. Wählen Sie App-Registrierungen aus, und wählen Sie dann Ihre Anwendung aus.
  2. Siehe Authentifizierung.
  3. Geben Sie im Textfeld Abmelde-URL den Umleitungs-URI nach der Abmeldung ein, und wählen Sie dann Speichern aus.

Nächste Schritte