How to Load Test OpenId Secured Websites
OpenId enables users to be authenticated using a single ID. The OpenId provider (OP) is the third party that authenticates a user signing in with an identificator.
Join the DZone community and get the full member experience.Join For Free
OpenId is an open standard and decentralized authentication protocol. It is one of the few technologies for single sign-on (SSO) with token based authentication. This post will describe the implementation of JMeter scripts for load testing websites that use the OpenId protocol to authenticate users. We have already discussed the implementation of JMeter scripts for load testing SAML and OAuth, which are also authentication technologies.
OpenId enables users to be authenticated using a single ID. This means that a user who needs to be authenticated in a web service that supports OpenId doesn’t need to enter a unique login and password, but only an identificator. This identificator will be the same for all web services that support OpenId.
The authentication workflow requires the presence of a third party that confirms to the web service that the provided identity is correct. That third party may provide the user related data to the web service as well.
Like in SAML and OAuth-based authentications, there are three parties in the authentication flow:
Client or relay party (RP).
Identity or OpenId provider (OP).
The OpenId provider (OP) is the third party that authenticates the user. The relay party (RP) is the web service that authenticates the user. All the user needs to do is to register to the OP and receive an ID. This ID can be used to authorize her or him on all web services that support OpenID. The ID that is used for the authorization is usually a URL that is related to the user.
The OpenId authorization is as follows:
On the web service login page, the user clicks on the OpenID provider icon. The user enters her or his OpenId identificator in the pop-up window that opens up and then clicks on the Authorize button.
The web service determines the OP URL, establishes a connection, and sends it the request for authorization via user browser. In other words, the browser is redirected to the OP for authorization.
The user enters a login and password for authorization on the OP. If the registration is successful, the OP confirms the authenticity of the user to the web service, the web service authorizes the user, the user is redirected back to the service and gets logged in.
There are many sites and web services that support OpenID authorization and there are many OpenId providers as well. For example, users may register on the OpenID website and use their blog’s URL to sign into LiveJournal. Another popular OpenId provider is VeriSign.
Load Testing OpenId
This example is a user authorizing her or himself to StackOverflow (the RP) using the OpenId URL of the Wargaming.net site (the OP). Different web services might have additional steps, but this is the general flow.
1. The user opens StackOverflow (the RP) and attempts to log in. The OpenId is sent to the RP. The user is directed to the OP site. On JMeter, this is demonstrated through an HTTP request to the site.
2. The BeanShell PostProcessor extracts callback URL and additional parameters. They are used further in the script.
3. The Regular Expression Extractor gets the CSRF token that is used further in the script in the login call.
4. The OP makes the authorization request and if it succeeds the user becomes authorized in the RP. On JMeter, this is added through an HTTP request that submits the login details.
That’s it! You can now run the test and see how your site handles OpenId requests.
Note: this is a load testing example for a single user. When you scale the number of users, make sure you have a corresponding number of IDs registered with the OP. Multiple IDs can be managed through the CSV data config element.
You are welcome to ask me questions in the comments section of this post.
Published at DZone with permission of Konsantine Firsanov, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.