Press "Enter" to skip to content

Web Testing K2 SmartForms Applications with Claims-based Authentication

0
If you create a Visual Studio Web Performance Test for a SmartForms application that uses Claims-Based Authentication, like K2 Windows STS or ADFS (Active Directory Federation Services), you might end in a situation where each Web test request does not arrive to the form loading, but throws an error during the call of an Identity application, making all other subsequent Ajax calls (i.e. SMO calls) unsuccessful:

The error message you see (‘Script is disabled. Click submit to continue’), is because the Visual Studio Test Engine does not support JavaScript and thus the automatic POST of the SAML token into the Relying Party (i.e. your application) does not work.

In these cases, before actually being able to perform a successful request that hits your Smartform, you will need to perform an explicit authentication request to Identity application to get a valid Authentication cookie (AKA FedAuth cookie) and send this cookie in all subsequent requests. This will make the request as ‘authenticated request’, avoiding the redirection to the Identity application and thus the error above.


Below you can learn how to create additional Web Requests that authenticates Virtual Users in K2, configured by default with Windows STS.

1. I would recommend to use Fiddler or Browser Developer Tools to inspect a normal authentication flow on your SmartForms application. Assuming your Claims-based Authentication is configured for Windows Integrated Authentication, you should get a set of redirections, be prompted for your username/password, and arrive to your target application with a valid FedAuth cookie. Check the last request to ../Identity/.. application and take note of the following querystring values:
– wa – the operation name;
– wtrealm – your application identifier;
– wctx – in this case the app return URL after Identity sign in.
Copy the the values as they are, including the URL encoding:

2. In the Visual Studio on a new Web Test add a new request to the Identity Application URL (…/Identity/sts/Windows/wsfed) passing the wa, wtrealm and wctx values you’ve obtained as QueryString Parameters in p.1.
In order to avoid Response URL Validation Error later, you need to change he wctx parameter, obtained in p.1:

Original value:
rm=1&id=&ru=%2fRuntime%2fRuntime%2fForm%2fTest.ADCall.Form.AllUsers%2f
New value:
rm=1&id=&ru=%2fRuntime%2f
3. Add three Form Field extraction rules for the following values:
– wa;
– wctx;
– wresult.
Create the corresponding Context Parameters in the Web test.
This will perform a Windows Integrated authentication request simulating part of a normal federated authentication flow. Identity application will return a valid SAML Token in the wresult form field of the response. With the Extraction Rules, Visual Studio will extract the SAML Token value and place it the wresult Context Parameter for using it in the next request you will create (wa and wresult will also be extracted and re-sent).
4. You can provide valid AD credentials, configured in the Web Test properties as shown below:
5. Now you need to add another request to the Web Test for posting the SAML token to the Runtime application (https://k2.denallix.com/Runtime/). To do this, you should create a POST web request to your Form URL, passing the wa, wctx and wresult context parameters.
The response of this request will have a valid FedAuth cookie, which will be automatically stored by Visual Studio in a cookie container and sent back on subsequent requests to the application under test.

6. Let’s now run the Web Test stand-alone to make sure it’s working as expected.

Everything is working. So we have a Visual Studio Web Performance Test, that performs authentication via K2 Identity application and returns a valid FedAuth cookie. 
Now I would like to show you how this can be used within a Load Test.
1. We need to create a separate Login web test, in which we will implement only authentication without loading any form. For this you need to create an empty Web Test and create all Web requests with all parameters and settings, described above. In the end you will have something like this:
2. Add a Load Test to you project, set it up, add all the test mixes you need.For example:
3. Right-click the Test Mix and select Edit Test Mix. In the Initialize and terminate tests section Select our Login web test as an Initialize test to execute before other tests for each virtual user:
4. This means that before any other Web Test our Login Test will be run by each Virtual User. This way each Virtual User will first login and get a valid FedAuth cookie before executing other Web Test to add load to your application. All subsequent load test requests performed will hit your application directly, without redirecting to Identity application and thus seeing the error from the beginning of this post.
Please notice, that if the testing time exceeds the validity period of the FedAuth cookie all the Web Tests of your Load Test will start to fail. The expiration time of the FedAuth cookie in K2 is set to 8 hours by default, unless you changed it.

PS. Special thanks to Sebastian Durandeu’s blog, the materials of which I used in the post here.

Leave a Reply

Your email address will not be published. Required fields are marked *

two × 1 =