Load Testing ADFS-Federated SharePoint Applications

If you create a Visual Studio Load Test for a SharePoint application that uses Federated Authentication using ADFS (Active Directory Federation Services), you might end in a situation where each Web tests request of the Load Test does not arrive to the application, but is stuck in an ADFS redirection like this:


Without getting into the technical details, 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 (more details here).

In these cases, before actually being able to perform a successful request that hits your SharePoint application, you will need to perform an explicit authentication request to ADFS to get a valid Authentication cookie (AKA FedAuth cookie) and send this cookie in all subsequent requests. This will make the request an ‘authenticated request’, avoiding the redirection to ADFS and thus the error above. Throughout this post you will learn how to implement this flow within a Load Test by creating a Login Web Test that authenticates Virtual Users in ADFS.

Disclaimer: To keep things as short as possible I won’t get in Visual Studio Load Testing or ADFS details. I will assume that you’ve used VS Testing platform before and you are somehow familiar with ADFS. If you want VS Load Testing documentation this post has a comprehensive set of links. Additionally, I’ve also found this Visual Studio Performance Testing Quick Reference Guide a gem; it is a bit more advanced, but very complete, covering lots of specific cases. Finally, notice that I will  assume some ADFS and SharePoint configurations, but I’ll try to make them explicit.

1. To start I’d suggest that you use Fiddler to inspect a normal authentication flow in your SharePoint application. Assuming ADFS 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 ADFS and take note of the wa (the operation name), wrealm (your application identifier) and wctx (in this case the app return URL after ADFS sign in) querystring values. Make sure you copy the values as they are, including the URL encoding.


2. Now let’s switch to Visual Studio. On a new Web Test, let’s add a new request to the ADFS Integrated Login URL (…/adfs/ls/auth/integrated) passing the wa, wtrealm and wctx values you’ve obtained as QueryString Parameters. Then add three Form Field extraction rules for the following values: wa, wctx, wresult. Make sure the corresponding Context Parameters are created in the Web test.


This will perform a Windows Integrated authentication request simulating part of a normal federated authentication flow. After Visual Studio provides valid AD credentials (configured in the Web Test properties as shown below), ADFS 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).

3. Now you need to add another request to the Web Test for posting the SAML token to the SharePoint application. To do this, you should create a request to the Sharepoint STS URL (/_trust/) under your SharePoint application, passing the wa, wctx and wresult context parameters (the {{…}} pattern indicates the use of context parameters values). 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.

4. It’s also a good idea to add a final request to the application under test to make sure authentication worked as expected. Ideally, a Validation Rule should be added to ensure that the request is indeed reaching the application and not bouncing back to ADFS for authentication. For example, you can add a validation rule that parses some user identifier value present in the page.

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


6. Good, you now have a Visual Studio Web Test that performs login with ADFS and gets back a valid FedAuth cookie. So let’s see how this can be used within a Load Test. When creating a Test Mix you can specify an Initialize test, which is run by each Virtual User before any of the tests in the Test Mix are executed. This way each Virtual User will first login in ADFS 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 ADFS 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 SharePoint is set to 10 hours by default, but in your environment this might differ – check this thread with more information on how to check it.

Thanks to Rodrigo Molinas (@romolinas) and Sebastian Ballarati (@sballarati) for their contribution in the code for this post.


  • Sebastian Ballarati (@SBallarati) says:

    Nice article Sebas!

    I just wanted to add something regarding the expiration time of the FedAuth cookie, mostly because it is very common to find the known infinite loop going back and forth between ADFS and Sharepoint… So, in order to avoid running into this issue, you should be careful with the ADFS TokenLifetime and the LogonTokenCacheExpirationWindow setup. For further info please check this article: http://msdn.microsoft.com/en-us/library/hh147183(v=office.14).aspx

    Best regards,

  • Thanks for any other great article. Where else may anyone get that kind of info in such a perfect method of writing? I have a presentation subsequent week, and I’m at the search for such info.

  • chakri says:

    image not shown 🙁

  • Emmanuel ISSALY says:

    hi, interesting post. I have a variation of that problem, i want to load test *external* users on a platform. So, best case, they auth by a ADFS form (not wia). With a form, the method you provide doesn’t seem to work. any ideas?

  • Emmanuel ISSALY says:

    Tried to make it work, but i could’nt. Afaik, in ADFS 3 it’s adfs/ls/wia for integrated.
    After that, the test fails with “form field ” was not found” thrice (for each parameter i guess)

Leave a Reply