Cloud Blog

Global API Gateways

Want to host your APIs in Europe, Asia or South America? We are now starting to let API Cloud customer select regional gateways around the globe to which they want to publish their APIs.

Why

When API Cloud launched initially there was only one location – AWS US East datacenter – in which you could publish your APIs. This has been a problem for some of our global customers for two reasons:

  1. Regulations: while API gateway does not store any end-user data and is merely enforcing policies and passing the calls to the backend, some companies would like to be on the safe side in terms of compliance and keep not just the backend but also the gateway within their jurisdiction,
  2. Performance: if both your backend service and your subscribers are in Australia, having the gateway in the US adds the extra hop to the other side of the globe and the corresponding wait for API consumers.

Today we are excited to announce the availability of API Cloud across the globe.

Where

The following datacenter locations are available:

  • US East,
  • US West,
  • Canada,
  • Brazil (São Paulo),
  • EU (Ireland),
  • EU (Frankfurt, Germany),
  • UK (London),
  • Singapore,
  • Tokyo, Japan,
  • Sydney, Australia,
  • Seoul, South Korea,
  • Mumbai, India.

Depending on your API Cloud subscription level, you are able to pick the datacenters that would host your APIs:

Starter Getting Traction Medium Large Extra Large
$129 $298 $698 $2,980 $9,980
US East only Pick any datacenter of choice Up to 3 datacenters Up to 7 datacenters Unlimited number of AWS datacenters of choice

Global API gateways: US, South America, Asia / Pacific, Europe

How it works

  1. You submit a request by filing an API Cloud support ticket and tell us in which regions you would like your gateway to be placed and the custom URL you would like to be used,
  2. We work with you on configuring DNS. The following options are available:
    • All traffic by default routed to a specific regional gateway: for example, a European company might decide that all traffic should go through a gateway in EU.
    • Traffic is routed based on geographic location: European consumers are routed to European hub, Australian – to Australian, and so on.
  3. In addition to this default routing, we can set up gateway URLs specific to regional gateways so you can give your subscribers direct URLs to target your API gateways in the US, Europe, Brazil, Australia, Singapore, India, China, and so on.

Pricing and Availability

There is no extra cost for this feature as long as the number of datacenters you use is within the limits of your subscription level.

The feature is available now to all paying API Cloud customers.

Getting Started

If you are interested in having your APIs hosted in datacenters other than US East – just click the Support menu in API Cloud and let us know. We will be happy to make this configuration change for you.

End-User Authentication via API Gateway

[UPDATE] Besides LDAP and web-service authentication, API Cloud now supports authentication via external Identity Provider (IdP) and WSO2 Integration Cloud. See the documentation for details: Authenticate External Users for API Invocation.

Quite often APIs need to be invoked on behalf of particular end-users. For example, a typical mobile application would ask the user to authenticate and then serve the data depending on who that user is.

These end-user identities are different from the engineers who publish the API (Publishers) and the ones who subscribe to the API to develop the application invoking it (Subscribers, developers.)

Let’s look into how WSO2 API Cloud supports that scenario:

 

Secondary identity store used in API invocation

 

  1. The application first invokes Token API, passing end-user username and password.
  2. API Gateway checks whether the user exists in the primary userstore (engineers who work with the API: publishers and subscribers), if not, it checks whether there is a secondary userstore, and if the one is registered with this organization, Gateway is making the call to check if the username and password are valid.
  3. Userstore performs the check and reports success or failure.
  4. If authentication is successful, Gateway generates the OAuth token and passes it back to the application.
  5. For all subsequent actual API calls, the application passes the OAuth token in the Authorization header.
  6. Gateway checks the token to authorize the call and passes to the backend user identity information in the form of a JWT token.

Here are the technical details on making this work:

Connecting End-User Identity Store to the Gateway

Application backends typically already have some sort of LDAP store or database that stores the end-user credentials. There are two ways you can get it connected to the cloud gateway:

  1. If the userstore is LDAP (for example, OpenLDAP or Microsoft Active Directory) you can get it connected directly by supplying the access URL and credentials,
  2. For everything else, you need to provide an authentication web-service that can perform the check.

If you are using the web-service option, it needs to expect a POST invocation with the following JSON payload:

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

If the enduser record is valid, the web-service should respond with the following JSON:

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

Notes:

  • The web-service should obviously itself be protected with username and password.
  • If your existing authentication webservice is using a different JSON format, this can be used too, we just need to configure the parameters to work with your schema.
  • If the userstore is behind firewall and cannot be exposed to the cloud directly, we support various secure ways of doing so including VPN, reverse proxy services in DMZ and so on.

Token API

Token API of the cloud gateway is documented here.

For a particular application, you can easily get the right call generated for you right in API Cloud’s Developer Portal (API Store), by going to the My Subscriptions tab,  clicking the cURL dropdown, and selecting GrantType: Password:

Token API password grant type

Note:

  • When passing username in the token request, take the username that the user has in your system and add @ and the organization name that you have in WSO2 Cloud. For example, if the username that user has in your database is userx and your organization name in WSO2 is my_company, then instead of <USER> in the screenshot above you would pass userx@my_company.

JWT Token

The final step in the scenario, is decoding user identity information in your backend code. This is passed with each call in the form of JWT token.

Here is the sample JWT token. The enduser identity is passed in the “http://wso2.org/claims/enduser” property:

{
    "typ":"JWT",
    "alg":"NONE"
 }{
    "iss":"wso2.org/products/am",
    "exp":1345183492181,
    "http://wso2.org/claims/subscriber":"user.email.com@org",
    "http://wso2.org/claims/applicationname":"app2",
    "http://wso2.org/claims/apicontext":"/placeFinder",
    "http://wso2.org/claims/version":"1.0.0",
    "http://wso2.org/claims/tier":"Silver",
    "http://wso2.org/claims/enduser":"jane"
 }

Ready to Get Started?

On the Configure menu, click External Users, and then select the options you need on the API Consumer Authentication tab. See Authenticate External Users for API Invocation for details.

WSO2 API Cloud Switching to TLS 1.1 and 1.2

use-lock-98613_960_720If you are relying on TLS 1.0 – please make urgent changes to switch to version 1.2. See details below.

Transport Layer Security (TLS) is the encryption protocol used for secure communications between your API clients and API Gateway, as well as between the gateway and your service backend. TLS is also sometimes referred to as SSL – the protocol that preceded it.

There are 3 versions of TLS available at the moment: 1.0, 1.1, and 1.2. Both sides of the encryption channel can support any combination of these and negotiate the highest common standard at the beginning of the communication.

TLS 1.0 is the oldest version and is vulnerable in many implementations to well-known attacks such as BEAST and POODLE. There’s also some crypto issues in TLS 1.0, such as cryptographic initialization vectors (IVs) being predictable in some implementations as well.

WSO2 API Cloud supports all 3 versions: 1.0, 1.1, and 1.2 – and we highly recommend that you switch to TLS 1.1 or 1.2 on your side to ensure secure communications. TLS 1.2 is strongly recommended as the latest and the most secure version.

We will be disabling TLS v1.0 completely in January 2017.

Please start your work on switching to TLS 1.2 (or at least 1.1) in both your client and backend communications.

To make your readiness testing easier, we are making available a sandbox gateway (sandbox-gateway.cloud.wso2.com) that only supports TLS 1.1 and 1.2.

For backend communications:

  1. See your server manual for information on TLS configurations and configure it to use the latest possible version of TLS.
  2. Then test the communications by replacing gateway.api.cloud.wso2.com with sandbox-gateway.cloud.wso2.com in your API call. If this succeeds you are fully secure and ready for TLS 1.0 decommissioning.

For client communications:

  1. Switch to the client technology version that supports the latest version of TLS (1.2 is recommended, 1.1 is not recommended but will remain supported for now). See the table below for details.
  2. Then test the communications by replacing gateway.api.cloud.wso2.com with sandbox-gateway.cloud.wso2.com in your API call. If this succeeds you are fully secure and ready for TLS 1.0 decommissioning.
Library        TLS 1.1/1.2 Compatibility Notes
Java 8 (1.8) and later Compatible by default
Java 7 (1.7) See Java documentation to enable TLS 1.1 and TLS 1.2
Java 6 (1.6) and earlier Not compatible with TLS 1.1 or later encryption
.NET 4.5 and later Compatible by default
.NET 4.0 TLS 1.2 not enabled by default. To enable TLS 1.2, it is possible to set the SchUseStrongCrypto DWORD value in the following two registry keys to 1, creating them if they don’t exist: “HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v4.0.30319″ and “HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\v4.0.30319″.
.NET 3.5 and earlier Not compatible with TLS 1.1 or later encryption
Python 2.7.9 and later Compatible by default
Python 2.7.8 and earlier Not compatible with TLS 1.1 or later encryption
Ruby 2.0.0 TLS 1.2 is enabled by default when used with OpenSSL 1.0.1 or later. Using the :TLSv1_2 (preferred) or :TLSv1_1 symbols with an SSLContext’s ssl_version ensures TLS 1.0 or earlier is disabled
Ruby 1.9.3 and earlier The :TLSv1_2 symbol does not exist in 1.9.3 and earlier. It can be patch to add that symbol and compile Ruby with OpenSSL 1.0.1 or later
Windows Server 2008 R2 and later Compatible by default
Windows Server 2008 and earlier Not compatible with TLS 1.1 or later encryption
OpenSSL 1.0.1 and later Compatible by default
OpenSSL 1.0.0 and earlier Not compatible with TLS 1.1 or later encryption
Mozilla NSS 3.15.1 and later Compatible by default
Mozilla NSS 3.14 to 3.15 Compatible with TLS 1.1, but not with TLS 1.2
Mozilla NS 3.13.6 and earlier Not compatible with TLS 1.1 or later encryption

Please contact us if you have any questions.

Categories

Recent Posts

Most Popular Posts