Fournisseurs de session d’authentification unique dans Azure Active Directory B2C

Dans l’article Configurer le comportement de session dans Azure Active Directory B2C, nous décrivons la gestion des sessions pour votre stratégie personnalisée Azure AD B2C. Cet article explique comment affiner la configuration du comportement de l’authentification unique (SSO) d’un profil technique individuel dans votre stratégie personnalisée.

Par exemple, vous configurez votre stratégie pour l’authentification unique à l’échelle du locataire, mais vous souhaitez toujours effectuer l’étape d’authentification multifacteur indépendamment d’une session d’authentification unique active. Vous pouvez obtenir ce comportement en configurant le fournisseur de session du profil technique multifacteur.

Vous pouvez appliquer les fournisseurs de session à deux flux :

• Nouvelle ouverture de session
  • Quand l’utilisateur se connecte pour la première fois, il n’y a pas de session. Tous les profils techniques qui utilisent un fournisseur de session deviennent un participant à la session.
  • Le fournisseur de session peut écrire des revendications dans le cookie de session.
• Ouvertures de session suivantes
  • Quand l’utilisateur a une session active, les revendications qui font partie du cookie de session sont lues dans le jeu de revendications.
  • Les revendications qui font partie du cookie de session ne peuvent pas être mises à jour.
  • Le fournisseur de session peut émettre des revendications supplémentaires dans le jeu de revendications, indiquant que ce profil technique a été exécuté dans des conditions SSO.
  • Le profil technique peut être ignoré.

Selon le fournisseur de gestion de sessions choisi pour un profil technique donné, le comportement de session peut être actif ou supprimé. La liste suivante présente quelques exemples possibles avec des fournisseurs de session :

• Empêcher ou appliquer des interruptions de l’interface utilisateur lors des ouvertures de session suivantes (SSO).
• Mémoriser le fournisseur d’identité choisi lors des ouvertures de session suivantes (SSO).
• Réduisez le nombre d’opérations de lecture dans le répertoire lors des ouvertures de session suivantes (SSO).
• Effectuez le suivi des sessions du fournisseur d’identité sociale pour effectuer la déconnexion du fournisseur d’identité.
• Effectuez le suivi des applications par partie de confiance connectées pour la déconnexion unique.

Fournisseurs de session

Cinq fournisseurs de session sont disponibles pour gérer la façon dont un profil technique gère la session d’authentification unique. Vous devez choisir le fournisseur qui convient le mieux lors de la configuration de votre profil technique.

Le tableau suivant indique quel fournisseur de session doit être utilisé en fonction du type de profil technique que vous souhaitez gérer. Certains fournisseurs de session autorisent la lecture et l’écriture des revendications dans le cookie de session.

Le diagramme suivant montre les types de session utilisés par Azure AD B2C.

Référencement d’un fournisseur de session

Pour utiliser un fournisseur de session dans votre profil technique :

1. Créez un profil technique de gestion des sessions du type approprié. Notez que le pack de démarrage Azure AD B2C comprend les profils techniques de gestion des sessions les plus courants. Vous pouvez faire référence à un profil technique de gestion des sessions existant, le cas échéant.

   L’extrait de code XML suivant montre le profil technique de gestion des sessions du pack de démarrage SM-AAD. Le fournisseur de session est de type DefaultSSOSessionProvider.

   <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. Référencez le profil technique de gestion des sessions au sein de votre profil technique. En procédant ainsi, vous contrôlez le comportement de ce profil technique lors des ouvertures de session suivantes (SSO).

   Pour référencer un profil technique de gestion des sessions à partir de votre profil technique, ajoutez l’élément UseTechnicalProfileForSessionManagement. L’exemple suivant illustre l’utilisation du profil technique de gestion des sessions SM-AAD. Modifiez l’élément ReferenceId en le remplaçant par l’ID de votre profil technique de gestion des sessions.

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

Gérer les revendications de session

Les profils techniques de gestion des sessions contrôlent les revendications qui peuvent être lues, écrites ou sorties pendant l’exécution de la stratégie personnalisée.

Dans le profil technique de gestion des sessions, utilisez les éléments PersistedClaims et OutputClaims pour gérer les revendications.

• Revendications persistantes : revendications qui peuvent être écrites dans le cookie de session.
  • Pour qu’une revendication soit écrite dans le cookie de session, elle doit faire partie du jeu de revendications actuel.
  • Toutes les revendications qui sont écrites sont retournées automatiquement lors des ouvertures de session suivantes (authentification unique). Vous n’avez pas besoin de spécifier les revendications de sortie.
• Revendications de sortie : revendications supplémentaires qui peuvent être envoyées au jeu de revendications lors des ouvertures de session suivantes (authentification unique). Étant donné que les revendications de sortie ne sont pas retournées à partir de la session, vous devez définir une valeur par défaut.

Les éléments de revendications persistantes et de sortie sont illustrés dans l’extrait de code XML suivant :

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

Les fournisseurs de gestion des sessions DefaultSSOSessionProvider et ExternalLoginSSOSessionProvider peuvent être configurés pour gérer les revendications, par exemple pendant :

• Nouvelle ouverture de session
  • L’élément PersistedClaims écrit des revendications dans le cookie de session. Les revendications persistantes ne peuvent pas être réécrites.
• Ouvertures de session suivantes
  • Chaque revendication écrite dans le cookie de session est générée dans le jeu de revendications et est disponible pour être utilisée lors de l’étape suivante de l’orchestration.
  • L’élément OutputClaims génère des revendications statiques dans le jeu de revendications. Utilisez l’attribut DefaultValue pour définir la valeur de la revendication de sortie.

DefaultSSOSessionProvider

Le fournisseur de session DefaultSSOSessionProvider peut être configuré pour gérer les revendications lors des ouvertures de session suivantes (authentification unique) et pour permettre d’ignorer des profils techniques. L’élément DefaultSSOSessionProvider doit être utilisé pour émettre et rendre persistantes les revendications qui sont nécessaires lors des étapes d’orchestration ultérieures et qui ne sont sinon pas obtenues lors des ouvertures de session suivantes (authentification unique). Par exemple, les revendications qui peuvent être obtenues à partir de la lecture de l’objet utilisateur du répertoire.

Le profil technique suivant SM-AAD est le type de fournisseur de session DefaultSSOSessionProvider. Le profil technique SM-AAD se trouve dans le pack de démarrage de stratégie personnalisée.

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

Par exemple, le profil technique de gestion des sessions SM-AAD utilise le fournisseur de session DefaultSSOSessionProvider. Il se comporte comme suit quand il est appliqué au profil technique SelfAsserted-LocalAccountSignin-Email à partir du pack de démarrage de stratégie personnalisée :

• Nouvelle ouverture de session
  • signInName est écrit dans le cookie de session, car le profil technique de gestion des sessions (SM-AAD) est configuré de telle manière que signInName soit persistant et le profil technique qui référence SM-AAD contient un OutputClaim pour signInName. Ce comportement s’applique à toutes les revendications qui répondent à ce modèle.
• Ouvertures de session suivantes
  • Le profil technique est ignoré et l’utilisateur ne voit pas la page de connexion.
  • Le jeu de revendications contient la valeur signInName du cookie de session, qui a été rendue persistante à la nouvelle connexion, et toutes les autres revendications qui remplissent le modèle à conserver dans le cookie de session.
  • Le profil technique de gestion des sessions retourne la revendication objectIdFromSession, car les revendications Output du fournisseur de session sont traitées lors des ouvertures de session suivantes (authentification unique). Dans ce cas, la revendication objectIdFromSession qui est présente dans le jeu de revendications indique que les revendications de l’utilisateur proviennent du cookie de session dû à l’authentification unique.

ExternalLoginSSOSessionProvider

Le fournisseur de session ExternalLoginSSOSessionProvider est utilisé pour ignorer l’écran « Sélection du fournisseur d’identité » et se déconnecter d’un fournisseur d’identité fédéré. La revendication est généralement référencée dans un profil technique configuré pour un fournisseur d’identité fédérée, comme Facebook ou Microsoft Entra ID.

• Nouvelle ouverture de session
  • L’élément PersistedClaims écrit des revendications dans le cookie de session. Les revendications persistantes ne peuvent pas être réécrites.
• Ouvertures de session suivantes
  • Chaque revendication écrite dans le cookie de session est générée dans le jeu de revendications et est disponible pour être utilisée lors de l’étape suivante de l’orchestration.
  • L’élément OutputClaims génère des revendications statiques dans le jeu de revendications. Utilisez l’attribut DefaultValue pour définir la valeur de la revendication.
  • Quand un profil technique faisant référence à un profil technique de gestion des sessions contient l’élément OutputClaim qui a été rendu persistant dans le cookie de session, ce profil technique est ignoré.

Le profil technique suivant SM-SocialLogin est le type de fournisseur de session ExternalLoginSSOSessionProvider. Le profil technique SM-SocialLogin se trouve dans le pack de démarrage de stratégie personnalisée.

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

La revendication AlternativeSecurityId est générée quand un utilisateur se connecte avec un fournisseur d’identité externe. Elle représente l’identificateur unique de l’utilisateur du fournisseur d’identité externe. La revendication AlternativeSecurityId est persistante de telle sorte que, sur les parcours d’authentification unique, le profil utilisateur peut être lu à partir du répertoire sans aucune interaction avec le fournisseur d’identité fédérée.

Pour configurer le fournisseur de session externe, ajoutez une référence à SM-SocialLogin à partir de vos profils techniques OAuth1, OAuth2 ou OpenID Connect. Par exemple, Facebook-OAUTH utilise le profil technique de gestion des sessions SM-SocialLogin. Pour plus d’informations, consultez le pack de démarrage de stratégie personnalisée.

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

OAuthSSOSessionProvider

Ce fournisseur de session OAuthSSOSessionProvider est utilisé pour gérer les sessions Azure AD B2C entre une partie de confiance OAuth2 ou OpenId Connect, et Azure AD B2C. Azure AD B2C prend en charge la déconnexion unique, également appelée SLO (Single Log Out). Quand un utilisateur se déconnecte via le point de terminaison de déconnexion Azure AD B2C, Azure AD B2C efface le cookie de session de l’utilisateur du navigateur. Toutefois, l’utilisateur pourrait rester connecté à d’autres applications utilisant Azure AD B2C pour l’authentification.

Ce type de fournisseur de session permet à Azure AD B2C de suivre toutes les applications OAuth2 ou OpenId Connecter auxquelles l’utilisateur s’est connecté. Lors de la déconnexion d’une application, Azure AD B2C tente d’appeler les points de terminaison logout de toutes les autres applications connectées connues. Cette fonctionnalité est intégrée au fournisseur de session. Aucune revendication persistante ou de sortie n’est disponible pour être configurée. Le profil technique suivant SM-jwt-issuer est le type de fournisseur de session 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>

Le profil technique SM-jwt-issuer est référencé à partir du profil technique JwtIssuer :

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

SamlSSOSessionProvider

Le fournisseur de session SamlSSOSessionProvider est utilisé pour gérer le comportement de session avec les fournisseurs d’identité SAML fédérée ou les applications par partie de confiance SAML et Azure AD B2C.

Gestion de sessions de fournisseur d’identité SAML

Quand vous référencez un fournisseur de session SamlSSOSessionProvider à partir d’une session de fournisseur d’identité SAML, RegisterServiceProviders doit avoir la valeur false.

Le profil technique suivant SM-Saml-idp est le type de fournisseur de session 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>

Pour utiliser le profil technique de gestion des sessions SM-Saml-idp, ajoutez une référence au profil technique du fournisseur d’identité SAML. Par exemple, le fournisseur Contoso-SAML2 d’identité SAML AD-FS utilise le profil technique de SM-Saml-idp gestion de session.

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

Gestion des sessions du fournisseur de services SAML

Lors du référencement d’un fournisseur de session SamlSSOSessionProvider pour gérer une session de partie de confiance SAML, RegisterServiceProviders doit avoir la valeur true. La déconnexion de session SAML requiert les valeurs SessionIndex et NameID pour pouvoir s’effectuer.

Le profil technique suivant SM-Saml-issuer est le type de fournisseur de session 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>

Pour utiliser le profil technique de gestion des sessions SM-Saml-issuer, ajoutez une référence au profil technique de l’émetteur de jeton SAML. Par exemple, le profil technique Saml2AssertionIssuer utilise le profil technique de gestion des sessions SM-Saml-issuer.

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

Métadonnées

NoopSSOSessionProvider

Le fournisseur de session NoopSSOSessionProvider est utilisé pour supprimer le comportement de l’authentification unique. Les profils techniques qui utilisent ce type de fournisseur de session sont toujours traités, même quand une session est active pour l’utilisateur. Ce type de fournisseur de session peut être utile pour forcer des profils techniques particuliers à toujours s’exécuter, par exemple :

• Transformation de revendications : pour créer ou transformer des revendications qui sont utilisées ultérieurement pour déterminer les étapes d’orchestration à traiter ou à ignorer.
• RESTful : récupérez les données mises à jour à partir d’un service RESTful chaque fois que la stratégie s’exécute. Vous pouvez également appeler un RESTful pour la journalisation étendue et l’audit.
• Autodéclaré : force l’utilisateur à fournir des données à chaque exécution de la stratégie. Par exemple, vérifiez les e-mails avec un code secret unique ou demandez le consentement de l’utilisateur.
• Phonefactor : force l’utilisateur à effectuer une authentification multifacteur dans le cadre d’une « authentification renforcée », même lors des ouvertures de session ultérieures (authentification unique).

Ce type de fournisseur de session ne rend pas les revendications persistantes dans le cookie de session de l’utilisateur. Le profil technique suivant SM-Noop est le type de fournisseur de session NoopSSOSessionProvider. Le profil technique SM-Noop se trouve dans le pack de démarrage de stratégie personnalisée.

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

Pour supprimer le comportement d’authentification unique d’un profil technique, ajoutez une référence à SM-Noop dans le profil technique. Par exemple, AAD-Common utilise le profil technique de gestion des sessions SM-Noop. Pour plus d’informations, consultez le pack de démarrage de stratégie personnalisée.

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

Étapes suivantes

Découvrez comment configurer un comportement de session.