Cloud Blog

All posts by Dmitry Sotnikov

Dmitry Sotnikov is Vice President of Cloud solutions at WSO2. Prior to WSO2, Dmitry worked at Quest Software (now part of Dell) as Director of Cloud Solutions, and later co-founded Jelastic PaaS and led Jelastic's sales, marketing, customer and partner relationships. Dmitry has been a featured speaker at multiple industry events including Microsoft TechEd, VMware VMWorld, Parallels Summit, Quest Innovate, and Technology Experts Conference (TEC).

Yearly discounts and wire transfer payments

We have made it easier to pay for WSO2 Cloud services (API, Integration, Device, and Identity). When we launched initially, monthly credit card payments were the only option we provided. Now we changed two things:

1. You can pay for a year ahead and save 10% of your subscription price:

2. And, if credit card is not something that your purchasing department likes, you can get a regular invoice and pay via a wire transfer instead:

Whatever is the WSO2 Cloud service of your choice, we would like you to be able to pay for it conveniently (and save money on the way!)

OAuth and Authentication Type: Application vs Application User

On the 3rd step of editing APIs in WSO2 API Cloud, you can set required authentication type for each resource:

We have already covered None as the option to allow invoking APIs without any authentication whatsoever.  Today we will discuss the other options.

Application type means that the API will require OAuth tokens generated with client grant type. That grant type produces tokens specific to the subscription but not the end-users.

So if there is a web- or mobile application that subscribed to this API and it has multiple end-users, they will all be sharing the same token and the API backend will not “know” which end-user is invoking the API:

Application User type means that the API accepts OAuth tokens generated with password grant type. These tokens are specific to the end-user – they require not just the application key but also end-user’s username and password.

In this case, each end-user gets their own OAuth tokens even though they are using the same API subscription. API Gateway then generates a JWT token and uses it to pass application and user information to the API backend:

Application and Application User type means that both kinds of tokens are acceptable by the API.

 

 

 

Limit API access with OAuth Scopes

OAuth scopes are a great way to segregate access to APIs and data. Combined with roles they can also be a powerful way to limit who gets access to what.

Let’s have a look at how you can implement scopes in WSO2 API Cloud.

Sample API

Let’s start with a sample WorldBank API that has two resources: /countries and /indicators – both taking a code parameter:

We have it published in Developer Portal and can invoke either of them with no problem (as long as we are subscribed to the API):

Adding Scopes

Now let’s add two different scopes: one that would only give access to /countries and the other one that only gives access to /indicators.

To do this:

  1. Open the API for editing,
  2. Go to the third step (Manage),
  3. Scroll down and click the Add Scopes button:
  4.  In the Define Scope dialog box, add the wb_geo scope for geographic data:
  5. Repeat the process to add wb_eco scope to the API.
  6. Now you can see both scopes available for the API. Click the + Scope button next to the /countries resource to assign its scope:
  7. Pick Geographic data for /countries and Economic data for /indicators:
  8. That’s it: we defined two new scopes and applied them to two different REST resources. Now click Save and Publish to update the API:

Generate scope-limited OAuth token

Now if you open the API in Developer Portal’s API Console, you will see two things: resources have notes about the scopes they need and attempts to invoke them with a regular OAuth key fail:

To generate an OAuth token with the OAuth scope included:

  1. In Developer Portal (a.k.a. API Store), click Applications,
  2. In the application list, click the application which you used to subscribe to the API (for example, DefaultApplication),
  3. Click the Production Keys tab,
  4. Scroll down to the Scopes section, select the scopes you want (for example, Geographic data), and click the Re-generate button (I picked “-1” as the validity period to have a non-expiring token):
  5. Now if you go back to the API, you can use the new token and successfully invoke the API:

Adding Roles

If you want to limit scope access to particular groups of users, you follow the same procedure but this time also list the roles when adding your scopes. For example, in the screenshot below, I am limiting the wb_geo scope access to users in the researches role:

Outbound agent – firewall-friendly way to connect LDAP to the Cloud

It has just become a lot easier to connect your corporate directory to web applications. WSO2 Identity Cloud’s agent now itself initiates its connection to the cloud and thus does not conflict with firewalls or require a DMZ placement.

WSO2 Identity Cloud is a simple way to enable single sign-on (SSO) from your LDAP to your and 3rd-party web applications, and also to give end-users a nice application catalog portal to locate and access their apps. When we originally launched the offering, the cloud service was initiating all connections to the LDAP agent, and thus you had to get the agent installed on a server visible on the internet. With today’s update, you no longer have to do that.

Now, you can install the agent on any server that can get to the internet itself. You can even take your own laptop with OpenLDAP running on it, and use that to evaluate our service.

All you have to do is:

  1. Go to WSO2 Identity Cloud,
  2. Sign in,
  3. Click the Connect your user store button,
  4. Click Connect my LDAP to Cloud to download the agent:

5. Follow the instructions on the agent download page to download the agent and configure it to connect to your LDAP and your cloud account:

6. Once the cloud starts seeing the agent, your users can start using their LDAP credentials to access the applications you hooked up to the cloud:

See detailed documentation here: Configuring an On-premise User Store

Multiple endpoints per API

Dynamic Endpoint functionality of API Cloud allows you to dynamically pick the backend to which each call is routed based on the call’s properties.

For example, suppose you have an API that has two resources /countries and /regions:

And suppose the actual implementation of the functionality is at two different backends. /countries is implemented by first.backend.url and /regions by something.different.url.

Fear not, this is fairly easy to implement with API Cloud. You simply need to select Dynamic Endpoint as the Endpoint Type and upload the In Flow sequence that defines the rules to route the traffic:

In our sample scenario, the In Flow sequence might look similar to this:

<sequence name=”dynamic_ep” trace=”disable” xmlns=”http://ws.apache.org/ns/synapse“>
    <switch source=”get-property(‘To’)”>
        <case regex=”.*/countries/.*”>
            <property name=”service_ep” value=”https//first.backend.url“/>
        </case>
        <case regex=”.*/regions/.*”>
            <property name=”service_ep” value=”https://something.different.url“/>
        </case>
        <!– add endpoints as needed –>
        <default>
            <property name=”service_ep” value=”http://some.default.url”/>
            <!–default endpoint if required. However there should be a matching resource–>
        </default>
    </switch>
    <header name=”To” expression=”get-property(‘service_ep’)”></header>
    <property expression=”get-property(‘service_ep’)” name=”ENDPOINT_ADDRESS”></property>
    <!–Please note that “ENDPOINT_ADDRESS” (additional) property is defined here in order to populate
    destination address for statistics (API Usage by Destination). –>
</sequence>

You can obviously define more complex rules if needed.

Do you have multiple backend services that need to become a single API? Dynamic Endpoints can get you going!

 

Now with WebSockets

WSO2 API Cloud now fully supports publishing WebSocket APIs. WebSocket is a TCP-based protocol that is a part of the HTML5 specification, enables full-duplex communications and streaming, and reduces network traffic and delays.

In API Cloud, you can now treat WebSockets just the same way as you treat regular HTTP protocols. It is just another option when you add a new API:

The wizard then guides you through the rest of the process so you can define your policies and make the WebSocket endpoint fully managed.

If you need details, just read this API Manager tutorial that covers the functionality: Create a WebSocket API – now this page applies to API Cloud as well.

iOS Device Management

We have added iOS management capabilities to WSO2 Device Cloud. From now on, not just Android phones and tablets, but also iPhones and iPads can be put under your control.

Adding a device is easy – simply log into WSO2 Device Cloud, and click the Add button in the Devices box, then follow the wizard steps as described in this tutorial: Enrolling an iOS Device.

Once the devices are enrolled, you can use the cloud UI to locate the devices, apply policies, check compliance, send messages, and perform other management activity.

Give this functionality a try and let us know what you think!

WSO2 Device Cloud is currently in free beta. We are targeting the summer of 2017 for the commercial launch.

Custom API error messages

When API subscribers make mistakes during API invocation be it a wrong REST path, submitting an invalid OAuth key or going beyond the throttling limit – they get an error message like:

{“fault”:{“code”:900902,”message”:”Missing Credentials”,”description”:”Required OAuth credentials not provided. Make sure your API invocation call has a header: \”Authorization: Bearer ACCESS_TOKEN\””}}

We now allow WSO2 API Cloud customers to change these messages so you can have something like:

{
 “errors” {
“status”:900902,
“message”: “Make sure to pass OAuth key as Authorization Bearer. Confused? Read our documentation and samples at our.wonderful.dev.portal”
     }
}

 

Custom messages work for both JSON and XML responses.

Making the change is easy: submit a ticket via API Cloud‘s Support menu, let us know which messages you want to be changed, and our engineers will get your custom messages into the system.

This nicely affects other branding options that we have such as custom URL, custom developer portal theme, and custom emails.

Ballerina hosting in Integration Cloud

We have added the ability to host Ballerina-based services in WSO2 Integration Cloud.

Ballerina is a general purpose, concurrent and strongly typed programming language with both textual and graphical syntaxes, optimized for integration.

Ballerina has been designed for integration scenarios and the world of web services and containers – which makes it a perfect development technology for the cloud.

To host a Ballerina service, simply take the project file and upload it to the cloud as a new application:

See our tutorial on Creating a Ballerina Service.

At the moment, Integration Cloud only supports Ballerina services (not main-based programs yet). We are working on adding Main() support as well as integrating the tooling into the cloud. Stay tuned!

Download SDKs for Your APIs

WSO2 API Cloud now automatically generates and allows API subscribers and publishers to download Software Development Kits (SDKs) for any of the published APIs. SDKs are a great benefit for developers because they provide native programming libraries that give natural access to the APIs within the application code.

SDKs are available both in the Developer Portal (aka API Store) and Publisher.

Developer Portal

Inside the Developer Portal, subscribers simply need to browse to the API they need and click the SDK tab:

Publisher

Within the Publisher UI, simply open the API for editing, and then click Edit Source on the first step of the editing wizard:

You can then use the Generate Server menu to get a stub for the server-side implementation of the API:

Or Generate Client for the client-side SDK:

Availability

We have upgraded WSO2 API Cloud to the new version that contains this feature and it is available to all API Cloud users at no extra cost and with no additional configuration required.

Check it out and let us know what you think.

Categories

Recent Posts

Most Popular Posts