WSO2 Cloud Services Gateway enables organizations to share their internal services beyond their private networks and out to the public Web, securely and in a controlled manner. Mostly, it is similar to a SSH tunnel from internal machines to outside locations, but implemented at SOA interactions level.
How does it make a difference?
Before the advent of the clouds, organizations could stay within their firewalls and they had to seldom cross that boundary, if not never. However, with Cloud Computing becoming mainstream, organizations are often forced to take their computations and data outside their firewalls. Building systems using old firewall based model works as long as the applications resides either completely in cloud or inside the firewall. But new use cases in the Cloud era often mash both internal and Public services together. Moreover, with the security concerns on the cloud are rising, it is likely that organizations want to keep the data securely inside the firewalls and only selectively expose those data outside through services, thus reducing the security concerns. In this outset, we introduce WSO2 Cloud Services Gateway as a tool that enables users to build applications by mashing services from both public Clouds and internal networks together. For instance, a bank may need to do an extensive analysis that uses hundreds of compute nodes and they may selectively expose few services running in their private network to the computation securely, while using extensive security support of SOA to secure their services.
WSO2 Cloud Services Gateway consists of two parts, a server which runs in the public space and a client running in the private network. The client runs as a part of WSO2 Web Services Application Server (WSO2 WSAS). The server is based on WSO2 Enterprise Service Bus (ESB) and for each published service, the client creates a proxy service in the WSO2 ESB server. There is a secure channel created from the client (WSO2 WSAS) to the server (WSO2 ESB), and it is initiated by the client. When the server receives messages that are addressed to a client, it uses this channel to push messages to the client(WSO2 WSAS) running in the private network.
How to Use it?
Following describes how to use WSO2 Cloud Services Gateway to expose your own services running inside a firewall to outside world in a controlled manner. As described in the architecture, there are two parts to the WSO2 Cloud Services Gateway: WSO2 Cloud Services Gateway server which runs in the public network and the client which runs inside the firewall.
To try this out, we provide a Developer Edition of WSO2 Cloud Services Gateway running in https://csg.tools.wso2.org/carbon. But the users have to setup the client side for the WSO2 Cloud Services Gateway. Client side of WSO2 Cloud Services Gateway is a WSO2 WSAS instance, where users will have their services running. If users have WSO2 WSAS already installed with some services running, they can also enable WSO2 Cloud Services Gateway to WSO2 WSAS by performing same procedure with their own WSO2 WSAS.
Install WSO2 Cloud Services Gateway Client
WSO2 Cloud Services Gateway Client, which supports publishing services to WSO2 Cloud Services Gateway and manage published services, is available as an OSGI P2 provisioning feature and just like with Eclipse, the Java IDE, this feature can be installed in to WSO2 WSAS through few commands. Let us look at how it can be done.
The P2 feature artifacts are placed in WSO2 P2 repository located at https://dist.wso2.org/p2/carbon/releases/2.0.2/.
The following steps assumes that the local host has Java installed and JAVA_HOME environment variable is set.
- Download WSO2 WSAS 3.1.2 and start the server with the -DosgiConsole option
- Run the following commands in the OSGi Console to install the feature.
osgi> provaddrepo https://dist.wso2.org/p2/carbon/releases/2.0.2/
osgi> provaddartifactrepo https://dist.wso2.org/p2/carbon/releases/2.0.2/
osgi> provinstall org.wso2.carbon.csg.client.all.feature.group 1.1.0
Restart WSO2 WSAS (type Ctrl + C and then start again by running ./wso2server.sh )
Then point the Web browser to https://127.0.0.1:9443/carbon. If all goes well, you will have the following window. WSO2 Cloud Services Gateway introduces two new tabs to the left hand panel.
First click on the tab called “Cloud Services Gateway”.
The panel shows a list of WSO2 Cloud Services Gateways that this WSO2 WSAS instance is connected to and hence can publish services. Initially there are no servers configured. Click on the “Add” to add a new server. As explained before, WSO2 has setup a Developer Edition of WSO2 Cloud Services Gateway at https://csg.tools.wso2.org/carbon, and the following entries will let you add the Developer Edition of WSO2 Cloud Services Gateway as a
server to your client.
As a user name, you have to use your WSO2 Oxygen Tank user credentials. If you do not have an account, you can create a new account using https://wso2.org/user/register. Click on “Save”, once you entered the credentials, and in the list of servers that appears, click on “Connect”. Now the server has been configured.
To publish services click on “CloudServices” and for each connected server, an entry will appear.
Choose the server where you want to publish services. Then the following list will appear.
To publish a given service in to WSO2 Cloud Services Gateway, click on the publish button and it will be published to the server.
Testing the Published Service
Now we have published the HelloService in the Developer Edition of WSO2 Cloud Services Gateway running in https://csg.tools.wso2.org/carbon/. Login to Developer Edition of WSO2 Cloud Services Gateway using your WSO2 Oxygen Tank credentials and in the browser window, on the left panel, click on the “List” and then click the service you have published. You will see that the service name is appended with your user name to enable different users to publish the same service. In the service description, click on “Try This service” on the top right hand corner. A form will appear. For the Hello Service we published, the form looks like following:
Use the form to make a service call and the response will appear below.
Creating Your Own WSO2 Cloud Services Gateway
WSO2 Cloud Services Gateway also provides an Amazon Machine Instance (AMI) which you can use to create your own WSO2 Cloud Services Gateway. The AMI ID can be found in https://wso2.com/cloud/connectors/services-gateway/ and it is provided as a paid AMI. To start a new WSO2 Cloud Services Gateway instance, you may use ElasticFox (Firefox Plugin) to start a new instance. You may install the ElasticFox by visiting https://developer.amazonwebservices.com/connect/entry.jspa?externalID=609 using Firefox and clicking on the “Download” link.
After you configure your credentials through the popup that comes up at the first run, you can see available AMIs and running instances and you may create a new AMI instance by right clicking on the AMI and selecting “Launch Instances”.
When the EC2 instance starts, it starts the WSO2 Cloud Services Gateway as well. To find the location, right click on the running instance and select “Copy Public DNS to Clipboard”. You may access the Developer Edition of WSO2 Cloud Services Gateway though https://$PUBLIC_DNS/carbon.
It is worth noting that the AMI comes with a self signed certificate and for any real deployment, the user may want to replace that with their own certificates. To do this, SSH to AMI and replace /opt/csg/security/server.key and /opt/csg/security/server.cert with your own private key and certificate.
This documents introduces WSO2 Cloud Services Gateway, which enables organizations to share their internal services beyond their private networks and out to public Web, securely and in a controlled manner. We explained the main idea behind the Cloud Services Gateway and explained how users can get started with the Gateway.