SSO-Sitzungsanbieter in Azure Active Directory B2C

Im Artikel Konfigurieren des Sitzungsverhaltens in Azure Active Directory B2C wird die Sitzungsverwaltung für Ihre benutzerdefinierte Azure AD B2C-Richtlinie beschrieben. In diesem Artikel wird beschrieben, wie Sie das SSO-Verhalten (Single Sign-On, einmaliges Anmelden) jedes einzelnen technischen Profils innerhalb Ihrer benutzerdefinierten Richtlinie genauer konfigurieren können.

Angenommen, Sie konfigurieren Ihre Richtlinie für ein mandantenweites SSO, möchten aber unabhängig von einer aktiven SSO-Sitzung immer den Multi-Faktor-Schritt ausführen. Sie können dieses Verhalten erreichen, indem Sie den Sitzungsanbieter des technischen Multi-Faktor-Profils konfigurieren.

Sie können Sitzungsanbieter auf zwei Flows anwenden:

• Neue Anmeldung
  • Wenn sich der Benutzer zum ersten Mal anmeldet, liegt keine Sitzung vor. Alle technischen Profile, die einen Sitzungsanbieter verwenden, werden zu Sitzungsteilnehmern.
  • Der Sitzungsanbieter kann Ansprüche in das Sitzungscookie schreiben.
• Nachfolgende Anmeldungen
  • Wenn der Benutzer über eine aktive Sitzung verfügt, werden Ansprüche, die Teil des Sitzungscookies sind, in den Anspruchsbehälter eingelesen.
  • Ansprüche, die Teil des Sitzungscookies sind, können nicht aktualisiert werden.
  • Der Sitzungsanbieter kann durch das Hinzufügen zusätzlicher Ansprüche in den Anspruchsbehälter angeben, dass dieses technische Profil unter SSO-Bedingungen ausgeführt wurde.
  • Das technische Profil kann übersprungen werden.

Abhängig davon, welcher Sitzungsverwaltungsanbieter für ein bestimmtes technisches Profil ausgewählt wurde, kann das Sitzungsverhalten aktiv sein oder unterdrückt werden. Die folgende Liste enthält einige der vielen möglichen Beispiele für die Verwendung von Sitzungsanbietern:

• Verhindern oder Erzwingen von Unterbrechungen der Benutzeroberfläche bei nachfolgenden Anmeldungen (SSO)
• Speichern des ausgewählten Identitätsanbieters für nachfolgende Anmeldungen (SSO)
• Verringern der Anzahl von Lesevorgängen im Verzeichnis bei nachfolgenden Anmeldungen (SSO)
• Nachverfolgen der Social Media-Identitätsanbietersitzungen, um sich vom Identitätsanbieter abzumelden
• Nachverfolgen angemeldeter Anwendungen der vertrauenden Seite für einmaliges Abmelden

Sitzungsanbieter

Es stehen fünf Sitzungsanbieter zur Verfügung, um die Handhabung der SSO-Sitzung durch ein technisches Profil zu verwalten. Beim Konfigurieren Ihres technischen Profils müssen Sie den am besten geeigneten Sitzungsanbieter auswählen.

Die folgende Tabelle zeigt, welcher Sitzungsanbieter je nach Typ des zu verwaltenden technischen Profils verwendet werden sollte. Einige Sitzungsanbieter gestatten das Lesen und Schreiben von Ansprüchen im Sitzungscookie.

Das folgende Diagramm zeigt die Sitzungstypen, die von Azure AD B2C verwendet werden.

Referenzieren eines Sitzungsanbieters

So verwenden Sie einen Sitzungsanbieter in Ihrem technischen Profil

1. Erstellen Sie ein geeignetes technisches Profil für die Sitzungsverwaltung. Hinweis: Das Azure AD B2C Starter Pack umfasst die gängigsten technischen Profile für die Sitzungsverwaltung. Sie können gegebenenfalls auf ein vorhandenes technisches Profil für die Sitzungsverwaltung verweisen.

   Der folgende XML-Ausschnitt zeigt das im Starter Pack enthaltene technische Profil SM-AAD für die Sitzungsverwaltung. Der Sitzungsanbieter weist den Typ DefaultSSOSessionProvider auf.

   <TechnicalProfile Id="SM-AAD">
     <DisplayName>Session Mananagement Provider</DisplayName>
     <Protocol Name="Proprietary" Handler="Web.TPEngine.SSO.DefaultSSOSessionProvider, Web.TPEngine, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" />
     <PersistedClaims>
       <PersistedClaim ClaimTypeReferenceId="objectId" />
       <PersistedClaim ClaimTypeReferenceId="signInName" />
       <PersistedClaim ClaimTypeReferenceId="authenticationSource" />
       <PersistedClaim ClaimTypeReferenceId="identityProvider" />
       <PersistedClaim ClaimTypeReferenceId="newUser" />
       <PersistedClaim ClaimTypeReferenceId="executed-SelfAsserted-Input" />
     </PersistedClaims>
     <OutputClaims>
       <OutputClaim ClaimTypeReferenceId="objectIdFromSession" DefaultValue="true" />
     </OutputClaims>
   </TechnicalProfile>
   

2. Verweisen Sie innerhalb Ihres technischen Profils auf das technische Profil für die Sitzungsverwaltung. Dadurch steuern Sie das Verhalten dieses technischen Profils bei nachfolgenden Anmeldungen (SSO).

   Um aus Ihrem technischen Profil auf ein technisches Profil für die Sitzungsverwaltung zu verweisen, fügen Sie das Element UseTechnicalProfileForSessionManagement hinzu. Das folgende Beispiel zeigt die Verwendung des technischen Profils SM-AAD für die Sitzungsverwaltung. Ändern Sie ReferenceId in die ID Ihres technischen Profils für die Sitzungsverwaltung.

   <TechnicalProfile Id="{Technical-profile-ID}">
     ...
     <UseTechnicalProfileForSessionManagement ReferenceId="SM-AAD" />
   </TechnicalProfile>
   

Verwalten von Sitzungsansprüchen

Die technischen Profile für die Sitzungsverwaltung steuern, welche Ansprüche während der Ausführung benutzerdefinierter Richtlinien gelesen, geschrieben oder ausgegeben werden können.

Verwenden Sie innerhalb des technischen Profils für die Sitzungsverwaltung die Elemente PersistedClaims und OutputClaims, um die Ansprüche zu verwalten.

• Persistierte Ansprüche: Ansprüche, die in das Sitzungscookie geschrieben werden können.
  • Damit ein Anspruch in das Sitzungscookie geschrieben werden kann, muss er im aktuellen Anspruchsbehälter enthalten sein.
  • Alle in das Cookie geschriebenen Ansprüche werden bei nachfolgenden Anmeldungen automatisch zurückgegeben (SSO). Sie müssen die Ausgabeansprüche nicht angeben.
• Ausgabeansprüche: Zusätzliche Ansprüche, die bei nachfolgenden Anmeldungen an den Anspruchsbehälter ausgegeben werden können (SSO). Da die Ausgabeansprüche nicht von der Sitzung zurückgegeben werden, müssen Sie einen Standardwert festlegen.

Die Elemente für persistierte und ausgegebene Ansprüche werden im folgenden XML-Ausschnitt dargestellt:

<TechnicalProfile Id="SM-AAD">
  <DisplayName>Session Management Provider</DisplayName>
  <Protocol Name="Proprietary" Handler="Web.TPEngine.SSO.DefaultSSOSessionProvider, Web.TPEngine, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" />
  <PersistedClaims>
    <PersistedClaim ClaimTypeReferenceId="objectId" />
  </PersistedClaims>
  <OutputClaims>
    <OutputClaim ClaimTypeReferenceId="objectIdFromSession" DefaultValue="true"/>
  </OutputClaims>
</TechnicalProfile>

Die Sitzungsverwaltungsanbieter DefaultSSOSessionProvider und ExternalLoginSSOSessionProvider können für die Verwaltung von Ansprüchen konfiguriert werden, um Folgendes zu erreichen:

• Neue Anmeldung
  • Das PersistedClaims-Element schreibt Ansprüche in das Sitzungscookie. Persistierte Ansprüche können nicht umgeschrieben werden.
• Nachfolgende Anmeldungen
  • Jeder in das Sitzungscookie geschriebene Anspruch wird an den Anspruchsbehälter ausgegeben und kann im nächsten Orchestrierungsschritt verwendet werden.
  • Das OutputClaims-Element gibt statische Ansprüche an den Anspruchsbehälter aus. Verwenden Sie das DefaultValue-Attribut, um den Wert des Ausgabeanspruchs zu festlegen.

DefaultSSOSessionProvider

Der Sitzungsanbieter DefaultSSOSessionProvider kann so konfiguriert werden, dass er Ansprüche bei nachfolgenden Anmeldungen (SSO) verwaltet und das Überspringen von technischen Profilen ermöglicht. DefaultSSOSessionProvider sollte verwendet werden, um Ansprüche zu persistieren und auszugeben, die für nachfolgende Orchestrierungsschritten erforderlich sind und andernfalls bei nachfolgenden Anmeldungen nicht abgerufen werden können (SSO). Ein Beispiel sind Ansprüche, die beim Lesen des Benutzerobjekts im Verzeichnis abgerufen werden können.

Das folgende technische Profil SM-AAD verwendet einen Sitzungsanbieter vom Typ DefaultSSOSessionProvider. Das technische Profil SM-AAD ist im Starter Pack für benutzerdefinierte Richtlinien enthalten.

<TechnicalProfile Id="SM-AAD">
  <DisplayName>Session Management Provider</DisplayName>
  <Protocol Name="Proprietary" Handler="Web.TPEngine.SSO.DefaultSSOSessionProvider, Web.TPEngine, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" />
  <PersistedClaims>
    <PersistedClaim ClaimTypeReferenceId="objectId" />
    <PersistedClaim ClaimTypeReferenceId="signInName" />
    <PersistedClaim ClaimTypeReferenceId="authenticationSource" />
    <PersistedClaim ClaimTypeReferenceId="identityProvider" />
    <PersistedClaim ClaimTypeReferenceId="newUser" />
    <PersistedClaim ClaimTypeReferenceId="executed-SelfAsserted-Input" />
  </PersistedClaims>
  <OutputClaims>
    <OutputClaim ClaimTypeReferenceId="objectIdFromSession" DefaultValue="true"/>
  </OutputClaims>
</TechnicalProfile>

Beispielsweise verwendet das technische Profil SM-AAD für die Sitzungsverwaltung den Sitzungsanbieter DefaultSSOSessionProvider. Bei Anwendung auf das technische Profil SelfAsserted-LocalAccountSignin-Email aus dem Starter Pack für benutzerdefinierte Richtlinien ergibt sich folgendes Verhalten:

• Neue Anmeldung
  • signInName wird in das Sitzungscookie geschrieben, da das technische Profil für die Sitzungsverwaltung (SM-AAD) zum Persistieren von signInName konfiguriert ist und das technische Profil, das auf SM-AAD verweist, einen OutputClaim für signInName enthält. Dieses Verhalten gilt für alle Ansprüche, die diesem Muster entsprechen.
• Nachfolgende Anmeldungen
  • Das technische Profil wird übersprungen, und dem Benutzer wird die Anmeldeseite nicht angezeigt.
  • Der Anspruchsbehälter enthält den signInName-Wert aus dem Sitzungscookie, der bei der neuen Anmeldung persistiert wurde, sowie alle weiteren Ansprüche, die dem Muster zur Persistierung im Sitzungscookie entsprechen.
  • Das technische Profil für die Sitzungsverwaltung gibt den objectIdFromSession-Anspruch zurück, weil Output-Ansprüche des Sitzungsanbieters bei nachfolgenden Anmeldungen verarbeitet werden (SSO). In diesem Fall weist der im Anspruchsbehälter vorhandene objectIdFromSession-Anspruch darauf hin, dass die Ansprüche des Benutzers aufgrund der einmaligen Anmeldung aus dem Sitzungscookie stammen.

ExternalLoginSSOSessionProvider

Der Sitzungsanbieter ExternalLoginSSOSessionProvider wird verwendet, um den Bildschirm zur Auswahl des Identitätsanbieters zu überspringen und sich von einem Verbundidentitätsanbieter abzumelden. Er wird in der Regel in einem technischen Profil referenziert, das für einen Verbundidentitätsanbieter wie Facebook oder Microsoft Entra ID konfiguriert ist.

• Neue Anmeldung
  • Das PersistedClaims-Element schreibt Ansprüche in das Sitzungscookie. Persistierte Ansprüche können nicht umgeschrieben werden.
• Nachfolgende Anmeldungen
  • Jeder in das Sitzungscookie geschriebene Anspruch wird an den Anspruchsbehälter ausgegeben und kann im nächsten Orchestrierungsschritt verwendet werden.
  • Das OutputClaims-Element gibt statische Ansprüche an den Anspruchsbehälter aus. Verwenden Sie das DefaultValue-Attribut, um den Wert des Anspruchs festzulegen.
  • Wenn ein technisches Profil, das auf ein technisches Profil für die Sitzungsverwaltung verweist, einen im Sitzungscookie gespeicherten OutputClaim enthält, wird dieses technische Profil übersprungen.

Das folgende technische Profil SM-SocialLogin verwendet einen Sitzungsanbieter vom Typ ExternalLoginSSOSessionProvider. Das technische Profil SM-SocialLogin ist im Starter Pack für benutzerdefinierte Richtlinien enthalten.

<TechnicalProfile Id="SM-SocialLogin">
  <DisplayName>Session Management Provider</DisplayName>
  <Protocol Name="Proprietary" Handler="Web.TPEngine.SSO.ExternalLoginSSOSessionProvider, Web.TPEngine, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" />
  <PersistedClaims>
    <PersistedClaim ClaimTypeReferenceId="AlternativeSecurityId" />
  </PersistedClaims>
</TechnicalProfile>

Der Anspruch AlternativeSecurityId wird generiert, wenn sich ein Benutzer bei einem externen Identitätsanbieter anmeldet. Er repräsentiert den eindeutigen Bezeichner für den Benutzer des externen Identitätsanbieters. Der AlternativeSecurityId-Anspruch wird persistiert, sodass bei Verwendung des einmaligen Anmeldens das Profil des Benutzers aus dem Verzeichnis gelesen werden kann, ohne dass eine Interaktion mit dem Verbundidentitätsanbieter erforderlich ist.

Um den externen Sitzungsanbieter zu konfigurieren, fügen Sie aus Ihren technischen OAuth1-, OAuth2- oder OpenID Connect-Profilen einen Verweis auf SM-SocialLogin hinzu. Beispielsweise verwendet Facebook-OAUTH das technische Profil SM-SocialLogin für die Sitzungsverwaltung. Weitere Informationen finden Sie unter Starter Pack für benutzerdefinierte Richtlinien.

<TechnicalProfile Id="Facebook-OAUTH">
  ...
  <UseTechnicalProfileForSessionManagement ReferenceId="SM-SocialLogin" />
</TechnicalProfile>

OAuthSSOSessionProvider

Der Sitzungsanbieter OAuthSSOSessionProvider wird zum Verwalten von Azure AD B2C-Sitzungen zwischen der vertrauenden OAuth2- oder OpenId Connect-Seite und Azure AD B2C verwendet. Azure AD B2C unterstützt einmaliges Abmelden, auch als Single Log-Out (SLO) bezeichnet. Wenn sich ein Benutzer über den Azure AD B2C-Abmeldungsendpunkt abmeldet, löscht Azure AD B2C das Sitzungscookie des Benutzers aus dem Browser. Allerdings kann der Benutzer weiterhin bei anderen Anwendungen angemeldet sein, die Azure AD B2C für die Authentifizierung verwenden.

Diese Art von Sitzungsanbieter ermöglicht es Azure AD B2C, alle OAuth2- oder OpenId Connect-Anwendungen nachzuverfolgen, bei denen sich der Benutzer angemeldet hat. Während der Abmeldung einer Anwendung versucht Azure AD B2C, die logout-Endpunkte aller weiteren bekannten angemeldeten Anwendungen aufzurufen. Diese Funktionalität ist in den Sitzungsanbieter integriert. Es sind keine persistierten Ansprüche oder Ausgabeansprüche verfügbar, die konfiguriert werden können. Das folgende technische Profil SM-jwt-issuer verwendet einen Sitzungsanbieter vom Typ OAuthSSOSessionProvider.

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

Auf das technische Profil SM-jwt-issuer wird im technischen Profil JwtIssuer verwiesen:

<TechnicalProfile Id="JwtIssuer">
  ...
  <UseTechnicalProfileForSessionManagement ReferenceId="SM-jwt-issuer" />
</TechnicalProfile>

SamlSSOSessionProvider

Der Sitzungsanbieter SamlSSOSessionProvider wird zum Verwalten des Sitzungsverhaltens mit SAML-Verbundidentitätsanbietern oder SAML-Anwendungen der vertrauenden Seite und Azure AD B2C verwendet.

Verwalten von SAML-Identitätsanbietersitzungen

Wenn Sie aus einer SAML-Identitätsanbietersitzung auf einen SamlSSOSessionProvider-Sitzungsanbieter verweisen, muss RegisterServiceProviders auf falsefestgelegt werden.

Das folgende technische Profil SM-Saml-idp verwendet einen Sitzungsanbieter vom Typ SamlSSOSessionProvider:

<TechnicalProfile Id="SM-Saml-idp">
  <DisplayName>Session Management Provider</DisplayName>
  <Protocol Name="Proprietary" Handler="Web.TPEngine.SSO.SamlSSOSessionProvider, Web.TPEngine, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" />
  <Metadata>
    <Item Key="RegisterServiceProviders">false</Item>
  </Metadata>
</TechnicalProfile>

Um das technische Profil SM-Saml-idp für die Sitzungsverwaltung zu verwenden, fügen Sie einen Verweis auf das technische Profil für Ihren SAML-Identitätsanbieter hinzu. Beispielsweise verwendet der AD-FS-SAML-Identitätsanbieter Contoso-SAML2 das technische Profil der SM-Saml-idp Sitzungsverwaltung.

<TechnicalProfile Id="Contoso-SAML2">
  ...
  <UseTechnicalProfileForSessionManagement ReferenceId="SM-Saml-idp" />
</TechnicalProfile>

Verwalten von SAML-Dienstanbietersitzungen

Wenn auf einen SamlSSOSessionProvider-Sitzungsanbieter verwiesen wird, um eine SAML-Sitzung der vertrauenden Seite zu verwalten, muss RegisterServiceProviders auf true festgelegt werden. Für die Abmeldung von SAML-Sitzungen sind SessionIndex und NameID erforderlich.

Das folgende technische Profil SM-Saml-issuer verwendet einen Sitzungsanbieter vom Typ SamlSSOSessionProvider:

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

Um das technische Profil SM-Saml-issuer für die Sitzungsverwaltung zu verwenden, fügen Sie einen Verweis auf das technische Profil für Ihren SAML-Tokenaussteller hinzu. Beispielsweise verwendet das technische Profil Saml2AssertionIssuer das Profil SM-Saml-issuer für die Sitzungsverwaltung.

<TechnicalProfile Id="Saml2AssertionIssuer">
  ...
  <UseTechnicalProfileForSessionManagement ReferenceId="SM-Saml-issuer" />
</TechnicalProfile>

Metadaten

NoopSSOSessionProvider

Der Sitzungsanbieter NoopSSOSessionProvider wird verwendet, um das SSO-Verhalten zu unterdrücken. Technische Profile mit diesem Sitzungsanbietertyp werden immer verarbeitet – selbst dann, wenn der Benutzer über eine aktive Sitzung verfügt. Dieser Typ von Sitzungsanbieter kann nützlich sein, um z. B. die ständige Ausführung bestimmter technischer Profile zu erzwingen:

• Anspruchstransformation: Zum Erstellen oder Transformieren von Ansprüchen, die später zur Bestimmung der zu verarbeitenden oder zu überspringenden Orchestrierungsschritte verwendet werden.
• RESTful – Abrufen aktualisierter Daten von einem RESTful-Dienst bei jeder Ausführung der Richtlinie. Sie können auch ein RESTful für die erweiterte Protokollierung und Überwachung aufrufen.
• Selbstbestätigt: Der Benutzer muss bei jeder Ausführung der Richtlinie Daten bereitstellen. Verifizieren Sie z. B. E-Mails mit einer Einmalkennung, oder holen Sie die Zustimmung des Benutzers ein.
• Phonefactor: Benutzer*innen müssen die Multi-Faktor-Authentifizierung als Bestandteil einer „Step-Up-Authentifizierung“ durchführen, auch bei nachfolgenden Anmeldungen (SSO).

Dieser Sitzungsanbietertyp persistiert keine Ansprüche im Sitzungscookie des Benutzers. Das folgende technische Profil SM-Noop verwendet einen Sitzungsanbieter vom Typ NoopSSOSessionProvider. Das technische Profil SM-Noop ist im Starter Pack für benutzerdefinierte Richtlinien enthalten.

<TechnicalProfile Id="SM-Noop">
  <DisplayName>Noop Session Management Provider</DisplayName>
  <Protocol Name="Proprietary" Handler="Web.TPEngine.SSO.NoopSSOSessionProvider, Web.TPEngine, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" />
</TechnicalProfile>

Um das SSO-Verhalten eines technischen Profils zu unterdrücken, fügen Sie einen Verweis auf das technische Profil SM-Noop hinzu. Beispielsweise verwendet AAD-Common das technische Profil SM-Noop für die Sitzungsverwaltung. Weitere Informationen finden Sie unter Starter Pack für benutzerdefinierte Richtlinien.

<TechnicalProfile Id="AAD-Common">
  ...
  <UseTechnicalProfileForSessionManagement ReferenceId="SM-Noop" />
</TechnicalProfile>

Nächste Schritte

Erfahren Sie, wie Sie das Sitzungsverhalten konfigurieren.