Configurar o comportamento da sessão no Azure Active Directory B2C

• Criar um fluxo do usuário para que os usuários podem se registrar e entrar no seu aplicativo.
• Registrar um aplicativo Web.

• Conclua as etapas em Introdução às políticas personalizadas no Active Directory B2C
• Registrar um aplicativo Web.

Configurar o fluxo do usuário

Para configurar o comportamento da sessão no seu fluxo de usuário, siga estas etapas:

1. Entre no portal do Azure.
2. Se você tiver acesso a vários locatários, selecione o ícone Configurações no menu superior para alternar para o seu locatário do Azure Active Directory B2C no menu Diretórios + assinaturas.
3. Escolha Todos os serviços no canto superior esquerdo do Portal do Azure, pesquise Azure AD B2C e selecione-o.
4. Escolha Fluxos de usuário.
5. Abra o fluxo de usuários criado anteriormente.
6. Selecione Propriedades.
7. Configure o tempo de vida da sessão do aplicativo web (minutos) , o tempo limite da sessão do aplicativo web, a configuração de logon únicoe exigir o token de ID em solicitações de logout, conforme necessário.
8. Clique em Salvar.

Configurar uma política personalizada

Para configurar o comportamento da sessão na sua política personalizada, siga estas etapas:

1. Abra o arquivo RP (terceira parte confiável), por exemplo, SignUpOrSignin.xml

2. Se ele ainda não existir, adicione o elemento <UserJourneyBehaviors> a seguir ao elemento <RelyingParty>. Ele precisa estar localizado imediatamente após o <DefaultUserJourney ReferenceId="UserJourney Id"/>.

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

   Depois de adicionar os elementos de comportamento do percurso do usuário, o elemento RelyingParty deve ser semelhante ao seguinte exemplo:

   <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. Altere o valor do atributo Scope para um dos possíveis valores: Suppressed, Tenant, Application ou Policy. Para obter mais informações, confira o artigo de referência do RelyingParty.

4. Defina o elemento SessionExpiryType como Rolling ou Absolute. Para obter mais informações, confira o artigo de referência do RelyingParty.

5. Defina o elemento SessionExpiryInSeconds como um valor numérico entre 900 segundos (15 minutos) e 86.400 segundos (24 horas). Para obter mais informações, confira o artigo de referência do RelyingParty.

A KMSI é configurável no nível de fluxo de usuário individual. Antes de habilitar a KMSI para seus fluxos de usuário, considere o seguinte:

• A KMSI é suportada apenas as versões recomendadas de entrada e inscrição (SUSI), entrada e fluxos de usuário de edição de perfil. Se, no momento, você tiver as versões Padrão (Herdado) ou Herdado de visualização - v2 desses fluxos de usuário e quiser habilitar a KMSI, precisará criar novas versões Recomendado desses fluxos de usuário.
• Não há suporte para KMSI com fluxos de usuário de inscrição ou redefinição de senha.
• Se você quiser habilitar a KMSI para todos os aplicativos em seu locatário, recomendamos que você habilite a KMSI para todos os fluxos de usuário em seu locatário. Como um usuário pode ser apresentado a várias políticas durante uma sessão, é possível que eles encontrem um que não tenha a KMSI habilitada, o que removeria o cookie KMSI da sessão.
• A KMSI não deve ser habilitada em computadores públicos.

Configurar a KMSI para um fluxo de usuário

Para habilitar a KMSI para o seu fluxo de usuário:

1. Entre no portal do Azure.

2. Se você tiver acesso a vários locatários, selecione o ícone Configurações no menu superior para alternar para o seu locatário do Azure Active Directory B2C no menu Diretórios + assinaturas.

3. Escolha Todos os serviços no canto superior esquerdo do Portal do Azure, pesquise Azure AD B2C e selecione-o.

4. Selecione Fluxos de usuários (políticas) .

5. Abra o fluxo de usuários criado anteriormente.

6. Selecione Propriedades.

7. EmComportamento da sessão, selecione Habilitar manter-me conectado na sessão. Ao lado de Manter-me conectado na sessão (dias) , insira um valor de 1 a 90 para especificar o número de dias que uma sessão pode permanecer aberta.

   

Os usuários não devem habilitar essa opção em computadores públicos.

Configurar o identificador de página

Para habilitar a KMSI, defina o elemento de definição de conteúdo DataUri para oidentificador da páginaunifiedssp e a versão da página1.1.0 ou superior.

1. Abra o arquivo de extensão da sua política. Por exemplo, SocialAndLocalAccounts/TrustFrameworkExtensions.xml. Esse arquivo de extensão é um dos arquivos de política incluídos no pacote de início de política personalizada, que você deve ter obtido no pré-requisito, Introdução às políticas personalizadas.

2. Pesquise o elemento BuildingBlocks. Se o elemento não existir, adicione-o.

3. Adicione o elemento ContentDefinitions ao elemento BuildingBlocksda política.

   Sua política personalizada deverá ter o seguinte snippet de código:

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

Adicionar os metadados ao perfil técnico autodeclarado

Para adicionar a caixa de seleção KMSI à página de inscrição e entrada, defina os setting.enableRememberMe metadados como true. Substitua os perfis técnicos de SelfAsserted-LocalAccountSignin-Email no arquivo de extensão.

1. Localize o elemento ClaimsProviders. Se o elemento não existir, adicione-o.

2. Adicione os seguintes provedores de declarações ao elemento ClaimsProviders:

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

3. Salve o arquivo de extensões.

Criar um arquivo de terceira parte confiável

Atualize o arquivo de RP (terceira parte confiável) que iniciará o percurso do usuário que você criou. O parâmetro keepAliveInDays permite que você configure o quanto o cookie de sessão KMSI (Manter-me conectado) deve persistir. Por exemplo, se você definir o valor para 30, o cookie de sessão KMSI persistirá por 30 dias. O intervalo para o valor é de 1 a 90 dias. A definição do valor como 0 desliga a funcionalidade KMSI.

1. Abra o arquivo de política personalizada. Por exemplo, SignUpOrSignin.xml.

2. Se ele ainda não existir, adicione um nó filho <UserJourneyBehaviors> ao nó <RelyingParty>. Ele deve estar localizado imediatamente após <DefaultUserJourney ReferenceId="User journey Id" />, por exemplo: <DefaultUserJourney ReferenceId="SignUpOrSignIn" />.

3. Adicione o seguinte nó como um filho do elemento <UserJourneyBehaviors>.

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

Você define KeepAliveInDays e SessionExpiryInSeconds para que, durante uma conexão, se um usuário habilitar o KMSI, o KeepAliveInDays seja usado para definir os cookies, caso contrário, o valor especificado no parâmetro SessionExpiryInSeconds será usado. É recomendável que você defina o valor de SessionExpiryInSeconds para um período curto (1200 segundos), enquanto o valor de KeepAliveInDays pode ser definido como um período relativamente longo (30 dias), conforme mostrado no exemplo a seguir:

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

1. Invalida a sessão baseada em cookies do Azure AD B2C.
2. Tenta se desconectar de provedores de identidade federados.

1. Invalida a sessão baseada em cookies do Azure AD B2C.
2. Tenta sair de provedores de identidade federada:
   • OpenId Connect – se o ponto de extremidade de configuração bem conhecido do provedor de identidade especificar um end_session_endpoint local. A solicitação de saída não passa o id_token_hint parâmetro. Se o provedor de identidade federada exigir esse parâmetro, a solicitação de saída falhará.
   • OAuth2 – se os metadados do provedor de identidade contiverem o end_session_endpoint local.
   • SAML - se os metadados do provedor de identidade contiverem o SingleLogoutService local.
3. De forma opcional, desconecta-se dos outros aplicativos. Para obter mais informações, consulte a seção de saída única.

Logout único

Ao redirecionar o usuário para o ponto de extremidade de saída do Azure AD B2C (para o OAuth2 e o OpenID Connect) ou enviar um LogoutRequest (para o SAML), o Azure AD B2C limpa a sessão do usuário no navegador. No entanto, o usuário pode ainda entrar em outros aplicativos que usam o Azure AD B2C para autenticação. Para desconectar o usuário de todos os aplicativos que têm uma sessão ativa, o Azure AD B2C oferece suporte à desconexão única, também conhecida como SLO (Single Log-out).

Durante a desconexão, o Azure AD B2C envia simultaneamente uma solicitação HTTP para a URL de logoff registrada de todos os aplicativos nos quais o usuário está conectado no momento.

Configurar sua política personalizada

Para dar suporte ao logout único, os perfis técnicos do emissor do token para JWT e SAML devem especificar:

• O nome do protocolo, como <Protocol Name="OpenIdConnect" />
• A referência ao perfil técnico da sessão, como UseTechnicalProfileForSessionManagement ReferenceId="SM-jwt-issuer" />.

O exemplo a seguir mostra os emissores JWT e token SAML com logout único:

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

Configurar seu aplicativo

Para que um aplicativo participe da desconexão única:

• Para provedores de serviços SAML, configure o aplicativo com o local SingleLogoutService no documento de metadados SAML dele. Você também pode configurar o registro do aplicativo logoutUrl. Para saber mais, confira configurar a URL de logoff.
• Para aplicativos OpenID Connect ou OAuth2, defina o atributo logoutUrl do manifesto de registro do aplicativo. Para configurar a URL de logoff:
  1. No menu do Azure AD B2C, selecione Registros de aplicativos.
  2. Selecione o registro do seu aplicativo.
  3. Em Gerenciar, selecione Autenticação.
  4. Na URL de logoff do canal frontal, configure a URL de logoff.

Como lidar com solicitações de desconexão única

Quando o Azure AD B2C recebe a solicitação de logoff, ele usa um iframe HTML de canal frontal para enviar uma solicitação HTTP à URL de logoff registrada de cada aplicativo participante no qual o usuário está conectado no momento. Observe que o aplicativo que dispara a solicitação de logoff não recebe essa mensagem de logoff. Seus aplicativos devem responder à solicitação de desconexão limpando a sessão do aplicativo que identifica o usuário.

• Para aplicativos OpenID Connect e OAuth2, o Azure AD B2C envia uma solicitação HTTP GET para a URL de logoff registrada.
• Para aplicativos SAML, o Azure AD B2C envia uma solicitação de logoff SAML para a URL de logoff registrada.

Quando o Azure AD B2C notifica todos os aplicativos sobre a saída, ele continua fazendo o seguinte:

• Para os aplicativos OpenID Connect ou OAuth2, o usuário é redirecionado para o post_logout_redirect_uri solicitado, incluindo o parâmetro state (opcional) especificado na solicitação inicial. Por exemplo, https://contoso.com/logout?state=foo.
• Para os aplicativos SAML, uma resposta de logoff SAML é enviada via HTTP POST ao aplicativo que enviou inicialmente a solicitação de logoff.

Para exigir um token de ID em solicitações de logout:

1. Entre no portal do Azure.
2. Se você tiver acesso a vários locatários, selecione o ícone Configurações no menu superior para alternar para o seu locatário do Azure Active Directory B2C no menu Diretórios + assinaturas.
3. Escolha Todos os serviços no canto superior esquerdo do Portal do Azure, pesquise Azure AD B2C e selecione-o.
4. Escolha Fluxos de usuário.
5. Abra o fluxo de usuários criado anteriormente.
6. Selecione Propriedades.
7. Habilitar a exigência de token de ID em solicitações de logout.

Para exigir um token de ID em solicitações de logout, adicione um elemento UserJourneyBehaviors dentro do elemento RelyingParty. Em seguida, defina EnforceIdTokenHintOnLogout do elemento SingleSignOn como true. Para obter mais informações, confira a Demonstração ao vivo. O seu elemento UserJourneyBehavors deve ficar parecido com este exemplo:

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