Cloud Blog

End-User Authorization with API Backend

In many cases, your applications and APIs need to take end-user identity into consideration. There are two ways this can be implemented in WSO2 API Cloud:

  1. Using WSO2 Cloud’s identity store and ‘Application & Application User’ authorization, or
  2. Using backend identity store and X-Authorization header.

In this blog post, we will look into the details of each of these two approaches.

1. WSO2 Cloud’s identity store and ‘Application & Application User’

This approach works best when your APIs target internal developers and partners, who subscribe to your APIs and invoke them.

All of them will thus sign up in your developer portal (API Store) and have their identity records in the system.

Since all the identities are in WSO2 Cloud, you do not need additional user-level authentication against the backend. Authentication is happening by passing the OAuth Authorization bearer header to the API gateway:

Authenticate with API Cloud and pass JWT

If your backend service needs user information, it can get it from JWT token that gateway passes with the call. Note that if you are using WSO2 API Cloud, you do not have to enable JWT tokens: passing them is the default behavior.

2. Backend identity store and X-Authorization header

This approach is typically used when you have a consumer mobile or web application with many users, all of them registered with some sort of backend identity store.

In that case, they all share the same application but need the extra user authentication.

Add X-Authorization to authenticate with backend

To make this happen, the following pattern is typically used:

  1. Application uses Authorization bearer header with the application token to communicate with the gateway. The token can be obtained manually from API Store or programmatically using token APIs,
  2. Then application prompts end-user for username and password, authenticates against the backend service, and get the corresponding OAuth token from it,
  3. In all subsequent calls, application passes two headers: Authorization with the application token for API Cloud gateway and X-Authorization with user token for the backend.

If backend cannot be changed to use X-Authorization and instead needs Authorization, the corresponding mediator sequence can be used to swap the headers.

API Gateway to backend service calls can be secured with a variety of mechanisms including IP Whitelisting, basic authentication or passing an authentication header.

Whatever you scenario is, try it today in WSO2 API Cloud!

Load Testing Published APIs with JMeter

WSO2 API Cloud gives you automated scaling and call limit enforcement.

Today we will describe how you can use Apache JMeter to load-test your APIs in WSO2 API Cloud and see these limits enforced.

1. Start by publishing your API and subscribing to it as explained in API Cloud tutorials.

2. Download Apache JMeter here, extract the files, navigate to /apache-jmeter-2.11/bin folder, and start it by running:

  • sh jmeter.sh on Linux or Mac,
  • jmeter.bat on Windows.

You can find more information on JMeter on their Getting Started page.

3. To add your test, in JMeter window, right-click the Test Plan node and click the Add / Threads (Users) / Thread Group on the shortcut menu:

JMeter add thread group

4. Now to add API call request, right-click the Thread Group that you have just added and click the Add / Sampler / HTTP Request on the shortcut menu:

JMeter add HTTP request

5. Provide API call details: Server Name and Path. You can easily see them on your API’s API Console page in API Store in Request URL when you invoke the API:

Getting API Server Name and Path from Subscriber Portal's API Console

Server Name is the domain of the API URL. If you have not assigned your own custom URL, this would be gateway.api.cloud.wso2.com.

Path is the rest of the URL. For example, in my case this is /t/wso2new/wb/1.0.0/countries/us.

Put your parameters in the corresponding fields of JMeter:

JMeter API server name and path

6. Now we need to add the authorization header. Right-click the HTTP Request node and, on the shortcut menu, click Add / Config Element / HTTP Header Manager:

JMeter Add HTTP Header

In the HTTP Header Manager, click the Add button. A new row will get added to the table of Headers Stored in the Header Manager.

Set Name to Authorization. And copy the Bearer part from API Console:

JMeter Add Authorization Header

7. To be able to view results, add a listener. For that, right-click the Thread Group node and, on the shortcut menu, click Add / Listener / View Results Tree.

JMeter View Results Tree Listener

8. Now you can click the Run button and verify that the API call was successful. If prompted to save the configuration, do so.

JMeter single test

9. To be able to test at larger load, go back to the Thread Group node, and increase the Number of Threads and Loop Count:

JMeter increase load

10. You will see that some of the messages are now getting blocked by the API Gateway. Check out the Response data tab to see why.

The limits imposed on the subscriber by the Subscription Tier that you set for the API – for example, 20 calls / minute – will result in “You have exceeded your quota” response:

JMeter failing subscriber limits

The transactions per second (TPS) limits that are based on your API Cloud subscription level will lead to “Your request was blocked due to exceeding the allocated quota. Please contact the API Store owner to resolve this.”:

JMeter failing organization limits

11. If you want to simulate multiple subscribers, you can create another subscriber account in API Cloud and create another HTTP Request in JMeter with this new subscriber’s authorization header.

12. To run the tests from multiple machines using commandline, you can use the saved plan file and run:
sh jmeter.sh -n -t TestPlan.jmx -l Test1.jtl
where -t specifies the saved Test Plan file and -l specifies the output file for the responses, or the corresponding .bat command on Windows.

That is it! Try it today in WSO2 API Cloud!

[Video] Publish and Invoke SOAP APIs

It may seem that REST is taking over the world, but in fact, there are still plenty of SOAP APIs out there and these can be published and consumed in WSO2 API Cloud just fine.

The easiest way to add a SOAP API is to simply import the WSDL definition as shown in this new video:

SOAP calls then can be invoked both through the built-in API Console and external tools and code.

If you want to follow a step-by-step tutorial instead, we have one published too: Publish and Invoke a SOAP API.

And if you want to transform SOAP backend into a REST API, this too can be done with API transformation sequences. For example, we published a tutorial specifically on using transformation sequences to transform JSON payload to SOAP, and SOAP response back to JSON.

Have a SOAP endpoint to share? Try it today on WSO2 API Cloud!

WSO2 Cloud Incident Report: Feb 4, 2016

WSO2 Cloud has faced a serious degradation of service recently: API Publisher and Store started performing slowly and didn’t function properly. For some users, it returned a 404 when trying to access the UI. Below is the detailed post-mortem analysis for the incident.

Start time: February 4, 2016 8:35 PST
Recovery time: February 4, 2016, 9:45 PST

Impact:

  • Publisher and Store UIs were not functioning properly.
  • Because of this, API related administrative tasks could not be performed.
  • However, already hosted APIs were functioning properly: http://uptime.cloud.wso2.com/

Root cause:
One of the publisher/store nodes started consuming too much memory. This node was initially able to recover itself but then became unresponsive. This affected the other node in the cluster too and it also started slowing down. Since the first node was not down, users were routed to that one too by the load balancer. Those users experienced a 404 error and the other users experienced extreme slowness.

Actions:

  1. Our monitoring system had failed to read the memory consumption of the problematic node at that time and ended up with failing to alarm us. We have fixed this now.
  2. We have tuned the alarm triggering thresholds to notify us earlier than during this incident.
  3. We have enabled the Java Flight Recorder to run and collect stats for us to investigate in a similar situation in the future.
  4. We improved our health checking tool to probe individual instances rather than going through the load balancer. This will help us to identify these kinds of situations quickly. With the measures taken in #2 and #3, we will gather necessary information to identify the culprit and then escalate to the internal support team to fix it.

Detailed Managed Cloud Documentation Published

Besides shared public WSO2 Cloud, our team also runs Managed Cloud – dedicated hosting of all WSO2 products for many private and government customers in Americas, Europe, and Asia/Pacific region.

In our effort to increase the transparency of our internal operations, we have made publicly available detailed documentation on how we run this hosted service:

Managed Cloud steps

Documentation includes information on the planning process, permission and networking set up, monitoring, backups, workflows for ticket submission and resolution, service levels, and much more.

Our public cloud operations are very similar to the managed cloud ones. The same team is handling both kinds of deployments and the set of tools and procedures is highly standardized.

Check out WSO2 Managed Cloud details at: https://docs.wso2.com/display/ManagedCloud/WSO2+Managed+Cloud+Documentation and click the Contact Us link if you would like to talk to us about using this service for your project.

Categories

Recent Posts

Most Popular Posts