SharePoint Session management
A user session in SharePoint
is the time in which a user is logged into SharePoint without needing to
re-authenticate. SharePoint, like most secure systems, implements limited
lifespan sessions – i.e. users may authentication with a SharePoint system, but
they’re not authenticated with the system indefinitely. The length of user
sessions falls under the control of session management, configured for each
SharePoint Web Application.
SharePoint 2013/ 2016
handles custom user session management using Sliding Session feature.
When SharePoint
authenticates a user, the Security Token Service creates a security token with
the user's identity and several other claims. This token is then added to the
Distributed Logon Token Cache so that it can be checked later to confirm that
the user is authenticated.
When built, the token gets a lifetime that depends on
the authentication provider used by the user to authenticate. For Windows and
Forms (FBA) authentication, the lifetime is a fixed amount of time that is set
on the Security Token Service configuration. For trusted providers like AD FS
or PING Fed, the lifetime depends on the validity of the security token POSTed
to SharePoint's /_trust/ endpoint.
This lifetime has a direct
impact in how often the user will need to authenticate. When the user makes a
request, the token in the cache is checked and if it is expired, then the user
needs to authenticate again.
The following is a summary
of the authentication process, shown in the sequence diagram.
1. A user requests a page in SharePoint from their browser this might be the
home page of the site.
2. SharePoint captures the request and determines that no valid session
exists, by the absence of the FEDAUTH cookie.
3. SharePoint redirects the user to the internal STS – this is important
because the internal STS handles all authentication requests for SharePoint.
4. Since we have configured SharePoint to use external trusted login
provider, the internal STS redirects the user to the IP (identity provider)
login page.
5. IP acquires credentials and authenticates the user.
6. IP creates a SAML token, containing the user’s claims, as encrypted and
signed.
7. IP posts the SAML token to the internal SharePoint STS.
8. The Internal STS saves the SAML token in the SAML Token Cache.
9. SharePoint creates the FEDAUTH cookie, which contains a reference to the
SAML token in the cache.
10. The Internal STS redirects the user back to SharePoint, and then back to
the original requested page.
Session Lifetime
The lifetime of a SharePoint
session, when using Identity Provider (ADFS or PING Fed), is the topic of much
confusion. Ultimately, SharePoint determines whether a user has a current
session by the presence of the FEDAUTH cookie. The default behaviour of
SharePoint is to store this persistent cookie on the user’s disk, with fixed
expiration date. Before sending a new FEDAUTH cookie back to the user’s
browser, SharePoint calculates the expiration of the cookie with the following
formula:
SAML Token Lifetime – Logon Token Cache Expiration
Window
SAML Token Lifetime: This
value, in minutes, is provided by the token issuer (IP – ADFS, PING). By
default, SharePoint sets the session lifetime the same as this SAML token
lifetime.
Logon Token Cache Expiration Window: This
value, in minutes, is provided by SharePoint STS and governs how long the SAML
token remains active in the cache, and therefore how long the associated user
session remains alive. For example, if IP sets the SAML Token Lifetime to 10
minutes and this value is set in the STS as 2 minutes then the overall
SharePoint session lifespan is 8 minutes.
Sliding Session
A siding session is one
where the session expiration time changes as a user interacts with the system.
Each new session expires on a fixed time, based on the aforementioned formula
(SAML
Token Lifetime – Logon Token Cache Expiration Window)
Use of a sliding session
does not mean that we must compromise security. Should a user become inactive,
a sliding session will timeout just as the fixed session, the main difference
that a user can extend a sliding session with continued use of the SharePoint
system.
Creation of sliding session
requires configuration of the Relying Party in Identity provider and the
SharePoint Logon Token Cache Expiration.
Persistent verses Session Cookies
By default, SharePoint
stores the authentication/session (FEDAUTH) cookie as a persistent cookie on
disk. This allows the user to close and reopen their browser and access
SharePoint without having to re-authenticate.
Fortunately, we can ask
SharePoint to use in-memory cookies (session cookies) for the authentication
(FEDAUTH) cookie, as follows:
Sliding Session Configuration
Requirement: Active users will continue to
use SharePoint for 8 hours and Inactive user will timeout after 15 min.
SAML Token Life time (ADFS/ PING Fed): 8 hours
Logon Token Expiration (SharePoint) : 7 hours and 45
minutes.
- è So the idle
timeout would be 15 minutes.
- è User can
continue to work without re-authentication for a maximum of 8 hours
Sliding Session Custom Code – Dotnet Solution (Class Library)
Create a SharePoint Empty Solution and proceed further
1) You need to
refer below DLL’s in your project (apart from other DLL’s required for the
project)
a. C:\windows\assembly\GAC_MSIL\Microsoft.IdentityModel\3.5.0.0__31bf3856ad364e35\Microsoft.IdentityModel.dll
b. C:\Program
Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.5\System.IdentityModel.dll
2) You need
the implement a HttpModule.
a. And the
sample for the same is attached in the class file.
b. The code
implements SessionAuthenticationModule_SessionSecurityTokenReceived event.
i.
Go through this article to under the WIF
Authentication Module
3) Once you
build the WSP and deploy it, you need to add the module in your web.config
(Under section & section)
Sample from my project “
”
è If we have
crossed half of the session idle timeout then we renew the cookie.
è Otherwise
we don’t as it would be over kill to re-issue cookie on every request.
CODE SNIPPET
Configuration with ADFS
as Identity provider
1) The
following script shows you how to configured ADFS to issue SAML tokens with a
lifetime of eight hours.
Add-PSSnapin Microsoft.ADFS.PowerShell
Set-AdfsRelyingPartyTrust –TargetName "Sharepoint" –TokenLifeTime 480
Set-AdfsRelyingPartyTrust –TargetName "Sharepoint" –TokenLifeTime 480
Get-AdfsRelyingPartyTrust
2) By setting
the LogonTokenCacheExpirationWindow value to 465 minutes, sets the
session duration to 15 minutes.
$ap = Get-SPSecurityTokenServiceConfig
$ap.LogonTokenCacheExpirationWindow = (New-TimeSpan -minutes 465)
$ap.Update();
Iisreset
$ap.LogonTokenCacheExpirationWindow = (New-TimeSpan -minutes 465)
$ap.Update();
Iisreset
3) Deploy/ Install the
WSP solution as Farm Solution (Sliding Session Code – Dotnet Solution)
Add-SPSolution “Your WSP Location”\”Your WSP Name”.wsp
4) Web Config
Change
a. Entries in
the httpModules & Modules Section of web.config file
add name="SingleSignOut"
type="SlidingSessionNew.Class1, SlidingSessionNew, Version=1.0.0.0,
Culture=neutral, PublicKeyToken=546da86ff4b9c32a"
Configuration with PING Federation as Identity provider
1) Set the MINUTES BEFORE and MINUTES AFTER value to 1 & 480
respectively in PING Assertion creation screen
This will create a ping
token with Token life time for 8 hours (fiddler trace with the session)
Set the SESSION MAX TIMEOUT value to 480
3) By setting the LogonTokenCacheExpirationWindow value to 465
minutes, sets the session duration to 15 minutes.
$ap = Get-SPSecurityTokenServiceConfig
$ap.LogonTokenCacheExpirationWindow = (New-TimeSpan -minutes 465)
$ap.Update();
Iisreset
$ap.LogonTokenCacheExpirationWindow = (New-TimeSpan -minutes 465)
$ap.Update();
Iisreset
4) Deploy/ Install the WSP solution as Farm Solution (Sliding Session Code – Dotnet
Solution)
Add-SPSolution “Your WSP Location”\”Your WSP Name”.wsp
5) Web Config Change
a. Entries in the httpModules & Modules Section of web.config file
Application Validation
- Restart the App Fabric service on all SP WFE server and ADFS service on ADFS server (in case Identity provider is ADFS)
- Validate the share point site functionality for both Active / In Active behaviors.
Share your input/ comments in case of issues.
Thanks
