Partager via

Load Testing SAML (PING) Based SharePoint 2013 Sites

  • Article

I have to proof to a customer that their SharePoint infrastructure supports their user base and workload. So the logical solution is to Visual Studio Team System (VSTS) to build web tests and load tests and simulate the load and see how the farm reacts.

There is one problem: the sites are based on SAML (PingFederate is used as the IdP).

SAML based sites are a lot different from sites using Windows Integration Authentication methods such as NTLM and Kerberos when users log in. The user will be redirected from SharePoint to SAML IdP, be presented a web form to fill out their username and password, be authenticated, and then be redirected back with a SAML token to SharePoint to be validated and then start browsing SharePoint content.

These work fine under normal user scenarios, the question is how do we turn it into web tests and load test to simulate large amount of users and requests coming to the sites and see how SharePoint farm would perform.

After playing with VSTS and Fiddler and a little research, I found this very useful article online: https://blogs.southworks.net/sdurandeu/2013/01/03/load-testing-adfs-federated-sharepoint-applications/. It is written for ADFS but the idea stays the same. I modified the test cases and made them work for PING based SharePoint sites.

To test SAML sites, you need to create a web test to log in a user with SAML IdP first, then run subsequential web tests such as open a page, navigate the sites, search for something, and so on.

For the user log on web test, there are only two steps you have to take: 

  1. Request the SAML IdP's log in page with the correct query strings and form data, to get the SAML token back
  2. Come to SharePoint’s “/_trust/” to validate the token and get the FedAuth token

After getting the FedAuth token, you can start the real SharePoint performance and load tests.

All the above steps should be manually created in the VSTS and use a few variables to carry around some key factors, like the SAML token.

Below is the screenshot of the web test, you don’t have to write any code: 

In above web test the SAML token is carried around in a variable called "wresult", I also used a CSV file to store all test users’ credentials.

The information you have to modify according to your own environment is highlighted. Your environment may have different values for those “w*” variables, the best way to find this out is to use Fiddler to monitor a full SAML log on session, you will see the values in Fiddler’s WebForms window.

After you get the user log on web test, you can add other recorded SharePoint web test scenarios to your load test, just make sure you configure the user log on web test as the initial test to execute before other tests for each virtual user in your load test’s Test Mix.

One more thing to keep in mind: when you run load tests against your SAML based SharePoint sites, you will put a lot of pressure on your IdP (PING in my case) as well. Just make sure that you check with the team manages the IdP before you run your load tests, you don’t want to interfere with other users and systems that your IdP is supporting.

Comments

  • Anonymous
    July 23, 2014
    Nice article ! Keep up the good work !