Cloud Blog

Display the latest or all versions of an API

By default, API Cloud‘s Developer Portal only displays the latest published version of each API.

So once version 2.0 of an API gets published, version 1.0 gets automatically hidden from the Developer Portal (existing subscriptions still work though until you block the API.)

This way you can make sure that all your new subscribers pick the latest and greatest of your APIs. You can see the video and read more about how API lifecycle works in this tutorial.

However, all API programs are different and you might decide that you want all published versions of your APIs shown to your subscribers. To do that, you need to set the DisplayMultipleVersions flag to true as described in API Cloud’s documentation.

Notes:

  • It might take about 15 minutes before the changes apply to your store and the older versions start showing up,
  • Even with this flag, deprecated versions are still hidden. If you want API Cloud to also show deprecated APIs set the DisplayAllAPIs to true too.

 

Uptime Dashboard now includes regional gateways, Integration, Identity, and Devices Clouds

We have extended our public uptime dashboard to go beyond just API Cloud and its default gateway. From now, on API Cloud’s indicators include:

  • Web interfaces (Publisher, Admin Dashboard, Developer Portal),
  • Key Manager,
  • Developer Portal (aka API Store),
  • Regional Gateways.

Even more importantly, we now have public dashboard indicators for the other WSO2 Cloud services:

  • WSO2 Integration Cloud,
  • WSO2 Identity Cloud,
  • WSO2 Device Cloud.

For all of these, you can see whether the service is up or down at the moment, how well it performed lately, and can even drill down into uptime and performance over the last few months and get a list of all disruptions we had during the selected period:

In addition to the uptime dashboard, all paying customers get incident notification and post-mortem emails as well as maintenance announcements.

WSO2 Cloud comes with financially backed uptime SLA and our public availability dashboards and incident notification processes help ensure transparency of our quality of service and processes.

New and Improved Live Log Viewer

Debugging APIs can be a challenge when things go wrong. A lot can go unexpectedly while the calls travel from a user application to the API gateway, through transformation engine, to the backend service, and back.  Luckily, WSO2 API Cloud comes with a live Log Viewer screen and we have just released its improved version.

Whenever you want to see what’s going on under the hood of API Gateway:

1. In API Cloud, on the Configure menu, click Admin Dashboard:

2. In the API Cloud Admin Dashboard, navigate to Log Analyzer / Live Log Viewer.

3. Invoke the API that you want to troubleshoot (for example, in the Developer Portal or curl or from your application.)

4. See the log in the Log Viewer:

The new Log Viewer:

  • Has a clear visual separation of information, warning, and error messages,
  • Works across all regional gateways around the globe.

Note:

  • API call tracing is off by default, so you will likely not be able to get the detailed information on the actual API and response URLs, headers, and body. To get those, enable tracing before making the calls. Then turn tracing off when you are done troubleshooting.

 

Adding request headers to published APIs

Suppose you have a REST API and besides parameters also want to prompt subscribers for custom HTTP headers. WSO2 API Cloud makes this easy.

In the example below, we will add a custom header called setName to an existing API and invoke it from the Developer Portal.

1. In API Cloud’s Publisher interface, open the API for editing, and on the second screen (Implement), select the Enable API based CORS Configuration checkbox:

2. In the Access Control Allow Headers edit box, type the name of the header that you would like to add (in our case setName) and press Enter. Then click the Save button.

3. Now, go back to the first step of API editing (Design), open the resource that you want to request that header as a parameter, add the parameter with the name of the header, and change the Parameter Type from query to header:

4. If the API has already been published, you can just click Save to make the change go into effect. If not, go to the last step of the wizard and click the Save & Publish button there.

5. Now, you can go to the Developer Portal (also known as API Store), subscribe to the API if you have not done so yet, and expand the method that we have just modified – you will see that our new header setName is there, listed as one of the parameters:

6. When you invoke the method, you can see that the new header is indeed getting added to the API call and passed to your backend. Notice that the generated curl command example also has the new header:

That is it! WSO2 API Cloud makes it easy to design your APIs the way you want them and have them published for your consumers in a way that is intuitive and easy to understand.

Integrating OAuth API Gateway with SAML Identity Provider

OAuth2 is the modern standard of providing security for REST and SOAP APIs. However, a lot of enterprises have existing SAML Identity Providers (IdP) and that they use as their internal authentication standard. They would like their web and mobile applications to have end-users authenticate with these existing providers and then translate that to OAuth, enforce access and policies, and pass the calls to the backend.

Today we will talk about how this works in case of WSO2 API Cloud:

Configuration:

  • Configure the cloud to trust the IdP.
  • In the Developer Portal (API Store), create your application and get its OAuth consumer secret and consumer key.

Now, let’s look at the way the actual authentication and API usage happens in the diagram above:

  1. Your web or mobile app asks the end-user to log in as it normally would.
  2. Your corporate Identity Provider (IdP) checks credentials and issues the SAML2 token.
  3. Now the application needs to generate the personalized OAuth2 token for that end-user and that app. For that, it invokes the API gateway’s Token API and passes consumer secret, consumer key, and the SAML2 token.
  4. API gateway validates the SAML assertions with the IdP. If particular API Scopes are requested, the gateway also checks to see if the roles with which the scopes are associated match the roles in the SAML assertions.
  5. If validation is successful, API gateway returns the OAuth token and refresh token. The refresh token can be used to renew the OAuth token when it expires.
  6. Now the application has the OAuth token it needs and can use it to invoke the actual APIs.
  7. API gateway uses the OAuth token to identify the end-user, apply security and throttling policies, collect analytics data, and pass the calls to the backend. When the backend is invoked, end-user and application information is passed as JWT token.

That is it. See our documentation page for the specific configuration steps and token API calls, and use API Cloud’s Support menu if you need any help.

 

Categories

Recent Posts

Most Popular Posts