Authentication with Azure Load Testing series : Azure Active Directory
Authentication is a key step in the user journey of any application. Going about designing the authentication flow can be confusing and not straightforward. When load testing an application, this generally is the first step in the user journey. Supplying client credentials through a UI is not possible when load testing an application, so is evaluating how to implement specific authentication flows available on Azure, as they can be tedious and time consuming as well. Within this series, we will cover the authentication flows and scenarios that are possible with Azure Active Directory (Azure AD) as the identity provider. At the end of the blog, you will be able to Use Azure AD to Authenticate a web application hosted on Azure App Service using the client credential grant flow. Parametrize the client credentials in JMeter to retrieve them at run-time in Azure Load Testing. Prerequisites A webapp with authentication enabled with Azure AD. An Azure Load Testing resource. Azure key vault for storing secrets. Azure Load Testing resource configured to fetch the secrets during runtime. Visit here to learn how to do it. JMeter Authenticating to your web app with a shared secret When you are using a shared secret to authenticate to an application on, you essentially pose yourself as a trusted principal with a valid token that can be used to authenticate you to the application which is registered with azure active directory. The token helps establish a trust, that you can access and make modifications to the resource (application). To get the access token from Azure AD, we need to pass 4 parameters to get the access token: client_id client_secret grant_type and the tenant_id For more information you can see authentication using shared secret Retrieve client_id, tenant_id for the app registered with Azure AD by going to Azure Active Directory >>App Registrations >>Overview on the azure portal. Retrieve the client_secret for the app by clicking on Certificate & secrets >> Client Secrets The best practice is to store the above parameters into Azure Key Vault and then fetch them directly at runtime instead of hard coding them into the script. Configuring the JMeter test plan The JMeter test plan needs to be configured to make a request to the app’s authentication endpoint to acquire the token. The endpoint can be found by visiting Azure Portal and navigating to Azure Active Directory > App registrations > <YOUR-APPLICATION> > Endpoints It would look something as below: https://login.microsoftonline.com/<issuer>/oauth2/token For the allowed values of <issuer> you may refer to issuer values. In our case, it would be the tenant id. Once we have the token, we can pass it to the subsequent requests in the authorization header to authenticate to the application. Now that we know what needs to be done, let’s start implementing it. Creating the test plan in the JMeter GUI Start by adding two thread groups, (Authentication) one for fetching the bearer token and the other (Application) to access the landing page of the application. Add an environment variable element to the Authentication thread group. This environment variable will be used to fetch the values of fields like client_id, client_secret and tenant_id which we stored earlier in the key vault at runtime to help acquire the access token. Add a child HTTP request sampler (Token Request) to the Authentication thread group. Within this HTTP request we will setup a post method that will help retrieve the access token. Add two child post processor elements to the Token Request sampler, one JSON Extractor (Extract Auth Token) for extracting the token. The response from the Token Request HTTP sampler comes back as a JSON response and we extract the token using the expression $.access_token . The next post processor element would be JSR223(Set AuthToken), which will be used to set the token extracted as a property named access_token. Setting it as a property will allow the variable to be accessible globally across samplers and hence can be accessed by the next thread group. Next, let’s configure the application landing page (Homepage) to access the application homepage. Add a child element a header manager, to configure and maintain the header to be passed with the request. In this case we only pass the authorization header that would contain the bearer token obtained from the previous thread group (Authentication). Creating and Running the Load Test Once we have setup our JMeter test plan, now we can move ahead and run the same using the azure load testing service by creating a test, supplying the above created JMeter script as the test plan and configuring the environment variables. Supply the JMeter test plan (JMX file) we created in the previous section. Configure the Secrets section within the Parameters tab. We have stored all the sensitive information in the key vault. We would need to configure our tests to fetch those at runtime. Visit how to parameterize load tests to know more. Try this out and let us know if it works for you. Please use the comments section to help us with any feedback around this scenario and anything you would like to see next time. If you have any feedback on Azure Load Testing, let us know using our feedback forum. Happy Load Testing!!!Azure Media Services Github for 3rd party player framework samples
Media Services supports standards based streaming protocols including MPEG-DASH, and HTTP Live Streaming (HLS). Customers have the option of choosing from many available player frameworks on the market to meet their delivery and unique application needs. Often, customers need to choose an open source framework that runs on specific device or is supported in a favorite Javascript framework. Or they need the power of a commercial player framework with enhanced features, compliance, and support. The new 3rd-party player samples repo is a great place to start, contribute and learn what is available to use with Azure Media Services live and on-demand streaming.
