WSO2TORIAL: WSO2 API Manager 1.10.0

 In this episode of our WSO2 tutorial: The new WSO2 API Manager 1.10.0 is a minor upgrade from the previous version of the API Manager (1.9.1). However, there are some new features that have been integrated in this version that will allow for more control over who is able to do what in the API Manager, or in this case the API Publisher.

The WSO2 API Manager consists of four major components:

1. API Store (for developers to discover, subscribe and rate APIs)
2. API Publisher (for the organization to manage the API Lifecycle)
3. API Gateway (that manages API traffic, security and access)
4. API Keymanager (for handing out OAUTH2 tokens)

As you can see the Monitoring and Analytics is done using WSO2 Data Analytics Server (using the binary thrift protocol). This is not part of the API Manager but a separate product.

The API Publisher supports the whole lifecycle of APIs. In the image this is show as Design, Publish, Manage and Monitor but actually you now have control over the whole lifecycle allowing to change the default lifecycle that currently supports:

1. CREATED
2. PUBLISHED
3. DEPRECATED
4. RETIRED
5. BLOCKED
6. PROTOTYPED

These lifecycle steps not necessarily need to be taken sequentially. This is one of the flows possible within the API Manager. The actual flow and possibilities depend on the APILifeCycle settings.

Determining who can publish

The extension of the lifecycle, or in this case more aptly the additional requirements to roles in the lifecycle. It involves certain roles that a user might have. It is similar to for instance a scope with OAUTH2 (depending on the fact that a user has a certain scope or not access will be available / granted to a resource).

In order to add this possibility to the lifecycle it is needed to change the default sequence. The APILifeCycle can be found on the Extension tab of the UI. Clicking on the View/Edit choice of the APILifeCycle will open up the editor.

We  need to add three lines to the APILifeCycle :

• <data name=”transitionPermission”>
• <permission forEvent=”Publish” roles=”pubrole” />
• </data>

This XML will only allow the transition to progress to Publish if the user has the ‘pubrole’ role.

You can add the permission in each lifecycle and for each transition indicated in the lifecycle definition.  In this case we added it to the Prototyped Lifecycle and specifically for the transition to Published.

So what happens if we do not have that role? Consider the admin user of WSO2 who has all possible rights in WSO2 after all.

We open the API Publisher and publish the default API that comes with the WSO2 API Manager.

As you can see it is published and we will deploy it as a prototype.

At this moment with the default admin user we see two possibilities: Demote to Created and Deploy as a Prototype.

At the moment we add the pubrole to the admin user, we see the option that is now available: Publish.

Multiple roles

In case that you want to add more than one role to a transition, separate the roles with a comma like this:

<data name="transitionPermission">

                           <permission forEvent="Publish" roles="pubrole,allrole" />
</data>

If you create a new user with the ‘allrole’ role (e.g. johndoe) but without pubrole you will also see the ‘Publish’ option.

Publish to Test environment

One of the other things that is possible is the extension of the lifecycle to, for instance, first publish to a test environment (Publish to Test) and after that to a production environment (Publish to Production). We will cover this in another blogpost.

Thanks to my colleague Joris Jansen for his contribution to this blog.

WSO2TORIALS help you to change, update or improve WSO2 products and are based on our experiences with the products. WSO2TORIALS will guide you step by step with minimal knowledge required.