Session cookie versus persistent cookie as it pertains to SharePoint for the RSA Authentication Agent 7.1.3 for Web for IIS

[#1]

Article Number

000030860

Applies To

RSA Product Set: SecurID
RSA Product/Service Type: Authentication Agent for Web for IIS
RSA Version/Condition: 7.1 & 8.x

Issue

The SharePoint core.js has to be modified manually when implementing the RSA Authentication Agent 7.1.3 for Web for IIS in order for persistent cookies to work with SharePoint.

This article explains the difference between a session cookie and a persistent cookie in the RSA Authentication Agent 7.1.3 for Web for IIS, and why these changes are needed.

Cause

Because persistent cookies are considered a security vulnerability, they are only created and used when it is considered absolutely necessary.  This is why the RSA Authentication Agent 7.1.3 for Web for IIS, when used with SecurID authentication, does not create a cookie that is persistent from its creation (so that a protected web site could not destroy the cookie); rather, the IIS web agent creates a session cookie.

SharePoint web sites break sessions during certain activities, such as when opening a document.  When the session is broken, the RSA session cookie that was created at the initial SecurID authentication is eliminated from the browser/web server interaction.

The persistent cookie setting was added to the IIS web agent to address this situation.  The settings are visible in the IIS Manager under Cookie Expiration Settings on the main screen of the configuration panel.
 

Image description

Resolution

Session cookies

To cover the session break, RSA used two forms of persistent cookies shown above for SharePoint.  The SharePoint persistent cookies, then, are only for the purpose of handling SharePoint session breaking.  

The session cookie, configured on the main page of the web agent web site configuration, is still the primary cookie that is referenced all the time, unless it cannot be found because of a SharePoint session break.  It is the session cookie that is the most important.

The first setting Expires if not used within the specified time means that no matter the value set for the lifetime of the cookie, the cookie will expire if it is not referenced within the specified amount of time between references.  Often this time is stated as the idle time setting.  The user’s cookie is good as long as a user references the web site on a basis where no two succeeding references occur beyond the idle time, or until the cookie’s lifetime from the second setting expires.  In the above setting in the screen shot, if a user does not access the web site within five minutes of his last access, the cookie will expire and he will have to login again.  If he accesses the web site within four minutes of cookie creation, he gets another time slot of five minutes in which to access the web site again.  Each access within the five minute time slot will begin another five minute time slot until the cookie’s life-time expires.

The second setting, Always expires after the specified time, is the absolute lifetime of the cookie.  No matter how often the cookie is referenced for URL access, the cookie will, always, become unusable after the specified time has elapsed since the creation of the cookie.

For SharePoint configuration of persistent cookies:

1. Click Start > Settings > Control Panel.
2. Double-click RSA Web Agent.
3. In the Connections pane of the IIS Manager, double-click server_name > Sites then click the name of the SharePoint web site.
4. In the SharePoint web_site Home pane, double-click RSA SecurID.
5. Click Manage SharePoint Settings.

Image description 
 

The first setting pertains to short-term persistent cookies. The second setting refers to long-term persistent cookies.  As stated, SharePoint operations will often break a session, so session cookies are eliminated.  A persistent cookie is the only kind of cookie that will survive a session break, so these must be used to act as the proof that a URL is legal to access because a user has previously authenticated successfully with SecurID.  The existence of an RSA cookie, of any kind, is proof of SecurID authentication; so it is key to access any particular SecurID protected URL.
 

Short term persistent cookies

With the short-term persistent cookie setting, a persistent cookie is created whenever SharePoint is about to break the session.  The core.js file governs when such a session break is about to happen and informs the RSA Authentication Agent for Web to create the persistent cookie that will survive the session break.  The persistent cookie creation will happen right before the session break so that the persistent cookie can copy values from the still alive session cookie.  Next, the session break occurs and our SecurID session cookie goes away; but the persistent cookie, created before the break, remains and keeps us through the break.  On the next URL access, after the break, we want to revive our session cookie for coverage of the new session, so a new session cookie is created with values taken from the persistent cookie, and the persistent cookie that is no longer needed is now deleted.  

This is the reason we call this first option a configuration for short-term persistent cookies.  These persistent cookies are very short term, and last only for the duration of one URL access.  
 

Long term persistent cookies

With a long term persistent cookie setting, a persistent cookie is created for a URL that that is considered a session breaker.  Once it is created, though, it remains until it expires within its lifetime as given by the setting Long Term Persistent Cookie Expires Always After.  One has to guess which URLs are session breakers for which a persistent cookie must be created, so that is why in the URL list the value of /* is often used.  In other words, create a persistent cookie for all URLs under the root.  This though, presents a security risk because of a cookie hanging around on a client machine for a long period of time, governed by the time setting for the long term persistent cookie configuration.  Using a long term persistent cookie configuration with a URL list of /*, rather defeats the refinement of configuration for the normal session cookie, described in the beginning.  Long-term persistent cookie configuration is generally considered a bad thing, but it is easier to configure than the short-term persistent cookie, because the short-term configuration must accompany proper modification of the core.js file.