WSO2 APIM: Partioned Publisher Groups

WSO2 API manager publisher role allows anybody in that role to create, edit and delete APIs. Sometimes, it is a requirement that this functionality should be limited to organizational units of different functional groups. This can be easily achieved by defining roles and assigning these roles to the published APIs.

First define the roles in the API manager to represent different groups.

• publisher_finance
• publisher_hr
• publisher _engineering

Then register an listener for API publishing. This can be done by writing an implementation of or governance registry LC executor. When the API is published by an user,

1. Discover the roles of the user
2. Allow only those role to edit and delete the API by modifying the permissions of the resource representing the API.

WSO2 IS : How to do Conditional Authentication using Entitlement Policies?

WSO2 Identity Server 3.0 has a brand new feature that allows users to be authenticated based on a set of XACML policies.

Use case - Allow only users with customer-care role to login to Cloud Based Microsoft Dynamic server.

1 - Configure logging into Microsoft Dynamic server using SSO by following this link.

2 -  Make sure you have set the "Enable Authorization" tick in Service Provider > Local & Outbound Authentication Configuration.

3- Then Go to Entilement > Policy Administration in the left hand menu

4 - Select the authn_role_based_policy_template. Edit it to have the Service Provider name as "CRM" (or the name you have given to the Microsoft Dynamic Server.  Change the the role name as "customer-care" and publish it to My PDP.

That is it!

APIs that Consume APIs - JWT Bearer Grant Type

OAuth protocol has provision to design custom grant type in addition to the four grant types that are mentioned in the specification. SAML grant type is of the first grant types that came out as an extensions and many IdPs support this. Many IdPs allow to write plugins that enable other custom grant types, and among the most popular grant types are,

• Biometrics - Here the biometrics such as your fingerprint or retina scan is used obtain an access token. This is pretty useful for mobile apps.
• JWT - Here a service that has a JWT token may use it to obtain a access token to access another API

Here is a scenario for JWT grant type.

You are writing a service that allows employees to report time that they spend on customer work. Your service has received a JWT token so it can do authorizations.  One of the methods in the service is as below,

reportTimeForCustomer(String clientId, String ticketId, int durationInMinutes) {}

First of all, authorization checks happen based on the JWT and the next step is to validate clientId and ticketId before proceeding. There is a CustomerAPI and TicketAPI that can perform validations.

But both of these APIs are OAuth protected. How do you proceed? How would you obtain an access token to access this service. You have several options,

• You can take an application token
• You can take an access by presenting the JWT token as mentioned above

Applications Accessing OAuth Protected APIs

When implementing applications that access OAuth2.0 protected APIs there are few recurrent questions asked by different parties. Before diving into the those questions, lets brush up on the for different OAuth2.0 grant-types and their usages.

• Authorization Grant - Typically used by 3rd party web applications. They can obtain an authorization code that can be used to get an access token. 
• Implicit Grant - Typically used by mobile phones and single page applications to obtain an access token.
• Username/Password Grant - Typically used by trusted applications by clients. For example, the applications within the same organization as the the API provider can use this approach to obtain an Enduser access token.
• Client Credential Grant - Used to get an application access token.

You can read more about these at https://tools.ietf.org/html/rfc6749

Now lets look at the common questions raised by some application developers.

Q1 - My application must do SSO with SAML2.0. It should also access APIs without requesting the end users to login again.

Additionally there is freedom to design and implement different grant-types. One of the first grant-type is OAuth2.0 SAML2.0 bearer token. This allows an application to obtain an access token by presenting the SAML token, so this answers your Q1.

Q2 - My web application should access 3rd party APIs as the end user. How can I obtain an access token to call the APIs?

When 3rd party APIs needs to be accessed, redirect the end user to the 3rd party auth server to get authorization code. This means the user has to first authenticate to your app, and then authenticate to the 3rd party auth server.  Or else you can obtain an application token using client credential grant-type, but in this method the application is not accessing the APIs as the end user.

Q3 - I don't want my application to maintain multiple OAuth access tokens for the same API provider. Is this possible?

For the same provider you can access multiple APIs using the same OAuth2.0 tokens. This is inbuilt into API provider platform by default, mos of the time

WSO2 APIM: Publishing APIs to External\Internal Parties

What if you want to have two API gateways - one for external facing APIs and the other for internal facing APIs? This can be achieved by two API manager deployments, but from WSO2 APIM 2.0.0 onwards this has become an inherent features supported by the product, so there is no need for two deployments. The solution is based on the multi-gateway feature. The multi-gateway feature allows one publisher to push APIs different gateway environments selectively.

At the time of publishing APIs, all available environments are listed in the publisher so that the API publisher can pick the correct environment. So the publisher will see all the environments available, in this case external and internal.

This allows publisher to push APIs to external or internal gateway selectively. So you can pick to expose an API on either external or internal gateway or on both of the gateways at the same time.

RBAC Store

In a real world scenario, internal users should be able to see only internal APIs and external users should be able to see only external APIs. This can be achieved via user roles. User roles can be defined for external and internal user, but sometimes it is not always scalable and can be troublesome as you have to assign users to specific roles.

Why two stores would be great?

What if we could deploy two stores, one for internal users and the other for external users. This will match the deployment expectation as well. The external store can be in DMZ (or accessible by outside world) and internal store can be internal network only.

This is added as a new feature to APIM road-map.

What about OAuth Keys and Throttling?

Underlying gateway/environments APIs are transparent to the OAuth keys. Irrespective of the API being exposed on a single or multiple gateways the number of cumulative API calls will be considered by the traffic manager when enforcing throttling.

5 Top Technical Reasons to use WSO2 API Manager

Not Just a Gateway - WSO2 API Manager is more than an API gateway. It is a complete platform for API Management, which includes an API gateway, security, developer portal, publisher portal, API lifecycle management, analytics and much more. It has a very comprehensive feature list and you can read about the feature list here.

Cloud and On-premise Options - WSO2 API Manager is available has a public cloud offering from here. Or it can be downloaded and installed on premise with different deployment options. Your organization can take an iterative approach and start small and grow into a API centric organization in an iterative manner.

Flexible Deployment - This is one of the strongest reasons to go for WSO2 API Manager. It offers flexible deployment patters as each organization has different network, governance policies. You can start WSO2 API Manager in different modes (profiles) to act as a gateway, developer portal and publisher portal. You can deploy different profiles at different network zones (eg. DMZ) adhering to organization network and deployment policies.

Part of a Platform - As all WSO2 products, the API Manager is built on it's comprehensive platform. That means whenever additional functionalities are required one can extend into those areas such as security, integration, real-time analytics and mobile device management and they would work together seamlessly with near zero effort. So what if you don't want any more WSO2 products? No problem, just jump into the next point.

Openness, Modularity Extensibility - WSO2 API Manager is 100% open source and distributed under Apache License 2.0. It is built on open standards such as OAuth 2.0 and has all of it's functionalities available as APIs. It is modular and extensible allowing to plug into external Identity Providers. All of these leads to into zero vendor locking.

An Iterative Approach to Transform your API Strategy using WSO2 APIM

Iterative approach is the choice for most IT related projects today. In the same wary API management at your enterprise can follow an iterative approach that will eventually lead to digital transformation.

If you have no problem using Cloud services just get a demo account and you are on your journey. 

API management can be achieved within a few hours using WSO2 APIM. You can download the latest pack from http://wso2.com/api-management/, deploy and configure it to be production ready instance within a few hours. The deployment is as follows.

Pros
1 - The cost is for single instance and you will get 24*7 WSO2 production support
2 - Deployment is up and running within hours
3 - Minimum hardware/cloud infrastructure requirement (only one node)
4 - Suitable for starters

Cons
1 - No HA
2 - Not network friendly. Where are you going to run this instance? Not in DMZ as this need a database connectivity.
3 - The supported load really depends on your use-case

What if you want HA? This is the next level. You need  high availability. The system should be up and running 99.99%. Then you will need another node.

Pros
1 - The system is highly available
2 - The cost is for single instance and you will get 24*7 WSO2 production support
3 - Deployment is up and running within hours

Cons
1 - Not network friendly. Where are you going to run this instance? Not in DMZ as this need a database connectivity.
2 - The supported load really depends on your use-case

What if your load goes high? You can make the passive node as a traffic serving node. This means production subscription changes from 1 instance to 2 instances. 

Pros
1 - The system is highly available
2 - The cost is for two instance sand you will get 24*7 WSO2 production support
3 - Deployment is up and running within hours

Cons
1 - Not network friendly. Where are you going to run this instance? Not in DMZ as this need a database connectivity.
2 - The supported load really depends on your use-case


What if you want to support more TPS OR complex throttling OR adhere to standard network patterns, where the un-trusted connections are throttled out at the gateway itself. Then you need a distributed deployment where the deployment looks like below. This deployment allows different functional component of API management to scale differently - and these components scale at different proportions.

For this type of deployments you can get solution architecture help from the WSO2 team. This is an API empire that needs to be planned precisely.