A – Yes. The K2 installer sets the type of authentication according to the user manager of the environment. With the K2 smartforms 4.6.7 release, SharePoint and Appit integration changed. Appit is dependent on Azure Active Directory, which uses Claims-Based Authentication (CBA). This means that CBA is the default authentication mechanism. K2 has the ability to authenticate using Windows or Forms and ultimately is based on claims authentication. The _trust/Login.aspx in the highlighted field in Internet Information Services (IIS) indicates that CBA is being used in the Forms Authentication, but it also applies to Windows as well.
SharePoint, both on-premises and Online, uses CBA. This can impact authentication performance as multiple redirection calls occur between the K2 server and SharePoint. The diagram below illustrates the redirection between the K2 server and SharePoint.
When you open a form in SharePoint, three authentication processes occur:
- Sign in to SharePoint portal site
- Sign in to the Application web where the application.aspx runs – if you load a new form
- Sign in to SmartForms within the iFrame that resides inside the application. This is where the Secure Token Service (STS) redirects occur.
Beginning with K2 smartforms 4.6.7, the Windows and Forms STSs were added to fully support CBA. This introduced more authentication redirects, but these typically only cost the platform a few milliseconds of additional time. The Redirect URL that is sent to the STS is sent back to K2 smartforms containing a GUID and a Return URL. The URL can be long and is stored in an OAuth session state in the server database to avoid limitations in the overall URL length, a limitation with most browsers.
The image below indicates a typical authentication process when SharePoint accesses K2 smartforms. Chrome Developer Tools are used in the example below. To test this in your environment, open Chrome Developer Tools, and go to the Network tab. Open a SmartForm used in SharePoint and notice the server requests listed under the Network tab. Next to each call is a Status column that lists the status code for each request. These codes indicate if the request was successful or if there is an issue or actual error. Note the time taken for each request listed in the Time column. The long green line on the example indicates where to target your investigation of slow performance.
To enlarge click on the image below
Use the following status code categories to identify errors:
- 1XX - Information
- 2XX - Success
- 3XX - Redirection
- 4XX - Client Error (such as 404 Not Found)
- 5XX - Server Error (such as 502 Bad Gateway)
Using the codes above, here is what occurs in the example:
- The 302 status codes indicate that redirection occurs.
- The 200 status code means the request is successful.
- The spauthorize.aspx.cs code handles the session token checks and the URL redirects. It also checks the claims type mappings and cache, and sets the OAuth session state accordingly. During this process, connections are made through the connection pool. Finally, in spauthorize.aspx.cs, a Return URL is acquired from the OAuth session state and this URL is used to populate the iFrame in the SharePoint page so that the form is available in SharePoint. The form cache is checked to see if an instance of the form already exists before the form is loaded.
Based on the above explanation, various factors can lead to a slower loading of a form:
- Authentication token retrieval and validation delay issues
- Issues when a claims identity is created based on the token
- Connection issues when accessing the connection pool
- Delay in the redirect from the STS
- OAuth calls can sometimes take a long time, especially if a refresh token is not cached and needs to be obtained first using an authorize token
- An instance of the requested form is not cached
- If the browser already has a few tabs open, it may take longer to complete the URL redirects within the iFrame. The iFrame loads already have a negative performance impact, and redirects within iFrames can compound this delay.
If you do not use SharePoint in your environment, you can change the authentication method to Windows authentication to improve performance, effectively bypassing CBA and the use of the STSs. See the resources below for information on SharePoint authentication, SharePoint session lifetime, K2 authentication, and K2 authorization.