CODEWITHSUNDEEP
securitysharepointsaml
nachonachoman
nachonachoman

Reputation: 852

SharePoint and SAML: Is there any guard against a replay attacks?

SharePoint uses SAML 1.1 as a protocol for federated authentication. A user will log in to a trusted identity provider and a SAML token is posted to the SharePoint site as a means of logging in to SharePoint.

I was surprised to find that the lifetime of the SAML token ties directly to the user's session. By default this seems to be 10 hours, which seems generous.

If I issue a SAML token to SharePoint what guard is there against replay attacks? It seems this token post is replayable for the lifetime of the user session. I would have expected the token lifetime to be long enough to authenticate. Is there something I am missing or is this a security hole?

Upvotes: 2

Views: 1607

Answers (1)

woloski
woloski

Reputation: 2873

The session lifetime in SharePoint will not be equals to the SAML token lifetime, but to the SAML Token ValidTo property (i.e. an absolute datetime), so the replay will work till that absolute time.

But there is more than that, SharePoint also relies on an internal property (defaults to 10 minutes) called LogonTokenCacheExpirationWindow. In my opinion, it brings more confusion than what value, but it's there and you have to understand that the validity of the session will depend on that

In pseudo code this is what happens inside SharePoint

SessionToken Lifetime = SAML Token Lifetime (by default)
if (SessionToken Lifetime - LogonTokenCacheExpirationWindow < DateTime.UtcNow)
    Logout()

Here you have an illustration of that with LogonTokenExpirationWindow = 40 mins and SAML Token Lifetime 1hr.

The LogonTokenCacheExpirationWindow can be changed like this:

$sts = Get-SPSecurityTokenServiceConfig
$sts.LogonTokenCacheExpirationWindow = (New-TimeSpan -minutes 1)
$sts.Update()

The SAML token lifetime (in case you use ADFS) can be changed like this:

Set-ADFSRelyingPartyTrust -TargetName "My SP2010" -TokenLifetime 5

Finally, it is worth noting that SharePoint will issue persistent cookies by default. So when you close the browser and open it again, it will use that persistent cookie. You can change that by setting 

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

Upvotes: 3

Related Questions