[WSO2 APIM] - The Basic Architecture of WSO2 APIM - Part 2- The Publisher - under the hood

 As a continuation of my previous post  The Basic Architecture of WSO2 APIM - Part 1, this post will concentrate on the publisher module, and its major functions. It is recommended that you read the aforementioned post in order to clearly understand the concepts described in this post.

The Publisher is the starting point of an API life cycle. An API is created at the API Publisher by an API publishers. The Publisher is also a major component in the WSO2 APIM and was introduced in my earlier post.

To start off with let me bring up the basic outline of the Publisher in a graphical mode.

 An API Publisher will ideally interact with the API Publisher module to create and manage an API. The API Publisher is a jaggery web app which provides and easy to work with GUI.

Databases associated with the API Publisher

 The database configuration can be found at <APIM_HOME>/repository /conf/datasources/master-datasources.xml

    - Registry Database
      The db handles all registry related storage.
    - AM_DB
       This db stores information required for the APIM.
    -UM_DB
       This db stores information such as user permissions.

Logging in 

The end user will log into the API Publisher by entering the username and password in the GUI provided by the web app. Once the credentials are entered the API Publisher will validate it against the authentication manager set in the api-manager.xml found at repository/conf. It is defined under the tag <AuthManager>. This is the server which the Publisher and the store will point to for authentication. By default it will be the embedded LDAP which is the user store which is being pointed by localhost which is started on the APIM server it self. In a typical production deployment this could either be WSO2 IS, or any other IDP (identity provider).

When the end user logs into the API Publisher in a SSO configured environment, it will send a SAML request to the Authentication Server. The Authentication server will process the authentication and send a signed response. The API Publisher then will validate this with the key stores.

Once the authentication is completed it checks for authorization in the UM_DB by checking for publisher permissions. Once the authentication and the authorization succeeds it will succeed in allowing the user to access the API Publisher.

Creating an API

There are two ways of creating an API.
   1. By Filling out the form in the API Publisher web app
   2. By Importing a Swagger doc.

When the API Publsher creates an API, the API information is stored in the Registry Database. This is specifically stored at the governance space of the registry database.Together with the API the swagger document related to the created API is also stored in the Registry database.

When the API is created a synapse config of the API is also stored at the API Gateway. Since the API Gateway is a WSO2 ESB, the API is also capable of having sequences defined in the API definition.

<api>
   <in>
         </custom in sequence>
   </in>
   <out>
          </custom out sequence>
   </out>
</api>

In parallel to this, when the APi is created, the AM_DB is also updated. A reference to the API is stored in this database tables. Since we have all the information of the API in the REG_DB, we only store a subset of the API information in the AM_DB, which is required for AM functionality.

When an API is created it is by default in the "created" state.

I hope this gives you a clear understanding on what happens in the publisher end, under the hoods.

In my next few blog posts I am planning to discuss on the  rest of the modules, API Store, and  API Gateway. these will cover the Key manager as well.

References
1.https://docs.wso2.com/display/AM180/Key+Concepts
2.https://docs.wso2.com/display/AM180/API+Developer+Tutorials

[WSO2 APIM] - The Basic Architecture of WSO2 APIM - Part 1

After a long time I decided to write a blog post, and this time about APIM. Mainly because my new team is the WSO2 APIM . Today I received a training from Nuwan Dias (WSO2 APIM team) on the basic architecture of APIM, and that training inspired me to come up with this article.

To start off with, yes I did have a prior knowledge on the WSO2 APIM and have worked on it on various instances. But the training I received today cleared many doubts and managed to organize my knowledge on the WSO2 APIM very clearly. Hence, this article is focused for dummies, to gather a basic idea on the WSO2 APIM architecture.

So, before I start there are some main components of WSO2 APIM which I will introduce briefly.

 1) The API Publisher
 2) The API Store
 3) The API Gateway
 4) The Key Manager

The Publisher

This is the component that is responsible for the work flows associated with API creation. This is where an API developer will have most of the work to do. API Publisher is a jaggery application (Jaggery is a framework to write webapps and HTTP-focused web services for all aspects of the application: front-end, communication, Server-side logic and persistence in pure Javascript). The publisher allows the creation of the API by allowing the developer to fill in a form. This form consists of many details such as, the API name, version ,throttling level etc.

There are basically two ways of creating an API.

•  Filling out the form in create API  on the WSO2 APIM.
•  By importing a Swagger document (Swagger is a simple yet powerful representation of your RESTful AP) to WSO2 APIM.      

API's created in this component initially is of the Created State. An API is associated with many states.

 The Store

The Store is the component that exposes the published API's. The API's which are created in the publisher needs to be pushed to published state in order for the user to view the API's in the API Store. The API store is responsible for maintaining the API access. Whilst the API Store is responsible for many other activities, I would like to believe that it's main responsibility is to allow users interact with the API's and  subscribe to them.

How the subscription and access is maintained is that the Store will show API's in a tenant domain, when the domain is selected upon navigating to the Store by a user.As mentioned before, these API's are only API's which are in the published state. For a user to access this API, the user requires to create an Application in the API Store. In a practical scenario, let's say there's an API to get weather information, and in my application I need to get the data for a functionality I intend to deliver. Then I would create an application, which would be an OAuth application, in the APIM Store. For a API I can subscribe using this created application which would maintain the subscriptions to API's. when this is done, I can create a token. This token will be a consumer secret and consumer key pair, which are in the world of OAuth terms for something similar to username/password. With this  the store also provides me an access token, which is a APPLICATION type token. With these tokens an application can access the subscribed API and obtain the service.

The API store, just like the Publisher is a Jaggery web application.

The Gateway

The gateway is the access point for a external user to obtain the services offered by the API.

When the Publisher publishes the API a synapse config (Apache Synapse is a lightweight and high-performance Enterprise Service Bus (ESB)) of the API is sent to the Gateway. In a typical production deployment this is the component that will be exposed. The gateway its self is an ESB, and hence sequences can be enforced on these API's. The API when invoked would be running this synapse config, and this config would have a set of handlers which are being called in sequence.These handlers are:

•  Security handler
•  Throtling handler
•  Stats Handler
•  Google analytics Handler (disaled by default)
•  Extentions Handler

These handlers are required to run in sequence because each handler populates the message context in the synapse and passes it on, which is required by the next handler in sequence. The gateway has endpoints for token and revoke which are proxies for the actual endpoint which is embedded into the keymanager component.

The Keymanager

The Keymanager is the component which handles the authorization/authentication part. The Keymanager can be configured to be the WSO2 IS as well. The API manager Key manager handles the security related aspects and issues and verifies keys, to the store and from the gateway.

There is a JAX-RS web app embedded into the key manager which has the implementations for token endpoints and revoking tokens. These are the endpoints to which the gateway calls upon requesting tokens.

With these four components being introduced, I will next discuss on how a API is published, how it is involved in the store, gatway and keymanaer in my next blog post.

Till then, I hope this gives you a heads up on the API Manager Basic architecture and hope you read about it more. If Interested I have noted references below for your use.

References
[1] https://docs.wso2.com/display/AM180/Key+Concepts

[2] http://synapse.apache.org/index.html
[3] https://docs.wso2.com/display/AM180/WSO2+API+Manager+Documentation