Tuesday, January 24, 2017

Encrypting passwords in WSO2 APIM 2.0.0

WSO2 products support encrypting passwords which are in configuration files using secure vault.
You can find the detailed documentation form here of how to apply secure vault to WSO2 products.

This post will provide you the required instructions to apply secure vault to WSO2 APIM 2.0.0.

1. Using the automatic approach to encrypt the passwords given in XML configuration files.


Most of the passwords in WSO2 APIM 2.0.0 are in XML configuration files. Therefore you can follow the instructions given in here to encrypt them.



2. Encrypting passwords in jndi.properties file and log4j.properties files.


As did in above section, the passwords in XML configurations can be referred in cipher-tool.properties file via Xpaths. Therefore cipher-tool can automatically replace the plain text passwords in XML configuration files.

However, passwords in files such as jndi.properties file and log4j.properties filee need to be manually encrypted.

  • Encrypting passwords in jndi.properties file.
Since passwords in jndi.properties file are embedded into the connection URLs of connectionfactory.TopicConnectionFactory and connectionfactory.QueueConnectionFactory, we have to encrypt the complete connection URL. 

Assume that I have my connection URLs as below.


connectionfactory.TopicConnectionFactory = amqp://admin:admin@clientid/carbon?brokerlist='tcp://localhost:5672'

connectionfactory.QueueConnectionFactory = amqp://admin:admin@clientID/test?brokerlist='tcp://localhost:5672'

First I will be encrypting the connection URL of connectionfactory.TopicConnectionFactory.
For that I am going to execute ciphertool which will prompt me to enter the plain text password.

So I gave amqp://admin:admin@clientid/carbon?brokerlist='tcp://localhost:5672'

It returned me the encrypted value as below.



Now I have to update the cipher-text.properties file with the encrypted string as below. As the alias I used connectionfactory.TopicConnectionFactory

connectionfactory.TopicConnectionFactory=hY17z32eA/AWzsGuJPf+XNgd5YkhgYkAgxse/JoPIUmxDMl6XnDen+JN7319tRS8aYLN1LcKOgOpUpbm9DAKfm/zXXGdLPLb7QzCCabkAXEtiloH02jMyNYjvUd9cLFksNojaJyZT6c5j4Je4niRuRjr/scyhzBsQ6L3HHJ5hkQ=

Similarly I encrypted the connection URL of connectionfactory.QueueConnectionFactory and updated the cipher-text.properties file.

connectionfactory.QueueConnectionFactory=c3uectqczNf28SOTW3IFYcj4Sk6ZhdXaFd1ie44XCvA4q4McKFGn1FdicscVvXTD2pp8zVZkDoFE3PQ23J85+QoCOy7jICfLwagkbqi8fSlJcjorhMEOzMJ7xgzFrEJ/AnOHHJqw3vsh/NU13wG3dNy0QRkfYWzQWmfp+i9HeL0=

Then I have to modify the jndi.properties file with the alias values instead of the plain text URLs. For that update it as below.

connectionfactory.TopicConnectionFactory = secretAlias:connectionfactory.TopicConnectionFactory

connectionfactory.QueueConnectionFactory = secretAlias:connectionfactory.QueueConnectionFactory

  • Encrypting passwords in log4j.properties file.
Similar to above we can encrypt the password of log4j.appender.LOGEVENT.password in log4j.properties file and add the encrypted string to cipher-text.properties and update the log4.properties file with the alias.

log4j.appender.LOGEVENT.password=secretAlias:log4j.appender.LOGEVENT.password


That's it. 

Now when you start the server, provide the keystore password which will be used to decrypt the passwords in run time.


Friday, August 5, 2016

Dynamic Endpoints in WSO2 API Manager 2.0.0

WSO2 APIM 1.10.0, we have introduced new feature to define dynamic endpints through synapse default endpoints support. In this blog article, I am going to show how we can create an API with dynamic enpints in APIM.

Assume that you have a scenario where depending on the request payload, the backend URL of the API differs. For instance, if the value of "operation" element in the payload is "menu", you have to route the request to endpoint1 and else you need to route the request to endpoint2.


{
 "srvNum": "XXXX",
 "operation": "menu"
}

In APIM, dynamic endpoints are achieved through mediation extension sequences. For more information about mediation extensions refer this documentation.

For dynamic endpoints we have to set the "To" header with the endpoint address through a mediation In-flow sequence. So let's first create the sequence which sets the "To" header based on the payload. Create a file named dynamic_ep.xml with below content.


  
   
   
   

Supporting Destination based usage tracing for dynamic endpoints.
In here note that we have to set "ENDPOINT_ADDRESS" additional property with the "To" header value which is required for populating destination address for statistics (API Usage by Destination). So if you have statistics enabled in your APIM setup, you have to set this property as well with the endpoint value in order to see the destination address in the statistic views.

Now let's assign this sequence to the API. For that go to the "Implement" tab of the API creation wizard.

  • Select "Dynamic Endpoint" as the "Endpoint Type"
  • Upload dynamic_ep.xml to the "In Flow" under message mediation policies. 
  • Save the API

Now let's try out the API.

With Payload containing "menu"



Wire log showing request going to endpoint 1.


With Payload NOT containing "menu".


Wire log showing request going to endpoint 2.

This way you can write your own logic using mediation extensions and dynamic endpoints in APIM to route your requests to dynamic destinations. 

Thursday, January 15, 2015

How to invoke APIs in SOAP style in Swagger

WSO2 API Manager has integrated Swagger to allow API consumers to explore APIs through a interactive console which is known as 'API Console'

This swagger based API Console supports invoking APIs i REST style out of the box. So this post going to show how we can invoke APIs in SOAP style in API console of WSO2 API Manager 1.7.0. For that we need to do few extra configurations.

1. Send SOAPAction and Content-Type header in the request
2. Enable sending SOAPAction header in the CORS configuration



First create an API for a SOAP Service. In this example I am using HelloService sample SOAP service of WSO2 Application Server. This HelloService has a operation named greet which accepts a payload as below.


   
   
      
         
         lakmali
      
   


1. Create API



Figure-1 : Design API 


Figure-2 : Implement API by giving SOAP endpoint


Figure-3 :Save and Publish API



2. Update Swagger API Definition


Now we have to edit the default Swagger content and add SOAPAction and Content-Type header. For that go to 'Docs' tab and click 'Edit Content' for API definition.


Figure-4: Edit Swagger API definition

Since we have to send a payload in the request, locate the POST http method in the content. Then add below content into the 'parameters' section of POST http method. 

{
                            "name": "SOAPAction",
                            "description": "OAuth2 Authorization Header",
                            "paramType": "header",
                            "required": false,
                            "allowMultiple": false,
                            "dataType": "String"
                        },
                        {
                            "name": "Content-Type",
                            "description": "OAuth2 Authorization Header",
                            "paramType": "header",
                            "required": false,
                            "allowMultiple": false,
                            "dataType": "String"
                        }


Then the complete POST HTTP method definition would look like below.


Figure-5: Edited Swagger API definition

After doing the above changes Save & Close.

Now if you go to API Store and click on the created API, and the go to API Console, you should see the SOAPAction and Content-Type fields are added to the Swagger UI.


Figure-6: API Console with new header parameters

3. Add New Headers to CORS Configuration


Although we have added required headers, those will be sent in the request oly if they are set as allowed headers in the CORS configuration.

For that open APIM_HOME/repository/conf/api-manager.xml file and locate CORSConfiguration. Then add SOAPAction in to available list of Access-Control-Allow-Headers as below (Content-Type is added by default, So we have to only add SOAPAction). 


Figure-7: API Console with new header parameters

After adding the headers, restart the api manager and invoke the API through API Console. 
When invoking the API, set the SOAPAction according to your SOAP service. Also set the COntent-Type header as 'text/xml'


Figure-8: API Console Invoke API


If you face any issues with swagger invoke, please go through this.

Saturday, December 27, 2014

Multi Tenant API Management with WSO2 API Manager - Part 2




In the previous post we discussed what is multi-tenancy, multi-tenancy in API Development and multi-tenancy in API Store(Consumption). In this post we will be discussing how subscriptions can be managed among multiple tenants, how APIs an be published into different tenant domains, multi-tenancy in API Gateway, multi-tenancy in Key Manager and also multi-tenancy in API Statistics. 

Manage subscriptions among multiple tenants

In the previous post we discussed how different tenants can develop and consume APIs in isolated views of API Publisher and API Store.This section describes how API creators can control who can subscribe to an API. In the Add API page, under Subscriptions you can select the Subscriptions Category.

There are 3 subscription categories.

  1. Available to current Tenant Only

The API will be allowed to subscribe for users in current tenant domain only(tenant domain of API Creator).

  1. Available to All the Tenants

The API will be allowed to subscribe for all the tenants in the deployment.

  1. Available to Specific Tenants

The API will be allowed to subscribe for specific tenants who are mentioned and the current tenant.

Example: UserProfileAPI is an API in hr.com. API developer from hr.com tenant domain set the subscription category of UserProfileAPI to sales.com and eng.com subscribers as below.

figure-6.png


Figure 1 : Subscription availability to specific tenants

Now a Subscriber from eng.com can login to his API Store and then access hr.com API Store. He will be able to subscribe to UserProfileAPI.

Although API subscription can be allowed to different tenant domains, this approach have a drawback. Because API subscribers need to login to own (eng.com) tenant store, then browse hr.com store and discover UserProfileAPI. How can we make UserProfileAPI visible in eng.com Store ? Let’s see in the next section.

Publishing APIs to multiple tenant stores

WSO2 API Manager allows API developers to publish APIs to external stores. BY default, when a tenant user publishes an API, it is getting published in that tenant’s own API Store. With this ‘Publishing to external stores’ feature, each tenant can configure set of external stores that they wish to publish APIs. Then API developers can push APIs to those configured different tenant stores. This allows them to expose APIs to a wider community.

However, when subscribing to such APIs, users will be redirected to original publisher's store.


publish-to-external-stores.png

Figure 2 : Publish to multiple tenant stores

We can configure external stores as below.

1. Login to API Manager management console (https://:9443/carbon) as hr.com admin and select Browse menu under Resources.

resources-browse.png
2. The Registry opens. G o to /_system/governance/apimgt/externalstores/external-api-stores.xml resource.

registry-browse.png

3. Click the Edit as Text link and change the element of each external API store that you need to publish APIs to. 

Example: HR department configure external stores for Sales and Engineering departments as below. So that UserProfileAPI can be pushed into sales.com and eng.com API Stores.  

Figure 3 : External store configuration

figure-9.png

Figure 4 : External API Stores in API Publisher

As shown in the figure 9, hr.com API Publishers can push UserProfileAPI into Engineering Store and Sales Store from the ‘External API Stores’ tab.

Example: admin@hr.com publishes the UserProfileAPI into Engineering Store and Sales Store. When a subscriber from eng.com clicks on UserprofileAPI, there is a link to access original Store.

figure10.png

Figure 5 : UserProfileAPI appearing in eng.com Store

Figure-11.png
Figure 6 : Link to Publisher Store (hr.com store)

Multi-Tenancy in API Gateway

Above we discussed the Multi-Tenant features supported in API Store and API Publisher. There we saw how we can achieve isolation in API development and consumption. Further, how API subscriptions can be managed among tenants and how APIs can be published to different tenant domains were discussed. In this section, let’s look at how Multi-Tenancy is achieved API Gateway and Key Manager level.

In WSO2 API Manager, the API gateway is a simple API proxy that intercepts API requests and applies policies such as throttling and security checks. These API proxies are deployed in WSO2 API Manager as Synapse REST resources. In a multi-tenant deployment, APIs are deployed in tenant isolated manner by having isolated deployment spaces for each tenant. Also APIs are exposed with tenant domain based URL patterns as below.

Example:  We created UserProfileAPI in hr.com domain and ArticleFeeds API in eng.com domain. In the API Gateway these APIs are deployed in different spaces. Also APIs are exposed with tenant domain based URLs with /t/. So as shown in below, UserProfile API is exposed as http://gateway.cin/t/hr.com/userprofile/1.0.0. On the other hand, ArticleFeeds API is exposed as http://gateway.cin/t/eng.com/articlefeeds/1.0.0. Now when Application developers are consuming these APIs from different domains, they’ll see these tenant based API Endpoint URLs.

Figure 7 : Multi-tenancy in API Gateway level

Multi-Tenancy in API Key Manager

The API Key Manager component handles all security and key-related operations. When API Gateway receives API calls, it contacts the API Key Manager service to verify the validity of tokens and do security checks. All tokens used for validation are based on OAuth 2.0.0 protocol. First API subscribers have to create an Application, then subscribe to APIs and generate tokens against that application.
In a multi-tenant deployment, consumer applications are tenant isolated. At the API subscription and key generation, keys (consumer key/secret) are issued against these consumer applications. Then the tenant users, who consume those applications can generate user tokens. Further when storing keys, tenant ids are used to achive tenant separation. This is how mult-tenancy is achieved in API Key Manager.


Multi-Tenancy in Statistics

We can set up WSO2 Business Activity Monitor to collect and analyze runtime statistics from the API Manager. To publish data from the API Manager to BAM, the Thrift protocol is used.
Here, usage data publisher is created per tenant.

Information processed in BAM is stored in a database from which the API Publisher and Store retrieves information before displaying in the corresponding UI screens.
Statistics view in API Store and API Publisher are tenant isolated, since API Store and Publisher apps are tenant isolated. 



Figure 8 : Multi-tenancy in API Statistics

Summary

This post discussed how organizations can collaborate and monetize their APIs across multiple entities such as departments, partners or simply between separate development groups with Multi-tenancy features in WSO2 API Manager. Basically API developers of multiple entities can have isolated views in API Publisher and manage their APIs. Further API consumers correspond to multiple entities can explore and consume APIs from tenant isolated API stores. Moreover this article described how APIs subscriptions can be controlled among tenants and how APIs can be published into multiple API Stores. Finally how multi tenancy is achieved in API Gateway, Key Manager and Statistic were discussed.