Cloud Blog

How to Recover Your Production Deployment from a Last Minute Mistake

You projects that are running in WSO2 Integration Cloud can have multiple versions. You can select which of the versions own the default URL and work on the versions in parallel. This means that your version 1.0 may be retired, 2.0 may be in production, 3.0 may be going through QA, and 4.0 may be in early development.

In addition, our newly released feature allows you to update your projects within the same version without changing the numbering. This is great for small incremental improvements and has built-in rolling update and roll-back functionality.

  • How do you update a version?

In the home page of your application, choose the correct version where the update is needed as shown in the figure 1 below. In this example it is version 2.0. Then click Update.

You can update the version via a local file system, URL or a Github repository.

Then you need to upload your artifact along with the update comment. This update comment helps you to track your updates per version.The update option enables you to update multiple times per version and it gives you the opportunity to revert the artifact to the previous state if you want.

  • How can you revert the version to its previous state?

Once you update an artifact you can see the Update or Rollback option in the homepage. Clicking on that button gives you access to page shown as below.

Choose the correct artifact that you want to revert to and click the Apply button. This will revert your current version to the previous artifact. Now you don’t have to worry about maintaining a large number of versions when fixing urgent issues in your production deployment. With WSO2 Integration Cloud, it’s just a small update to your existing version!

Read our documentation for more information on WSO2 Integration Cloud.

 

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.

Categories

Recent Posts

Most Popular Posts