Cloud Blog

Category Archives: API Cloud

[Video] Analyzing API Statistics and Blocking Rogue Subscribers

WSO2 API Cloud has all you need for successful API program. This means that besides just publishing your APIs and opening subscriber portal, you need to have detailed analytics reports to see the actual subscriber behavior and be able to block the subscriptions that do not comply with your policies.

We have published a couple of quick demos to show how this works.

Some of our out-of-box API analytics reports:

And here’s a quick video of how individual subscription can be easily located and suspended:

Start your free API Cloud trial today!

[VIDEO] New Publisher and Subscriber Experience in WSO2 API Cloud

With the latest updates to WSO2 API Cloud, we have made publishing and subscribing to APIs even easier!

Published APIs now just work out of box including interactive API Console (you no longer have to enable OPTIONS method for your APIs or edit Swagger file) – so the number of clicks to get your API published went down dramatically and the process became extremely straight-forward:

In subscriber portal (API Store) things got simpler as well. Interactive API Console no longer requires you to provide OAuth key manually and just grabs it from your configuration automatically. It also shows you various invocation and response details including the sample Curl command for your API call:

With these (and many smaller) changes and improvements, your API programs are now even more attractive and easier to implement.

Sign up for your free trial at http://wso2.com/cloud/api-cloud

Your own JAX-RS as an OAuth Web API in Minutes!

UPDATE: This is an outdated post. WSO2 App Cloud has been since then replaced with WSO2 Integration Cloud and App Server in it with Tomcat. General principals still apply and JAX-RS is a supported backend implementation in the Integration Cloud. Click Support inside the Integration Cloud UI if you need help.

We’ll be using WSO2 Application server in Cloud to host a secured JaxRS service. A future post will explain how to do it with Tomcat, but this post is written for WSO2 App Server.

After writing the JAX-RS service we are going to protect it using OAuth with several clicks. Then you’ll be able to,

  1. Access to the back-end JAX-RS service will be OAuth protected
  2. Advertise the API in an API store for the world to see
  3. Access to the back-end JAX-RS service will be throttled
  4. Allow people to subscribe to these APIs

This is the high-level diagram,

Step 1 – Adding security to the JAX-RS service in App Cloud

Step 2 – Expose it as an OAuth protected API

Step 1 – Adding security to the JAX-RS service in App Cloud

Here I am going to add security to my JAX-RS service by introducing the following lines to the web.xml. As you can see this is plain Tomcat based security. And you have not defined a Realm here. I will explain what happens to the realm below.

<security-constraint>
 <web-resource-collection>
 <web-resource-name>ElephantTracker</web-resource-name>
 <url-pattern>/*</url-pattern>
 </web-resource-collection>
 <auth-constraint>
 <role-name>admin</role-name>
 </auth-constraint>
</security-constraint>

<login-config>
 <auth-method>BASIC</auth-method>
 <realm-name>ElephantTracker</realm-name>
</login-config>
 

Now only the people in admin role can call this service. If you are familiar with Tomcat security, the question is: where is the realm and is the role coming from? It is coming from the Cloud user store.

 

We have simplified a lot of security related details in WSO2 Application Server. Now let’s try to invoke it using a REST Client.

 curl -v -H   
 "Authorization: Basic Base64_encoded_String_of_your_Username:Password  
 "https://appserver.dev.cloud.wso2.com/t/perftest/webapps/securedjrs-default-SNAPSHOT/services/customers/customerservice/customerservice/customers/123  

The trickiest part is figuring out the username. The “@” sign in the email address must be replaced with a “.”  and the tenant domain must be appended with the “@” sign.

 
dimuthu.leelarathne@gmail.com == becomes ==&gt; 
dimuthu.leelarathne.gmail.com@perftest  

Here “perftest” is my tenant domain name.

Next, remember to turn off “http” from transports.

Step 2 – Expose it as an OAuth protected API from API Cloud

Now go into API Cloud and publish the JAX-RS as a service.

Add the proper resource URL patterns and end points. In my case I am going to add “customerservice/customers/{id}” as the url pattern and endpoint of the service as the endpoint. In my case, it is something as follows,

http://identity.cloud.wso2.com/t/perftest/webapps/securedjrs-default-SNAPSHOT/services/customers/customerservice

Give the username/password to access it.

Screen Shot 2015-08-24 at 1.49.35 PM

Woala you are done! Now you have an API in the store, that is accessible the whole wide world!

Disabling OAuth in API Cloud

OAuth2 has become the industry standard for secure API access, and is the default security mechanism that you get for your API subscribers in WSO2 API Cloud. API Cloud fully automates OAuth key generation and management.

However, there are circumstances when you might want to temporarily have your APIs available with no security required. For example, this might be the way you decide to launch them initially while you are still on the prototype phase.

WSO2 API Cloud gives you two ways of achieving this:

  • By publishing your API as Prototype, or
  • By setting required resource authentication level to None.

Publishing as Prototype

Prototypes are different from common published APIs because they are meant to run your ideas across your community to quickly collect feedback.

They can be implemented with a proper backend webservice (just like other managed APIs) or JavaScript.

Either way, they require no subscription. Your users will be able to give them a try without having to subscribe to them.

To publish an API as prototype:

  1. Pick Prototype on the second step of API creation (Implement),
  2. Provide JavaScript or backend URL,
  3. Click Deploy as Prototype.

Deploying an API as prototype (JavaScript or backend) on Step 2 of API implementation

The API will appear on the Prototypes tab of API Store and will not require authentication for access.

API prototype in WSO2 API Store

Authentication Type: None

You can also remove authentication requirements for regular managed APIs. This is useful when you want to still have the API listed on the API Store home screen and/or when you want to disable authentication requirement for individual resources of an API.

For that, go all the way till the last (Manage) step of API creation, and then change Authentication Type to None in the drop down next to each API resource at the bottom of the screen:

Setting REST resource Authentication Type from OAuth2 to None

Happy API management!

API Cloud upgraded to API Manager 1.9

Good news! We have just finished upgrading WSO2 API Cloud to the latest codebase of WSO2 API Manager (1.9) – which brings us the latest features and fixes.

The biggest improvement is full Swagger 2.0 support. Swagger is the industry standard for API definitions and this is what API Cloud is using natively as well.

You can not just import or export the Swagger definitions, but also edit your API in full-featured Swagger editor with intellisense tooltips, syntax checks, and so on. Simply click Edit Source on the first step of API editing:

Edit Source button on the first step of editing API

And you get the full power of Swagger at your disposal:

Swagger wysiwyg editor and tooling in WSO2 API Manager

There are many other improvements and fixes, and we will be now re-releasing our tutorial videos and publishing new blog posts covering the exciting new functionality. Stay tuned!

Sign up for free trial of WSO2 API Cloud at http://wso2.com/cloud/api-cloud

API Cloud: Connecting to Backend Service with OAuth, Simple Auth, IP Whitelisting

WSO2 API Cloud provides a simple way to turn your web services into managed APIs with enforced policies, security, subscriber portal, and analytics.

To make this all work, all API calls from subscribers need to go through API Gateway rather than directly to your backend. See arrow 3 in the API Cloud schematics here:

cloud-api-diagram - how WSO2 API Cloud works

What this means is that you promote to your subscribers the API as it is published in the gateway and API Store, while securing the link between API Gateway and backend service.

There are a few ways that you can secure the connection between the gateway and the backend:

  • Unsecured access,
  • Simple username/password authentication,
  • IP whitelisting,
  • OAuth.

Unsecured Access is obviously the easiest. While not a good idea in the long run (if users are bypassing the gateway, you don’t really have an API management solution in place), but when you are only starting and experimenting, and have not launched the program yet – this is the easiest way to get started.

Because of that, this is the default mode and the one we are using in API Cloud tutorials.

Simple Username/Password Authentication is also very easy to implement. All you have to do is click Show More Options on the second (Implement) step of API implementation, select Secured from the drop-down list below it, and provide credentials:

Specifying credentials for backend API connection

IP Whitelisting is a good further security step. Simply contact our team via Support / Contact Us menu item, and we will give you the IP address range that we use for API gateway. That way you can set up your backend to only accept invocations proxied by the gateway.

Finally, if rather than username & password, your backend service only accepts OAuth2 authentication, we now have a fully documented way of using that approach. See this tutorial that we just published.

Happy API implementations, and let us know if you have any questions.

“High” severity security vulnerabilities in OpenSSL

WSO2 Cloud Services are not affected by this vulnerability, however systems administrators are highly advised to update the OpenSSL version.

OpenSSL is one of the most widely used implementations of the Secure Sockets Layer (SSL) and Transport Layer Security (TLS) cryptographic protocols. It’s being used widely on many internet-facing devices, including two thirds of all web servers. On 9th July, OpenSSL released a security patch to fix a new vulnerability discovered in versions 1.0.2 and 1.0.1.

“During certificate verification, OpenSSL (starting from version 1.0.1n and 1.0.2b) will attempt to find an alternative certificate chain if the first
attempt to build such a chain fails. An error in the implementation of this logic can mean that an attacker could cause certain checks on untrusted
certificates to be bypassed, such as the CA flag, enabling them to use a valid leaf certificate to act as a CA and ‘issue’ an invalid certificate.”

 - OpenSSL Security Advisory [9 Jul 2015]

The vulnerability appears to exist only in OpenSSL versions released in June 2015 and later. Because of this, the vulnerability only affects a limited set of OpenSSL versions: 1.0.2c, 1.0.2b, 1.0.1n and 1.0.1o.

Red Hat, CentOS, Debian, and Ubuntu have released notices stating that their distributions are not affected by this vulnerability as they were not using the latest version of OpenSSL.

How to make sure that your systems are not vulnerable?

If you are using any affected version, you should update your OpenSSL instance to a version as mentioned below.

  • OpenSSL 1.0.2b/1.0.2c users should upgrade to 1.0.2d
  • OpenSSL 1.0.1n/1.0.1o users should upgrade to 1.0.1p

Note: The bug does not affect OpenSSL versions 1.0.0 and 0.9.8.

WSO2 Clouds: Private, Managed, Public

Hello, World! This is the inaugural post in our new WSO2 Cloud blog. We will be covering the news and updates from the Cloud team at WSO2.

When we talk about Cloud at WSO2 we talk about the WSO2 platform used in one of 3 scenarios.

WSO2 Cloud modalities

Private Cloud has been historically the first one for WSO2.

WSO2 was the original creator (and is now one of the main contributors) to Apache Stratos PaaS (and is still supporting it commercially under the name of WSO2 Private PaaS) and has WSO2 App Factory PaaS that can run on top of it giving comprehensive developer experience with full lifecycle management, cloud IDE, teamwork, and so on.

In addition to that, the whole WSO2 integration platform stack plugs into the PaaS, giving complete cloud platform with:

  • Identity federation and management,
  • API management,
  • Integration,
  • Device management,
  • Application management
  • Data analytics (real-time and batch).

This makes it possible for some of the biggest companies in the world to deliver complex functionality for their employees, partners, and customers.

For example, watch this talk by Boeing on how they used WSO2 stack to implement their Boeing Edge platform that collects data from airplanes, analyses it, and then exposes to customers (airlines) in combination with supply chain systems for proper airplane servicing, ordering replacement parts, and so on.

Boeing Edge talk on WSO2 technology used by the company

Managed Cloud is not a software product really but a dedicated hosting option that we offer to our enterprise customers.

If you want to use any combination of WSO2 products, but do not want to maintain that deployment – our operations team is happy to do this for you:

  • Available for any combination of WSO2 products,
  • Run in the region of your choice on dedicated virtual machines not shared with any other customers,
  • WSO2 engineers set up the environment including the virtual machines, WSO2 products, and networking,
  • Can be set up to have network connectivity with your on-premise datacenter,
  • Deployment can be customized for your specific needs,
  • Can be combined with professional services including consultancy, development, and QuickStart,
  • Includes full devops service including 24*7 monitoring, regular backups, and product updates,
  • Priced as a fixed monthly fee,
  • Guaranteed service level and uptime.

Finally, WSO2 Public Cloud is a combination of WSO2 products deployed in shared multitenant mode.

These are shared deployment so the customization options are more limited. However, the pricing is extremely attractive: API Cloud starts at mere $100/month (after a free trial), and App Cloud is in free beta, and all you need to do to start using it is just go to http://wso2.com/cloud and sign up with your email address.

Two services are currently available:

And we keep working on adding more cloud services based on other WSO2 products – so stay tuned!

Categories

Recent Posts

Most Popular Posts