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).

WSO2 API Cloud in 2017

2017 was a great year for WSO2 (we are now the world’s 8th largest open-source company!), API Cloud, and our customers.

Thanks to the feedback that you provided, we have added numerous great capabilities to our cloud service. Below are just the highlights and the key new features and improvements that we have rolled out last year.

New API Design Capabilities

Advanced throttling: you can now set rate limits not just by the subscription plan but by multiple other criteria including IP addresses, headers, parameters, and JWT claims.

Native WebSocket support – now WebSocket APIs are first-class citizens in API Cloud.

Ability to have multiple backend endpoints per API and route calls on the fly based on your rules.

API Subscriber Benefits

Automated SDK generation for your APIs – API subscribers can download automatically generated SDKs for the programming language of their choice and get going developing their applications quicker.

Even more branding capabilities: you can now set your look, feel, and content not just to the Developer Portal (API Store), but also to the emails that the system sends, to the Publisher UI, and even the error messages.

Mutual SSL as a supported authentication mechanism between API clients and the gateway (and obviously between the gateway and the backend).

Cloud-Service Specific Functionality

Live log access and ability to trace the requests and their transformation for easier troubleshooting and API debugging.

Custom roles and ability to limit visibility and OAuth scopes based on them for better security design and management.

Integration with external Identity Providers and identity stores, including single sign-on for the web UIs,  ability to hook up end-user stores, and SAML integration.

Deeper integration with AWS: not only you can now have API Cloud’s gateway in any AWS datacenter of choice, you can also get API Cloud simply added to your AWS bill to simplify your accounting and vendor management.

Infrastructure Improvements

Full data encryption inside API Cloud: both in transit and at rest.

Separation between production and non-production environments for clean dev-test-production lifecycle.

Comprehensive set of our own APIs that allow you to use API Cloud programmatically and integrate it into whatever custom user interfaces and tools you develop.

 

Thank you for being a WSO2 customer and helping us innovate and advance our services!

Built-In Page Help

Happy New Year!

We have added a quick enhancement that should make API management easier for you in 2018. Now, all API Cloud pages have a context-sensitive Help button on the right-hand side:

Clicking the button, shows you the help pages that we think are most relevant to your current page:

Give the new tips a try and let us know if any useful information is missing on any of the pages!

 

 

Multiple features now included with API Cloud tiers

Today we are happy to announce that we are now bundling multiple API Cloud features (some new, some previously existing but requiring extra fees) into existing API Cloud subscription tiers at no extra cost!

Here are the features that we are adding:

Getting Traction and higher:

Medium and higher:

There are also some very exciting features in the works for Large and Extra-Large tiers so stay tuned for more announcements in January.

For our current paying customers affected by the change we will be happy to use whatever approach is the most beneficial for the customer:

  • If you are currently using a feature that is now a part of a higher tier than yours, we will let you continue to use it at your current level.
  • If you are paying for a feature that is becoming free at your tier (for example, VPN or VPC Peering at Medium and higher) we will stop charging you for the feature.

We keep looking to how we can provide more value to our customers. If you have any questions or ideas on how we can further evolve our offering please let us know.

 

Add WSO2 API Cloud to your AWS Bill

WSO2 API Cloud has a long history of integration and partnership with Amazon Web Services. Boasting 5-star rating, the service has for a long time offered comprehensive API management capabilities that go well beyond just API gateway and include analytics, real-time alerts, user management, full-featured developer portal, API monetization, integration with identity providers and user directories, and powerful on-the-fly transformation engine.

In 2016 we added the capability to have your WSO2 API Cloud gateway in any AWS datacenter of your choice and VPC peering between your AWS VPC and WSO2 API Cloud.

Today we are happy to announce that you can purchase WSO2 API Cloud right within your AWS account and simply have the service added to your Amazon bill.

If you are an existing AWS customer and want to turn your services into managed APIs and launch a full-scale API program, simply go to the API Cloud page in AWS marketplace and pick the tier that works best for your needs.

APIs to control your API Management

In WSO2 API Cloud, everything you do through the web user interface can also be done programmatically via APIs. Detailed API reference can be found in the API Cloud’s Product APIs documentation.

Today I will show you just a quick example on how you can use Publisher’s RESTful APIs to get a list of APIs published (for all other operations you would use a similar approach and simply other REST resources from the API reference).

1. Register client

1.1. Obtain your organization-qualified ID

The first thing we need to do is register our API client and obtain the consumer ID and consumer secret values.

The most important piece of information that you need for that is your domain-qualified ID in WSO2 Cloud. This is your email address @ your Organization Key. You can find your Organization Key by clicking Organization on the 9-dot menu at the top right of the cloud interface.

For example, on the screenshot below, my Organization Key is wso2dmitry2639:

With my email address dmitry@wso2.com, this gives me the qualified ID of dmitry@wso2.com@wso2dmitry2639.

1.2. Create registration json

This is just a payload.json file that would have the ID that you have just obtained. In my case that would be:

{
  "callbackUrl": "www.wso2.com",
  "clientName": "rest_api_publisher",
  "tokenScope": "Production",
  "owner": "dmitry@wso2.com@wso2dmitry2639",
  "grantType": "password refresh_token",
  "saasApp": true
}

Save that text file as payload.json.

1.3. Encode your credentials

Now you need to take the qualified ID from step 1.1, add a colon (:), add your password and do Base 64 encoding for that string. For example, if my password was P@ssw0rd, I would have needed to encode dmitry@wso2.com@wso2dmitry2639:P@ssw0rd and that would have given me: ZG1pdHJ5QHdzbzIuY29tQHdzbzJkbWl0cnkyNjM5OlBAc3N3MHJk

1.4. Register the client

Now you can just run this curl command in the folder that has your payload.json from step 1.2:
curl -X POST -H "Authorization: BasicZG1pdHJ5QHdzbzIuY29tQHdzbzJkbWl0cnkyNjM5OlBAc3N3MHJk" -H "Content-Type: application/json" -d @payload.json https://api.cloud.wso2.com/client-registration/v0.11/register/

This will give you an output like:

{
  "clientId":"O7buGR5fMVMuNBFF",
  "clientName":"dmitry-AT-wso2.com_rest_api_publisher",
  "callBackURL":"www.wso2.com",
  "clientSecret":"A3mYNQjHDsXX_T1",
  "isSaasApplication":true,
  "appOwner":"dmitry@wso2.com@wso2dmitry2639",
  "jsonString":"
     {
         \"grant_types\":\"password refresh_token\",
         \"redirect_uris\":\"www.wso2.com\",
         \"client_name\":\"dmitry-AT-wso2.com_rest_api_publisher\"
     }"
}

This response has everything we need: clientId is your consumer key and clientSecret is your consumer secret.

2. Obtain OAuth token

2.1 Encode consumer key and consumer secret

Now we need to take the clientId and clientSecret values, put a colon between them, and base 64 encode that string. In my case, I need to encode O7buGR5fMVMuNBFF:A3mYNQjHDsXX_T1.

When I do that, I get TzdidUdSNWZNVk11TkJGRjpBM21ZTlFqSERzWFhfVDE=

2.2 Find your scope

In the documentation page for the method you want to call, find which scope it needs. I just want to use Retrieve/Search API and this method requires apim:api_view scope.

2.3 Request the token

Now you have everything you need to get the OAuth token. Simply run this (with your own ID, encoded keys, and scope):

curl -k -d "grant_type=password&username=dmitry@wso2.com@wso2dmitry2639&password=P@ssw0rd&scope=apim:api_view" -H "Authorization: BasicTzdidUdSNWZNVk11TkJGRjpBM21ZTlFqSERzWFhfVDE=" https://gateway.api.cloud.wso2.com/token

You then get a response like that:

{
  "access_token":"89c12aab-6f0e-3c3b-8409-d186670ec73c",
  "refresh_token":"2cba2b65-d56a-25a7-a742-1a12345d123",
  "scope":"apim:api_view",
  "token_type":"Bearer",
  "expires_in":3600
}

access_token is the OAuth key you can use for your calls.

3. Use the APIs

Now you can just take that access token and use it with the API call that you pick from the reference page. In my case, for the token that I got, to get a list of all APIs, I would call:

curl -k -H "Authorization: Bearer 89c12aab-6f0e-3c3b-8409-d186670ec73c" https://api.cloud.wso2.com/api/am/publisher/v0.11/apis

I then get a response like:

{"count":1,
"next":"",
"previous":"",
"list":[
  {"id":"50b7213d-21d2-1234-840c-34e12d778a61",
  "name":"WorldBank",
  "description":"Country data API",
  "context":"/t/wso2dmitry2639/wb",
  "version":"1.0.0",
  "provider":"dmitry@wso2.com@wso2dmitry2639",
  "status":"PUBLISHED",
  "thumbnailUri":"/apis/50b7213d-21d2-1234-840c-34e12d778a61/thumbnail"}
]
}

For my tutorial, I picked just one simple call to list the APIs. Full reference has dozens of methods that you can use to completely bypass our user interfaces and perform any API management operations programmatically.

Check out API Cloud’s Product APIs documentation and let us know what you think.

Put your SOAP to REST

API management is about selectively, securely, and conveniently exposing internal functionality to the outside world. Quite often external consumption model and internal representation of APIs do not match and this is when API gateways shine efficiently translating one representation into the other on the fly.

Exposing SOAP web-services of internal enterprise systems as lightweight external REST APIs is a very frequent case of that. Here’s what it looks like:

  1. External REST API is called. Parameters are typically passed as parts of the URL path, query parameters, headers, or JSON payload. Authentication typically happens via OAuth2.
  2. API gateway receives the call, checks OAuth keys, enforces various policies such as throttling and scopes, records the call for analytics and monetization purposes, and creates a SOAP call with the new payload based on expected format and parameters, then passes the call to the backend.
  3. The backend would typically use some other form of authentication such as basic or digest authentication, mutual SSL, and IP whitelisting.
  4. When the backend responds, the gateway would do another transformation of the response to the format that the web or mobile client expects – typically JSON.

WSO2 API Cloud makes this process easy and efficient. See our documentation for details:

See also this blog post by Shenavi:

Multiple CNAME records within a single gateway

Your APIs can work with multiple backends and route calls to them based on different headers, REST resources, or even parameter values. Today we are expanding this functionality to routing based on multiple gateway URLs so the same API can, for example, serve production, development, and test environments picking the appropriate one based on the URL used for the invocation.

Typically, all your APIs share the same base URL of the gateway that you can set to a particular custom URL of your choice such as apis.example.com.

Also, starting with the Medium plan, API Cloud allows you to have multiple gateways. This is typically used by API publishers who want to have separate API gateways for different regions (for example, us.apis.example.com, eu.apis.example.com, apac.apis.example.com).

That same functionality can now be used within the same physical gateway to provide different URLs for different backend environments such as prod.apis.example.com, dev.apis.example.com, and qa.apis.example.com. In that case, you can assign them all to the same API gateway and then use the Dynamic Endpoint type to route the calls to the corresponding backend environments based on the URL used by the caller.

How API Gateway constructs URLs and translates them to backend calls

The URLs that your APIs have when hosted in API gateway and exposed to the world are different from the URLs of the backend services. Today we will explain how API gateway translates the calls that it gets into what it invokes and how each piece of that URL can be modified.

We will be looking at a simple case of one-to-one translation when you just want to pass parameters and values to the backend as they are (you can modify them on the fly too – see some links at the end of the post):

  1. API subscriber invokes something like apis.example.com/directory/1.0/users?identifier=123,
  2. If apis.example.com is associated with your organization in API Cloud, the API gateway receives the call,
  3. From the API context (directory) and version (1.0), the gateway identifies which API it should be calling,
  4. The gateway “knows” the Production Endpoint for that API (or Sandbox Endpoint if that is what is being invoked),
  5. It takes that endpoint and appends the resourceparameters, and values to it.
  6. The gateway then passes that call to the backend.

Let’s look at the elements of the API URL that the subscriber is invoking in the cloud:

  • API gateway URL (in our example, apis.example.com) is the URL part that all your APIs will share. By default, API Cloud will assign you something like gateway.api.cloud.wso2.com:443/t/orgid/ – but you can easily change it to your own custom URL,
  • Context is the URL path of that specific API (in our example, directory). All the REST resources of this API will share it (for example, directory/users directory/books, directory/groups). You specify that value on the first step of API design, right after the user-friendly name:

  • Version is defined on that same step, right after the Context. If you do not want the version to be a part of your API URL at all, you can select the Make this the default version checkbox on the 3rd step of API editing:

  • Resource is the HTTP noun that you use (users, books, groups, and so on). Just provide the name on the first (Design) step of API design in the URL Pattern box, select the HTTP methods you want to allow for this resource, and click the Add button:

  • Path parameters (for example, /users/123) get added in curly brackets right within the URL Pattern box (for example, /users/{identifier}). Query parameters (for example, /users/?identifier=123) get added by expanding the API resource that you just added, typing the parameter name in the Parameters box, and clicking the Add Parameter button (see the picture below). You can then change the type of that parameter from query to header or formData.

  • The values of the parameters will be provided by API users when invoking the APIs,
  • Finally, we need to specify the backend base path for the API. On the second step of API design (“Implement”), select the Managed API option, and type the backend URL into the Production Endpoint edit box:

See also: If you want to also do some call transformations on the fly, here are a few additional posts on how to do that:

Authenticate End-Users for APIs: LDAP, AD, SAML, Database, Web-Service

APIs are often the backbone of the functionality used by mobile and web-applications. These applications in their turn often need to “know” end-user identity to provide personalized service: end-user-specific data, permissions, access, and so on. How do you get API Gateway to verify that the user is who she claims she is, let her use the API, and pass her identity to the backend?

We have now made it easy with Configure / External Users / API Consumer Authentication configuration screen:

The following options are available:

1. Using existing SAML Identity Provider

Use this option if your application is already SAML-enabled, authenticates with an existing SAML provider, and now just needs to use that SAML token to access the APIs.

The configuration dialog box will ask you for the SAML provider details. Once the configuration is applied, your application will be able to use the SAML Grant Type to get API access OAuth token. When that token is used, JWT with the user identity information will be passed to the backend.

See our SAML Grant Type documentation for details.

2. Directly connecting to an LDAP userstore

If your LDAP directory is visible to API Cloud (for example, you have set up a VPN connection):

  1. Select the Connect your LDAP User Store option,
  2. Clear the Outbound agent configured checkbox,
  3. Specify LDAP connection parameters.

Once the configuration is live, your application will need to use the Password Grant type to get the OAuth token. API Gateway will verify the end-user identity against the LDAP and generate a personalized OAuth token. Each time the end-user accesses the APIs, the gateway identifies the user and passes the user details to the backend via JWT.

See this documentation for details.

3. Connecting to LDAP/AD via Identity Cloud

If your LDAP or Active Directory (AD) is behind a firewall and you do not want to have direct connectivity with it you can use WSO2 Identity Cloud to connect to the directory:

  1. Sign-up for WSO2 Identity Cloud and use its agent to hook up the directory,
  2. In API Cloud’s Configure / External Users / API Consumer Authentication screen, select the Connect your LDAP User Store option,
  3. Leave the Outbound agent configured checkbox selected.

This is sort of a combination of the previous two cases: API gateway is using Identity Cloud as the identity provider to authenticate the user. After which a personalized OAuth token is granted.

See this documentation for details.

4. Verifying user identity via a custom web service

If your end-users are stored in some sort of database or another system that you can expose via a web-service – select the Connect your RESTful Authentication Service option and provide the connection details.

By default, API cloud will be trying to authenticate end-users with a POST invocation with the following JSON payload:

{
	"credentials": {
		"username": "userx",
		"password": "mypass"
	}
}

If the end-user record is valid, API Cloud expects a response with the following JSON:

{
	"response": {
		"status": "true"
	}
}

These formats, however, can be changed using the configuration dialog box.

If the verification is successful, personalized OAuth token is granted for API access, and each API invocation comes with the user-specific JWT token.

See this documentation for details.

 

API Cloud is a powerful and flexible API management system. Should you have any questions, just click the Support menu and we will be happy to help.

Single Sign-On into API Cloud UI

WSO2 API Cloud is a web-based API management suite but you can now also use your corporate identity system to log into its web user interfaces!

To configure the integration, click External Users on the Configure menu:

You can then select one of the two ways to integrate:

  1. Direct integration with your Identity Provider (IdP), or
  2. LDAP or Active Directory integration via WSO2 Identity Cloud.

Here’s a quick overview of how these work.

Integration with an Identity Provider (IdP)

If you already use an identity provider such as Shibboleth, Google Apps, or ADFS, simply pick the corresponding provider from the dropdown list and supply the additional parameters:

WSO2 API Cloud will then start using this IdP to get users authenticated into the Publisher, Admin, and API Store user interfaces:

See our documentation for more details: Configure an External Identity Provider for API Cloud Authentication.

LDAP or Active Directory integration via WSO2 Identity Cloud

In this case, you use WSO2 Identity Cloud agent to get your local directory server connected to WSO2 Cloud.

You then simply tell API Cloud which local groups need to be mapped to which roles in API Cloud: who will be able to publish the APIs, subscribe to them, and so on:

See this documentation for details:Configure an On-Premise User Store for API Cloud Authentication.

Single Sign-On (SSO) makes your API management easier to use and more secure. Try it today in WSO2 API Cloud.

Categories

Recent Posts

Most Popular Posts