Share via

Definindo corretamente a expiração de token de logon para usuários de declarações SAML do SharePoint 2010

  • Article

Definindo corretamente a expiração de token de logon para usuários de declarações SAML do SharePoint 2010

Recentemente, estava trabalhando para entender o processo de expiração de cookies de logon e encontrei o que parecia ser um problema bem grande. Para os usuários de declarações SAML, após a obtenção de seus cookies de logon do ADFS, eles aparentemente não têm tempo limite. Isso significa que o navegador poderia ser fechado e, vários minutos ou mesmo horas depois, eles poderiam reabrir o navegador e simplesmente navegar direto para o site, sem precisar de nova autenticação no ADFS. Além disso, os aplicativos clientes do Office 2010 funcionariam da mesma forma. Finalmente, descobri os vários aspectos que estavam causando isso e então os documentei aqui.

Primeiramente, um histórico bem rápido mesmo. Quando você navega pela primeira vez para um site do SharePoint que está protegido por declarações SAML, há um redirecionamento para que você se autentique e obtenha as declarações. O seu provedor de identidade SAML (conhecido como IP-STS) faz tudo isso e redireciona você de volta para o SharePoint. Quando você volta para o SharePoint, nós criamos um cookie FedAuth e é dessa forma que sabemos que você foi autenticado. Para melhorar ainda mais a experiência do usuário final, gravamos o valor do cookie FedAuth na pasta local de cookies. Nas solicitações subsequentes para esse site, se localizarmos um cookie FedAuth válido para o site, faremos a leitura do cookie e concederemos a você o direito ao conteúdo do SharePoint, sem que seja necessário repetir o processo de autenticação. Isso pode ser um tanto surpreendente para os usuários acostumados com o ADFS 1.x e o SharePoint 2007, porque, com esses sistemas, todos os cookies SSO da Web eram baseados na sessão e, portanto, não eram salvos em disco. Quando você fechava o navegador, por exemplo, o cookie sempre desaparecia, tornando necessária uma nova autenticação sempre que o navegador era fechado e aberto. Isso não acontece com o SharePoint 2010.

ATUALIZAÇÃO 1: encontramos uma alteração que pode ser feita no STS do SharePoint para que ele trabalhe novamente com cookies de sessão, tal como era feito no SharePoint 2007. Este PowerShell fará a alteração:

$sts = Get-SPSecurityTokenServiceConfig
$sts.UseSessionCookies = $true
$sts.Update()
iisreset

Depois de fazer isso, você verá que o cookie FedAuth não está mais gravado no disco. Para alterar e retomar o comportamento padrão, basta reverter as etapas:

$sts.UseSessionCookies = $false
$sts.Update()
iisreset

Sendo assim, como configuramos esse comportamento para obter um token SAML com um tempo de vida adequadamente gerenciável? Aqui estão alguns aspectos que você precisa examinar:

  1. A propriedade TokenLifetime pode ser definida por uma terceira parte confiável do ADFS. Infelizmente, parece que isso só pode ser definido no momento da criação da terceira parte confiável. Isso é um problema porque significa que o comportamento padrão é você obter um cookie com validade muito longa (não testei efetivamente para ver por quanto tempo o cookie é válido).

ATUALIZAÇÃO 2: Rich Harrison foi bom o bastante para oferecer essa grande descoberta de atualização do TokenLifetime no ADFS para a terceira parte confiável:

Set-ADFSRelyingPartyTrust -TargetName "SPS 2010 ADFS" -TokenLifetime 5

onde "SPS 2010 ADFS" é o nome da entidade Confiança de Terceira Parte Confiável no AD FS 2.0.

Portanto, se quiser definir o TokenLifetime da terceira parte confiável no ADFS, no momento da criação, você precisará fazer isso usando o PowerShell. Aqui está o pequeno script de uma linha que usei para criar minha terceira parte confiável:

Add-ADFSRelyingPartyTrust -Name "FC1" -Identifier "https://fc1/_trust/" -WsFedEndpoint "https://fc1/_trust/" -TokenLifetime 2 -SignatureAlgorithm https://www.w3.org/2000/09/xmldsig#rsa-sha1

Depois de criar a terceira parte confiável dessa maneira, você precisará fazer o seguinte manualmente:

  1. Adicionar o realm à lista de identidades (por exemplo, urn:sharepoint:foo)
  2. Adicionar uma regra de autorização de emissão para permitir o acesso a todos os usuários
  3. Adicionar uma regra de transformação de problema a ser enviada para endereços de email e funções

 

  1. Se você apenas tentar e fizer logon agora, provavelmente notará que, após a autenticação no ADFS, você ficará preso nesse loop interminável de ida e volta entre o SharePoint e o ADFS. Se examinar o tráfego no Fiddler, perceberá que: você obtém êxito ao se autenticar no ADFS; volta para o SharePoint que, por sua vez, emite com êxito o cookie FedAuth; esse cookie redireciona você para /_trust/authenticate.aspx no site do SharePoint, o que limpa o cookie FedAuth e redireciona você para o site do ADFS. Basicamente, você faz um pingue-pongue de ida e volta até que o ADFS pare e emita uma mensagem de erro nas linhas de “A mesma sessão de navegador cliente fez ‘6’ solicitações nos últimos ‘12’ segundos”. O resultado faz realmente sentido. Isso porque o LogonTokenCacheExpirationWindow padrão do STS do SharePoint é de 10 minutos. Nesse caso, quando criei minha terceira parte confiável, eu determinei que o tempo de vida do token no ADFS seria de 2 minutos, portanto, assim que ocorreu a autenticação, o programa soube que o cookie era válido por menos tempo do que o estipulado no valor de LogonTokenCacheExpirationWindow. Por isso, ele voltou ao ADFS para autenticar novamente. E assim continuou, indo e voltando. Para corrigir essa parte, basta alterar o LogonTokenCacheExpirationWindow, tornando-o menor do que o TokenLifetime de SAML. Depois disso, você poderá fazer logon no site. Aqui está um exemplo de definição do LogonTokenCacheExpirationWindow no SharePoint:

$sts = Get-SPSecurityTokenServiceConfig

$sts.LogonTokenCacheExpirationWindow = (New-TimeSpan –minutes 1)

$sts.Update()

Iisreset

 

Agora, após a configuração correta dessas definições, a expiração do logon para usuários SAML funcionará adequadamente. Posso abrir e fechar minha janela do navegador e continuar para voltar ao site, e durante 2 minutos, não serei redirecionado ao SharePoint. Após esse tempo, porém, o processo corretamente fará com que eu precise me autenticar novamente no ADFS.

Esta é uma postagem traduzida. Consulte o artigo original Setting the Login Token Expiration Correctly for SharePoint 2010 SAML Claims Users