K2 smartforms uses Internet Information Services (IIS) and ASP.NET to manage logon sessions. In terms of ASP.NET, the SmartForms application is not affected by sessions. However, the authentication model may still use headers and cookies to keep track of the authenticated user.
When using Azure Active Directory (AAD, such as in Appit environments), you cannot change the session timeout as it is controlled by the AAD token's ValidTo setting. Specifying the session timeout value on the K2 server has no impact. The default ValidTo setting is 8 hours.
The timeout behavior depends on the authentication configuration in K2 smartforms as shown below:
|Anonymous Access/Connect As Application Pool
||No timeouts are experienced since all connections are made in the context of the Application Pool Identity user
||No timeouts are experienced as the browser automatically uses NTML or Kerberos to re-authenticate the user
||The user is redirected to the login screen after the session has expired and the current form is lost (standard ASP.NET)
||The behavior is controlled by the WIF configuration – usually the user is passively redirected to re-authenticate either using Windows credentials or a Forms based login. The current form may be lost if the re-authentication redirects the user back to the root of the web site. In some cases the user can continue working.
When using Forms Authentication and Claims-based Authentication and the session expires, the user may lose all the information on the Form that he or she was currently working on. However, some browsers have the functionality to keep the current state or autocomplete information.
The following settings can be used to manage the session timeouts:
The sessionState mode setting controls the ASP.NET session state and is disabled by default in K2 smartforms.
<forms defaultUrl="Default.aspx" loginUrl="Login.aspx" requireSSL="false" enableCrossAppRedirects="true" cookieless="AutoDetect" timeout="9000"/>
The timeout setting in the above node controls the time (in seconds) that the Forms Authentication ticket cookie is valid before the user needs to log in again.
<httpRuntime maxRequestLength="16384" enableVersionHeader="false" sendCacheControlHeader="false" executionTimeout="320"/>
The executionTimeout setting controls how long (in seconds) ASP.NET attempts to execute a request such as deploying a view or form, executing a SmartObject method, or uploading a file before the session expires. The action is per-HTTP request and does not affect authentication or sessions directly.
Configuring Session Token and Maximum Token Lifetime Values
You can configure the Session Token and Maximum Token Lifetime values in the STS web.config file to shorten or lengthen the token lifetime.
The SessionTokenLifetime and MaximumTokenLifetime keys control how many seconds the session token remains valid. This is normally set to around 8 hours (28800 seconds).
To change the settings:
- Access the web.config file in the following location for K2 4.7 or prior:
<install drive>:\Program Files (x86)\K2 blackpearl\WebServices\Identity\Sts\Windows\Web.config
For K2 Five:
- Change the following values to the required seconds:
<add key="SessionTokenLifetime" value="3600" />
<add key="MaximumTokenLifetime" value="3600" />
This means that the Session Token expires after an hour, which can be helpful when you’re debugging performance issues related to the STS.