WSO2 API Cloud provides a fully fledged, easy to use hybrid API management solution, which supports the best of both cloud and on-premises API management. WSO2 Cloud Microgateway is container-friendly. Since it can run in any infrastructure, it supports multi-cloud deployment, which relieves you from vendor lock-in as well. The latest addition to WSO2 Cloud Microgateway is the ability to add labels to group APIs so that it is possible to selectively deploy APIs by configuring the microgateway with a required label.
Our upcoming webinar “Deep-Dive into Hybrid API Management with WSO2 Cloud Microgateway” is a good starting point for anyone looking at adopting a hybrid API management approach. This will happen on Wednesday, July 31, 2019 from 9:00 a.m. – 10:00 a.m. (PDT).
In this webinar, we will discuss and demonstrate:
Hybrid API management
WSO2 Cloud Microgateway:
Microgateway Deployment options:
Deploying in containers
Click here to register and reserve your spot to learn about hybrid API management with WSO2 Cloud, and to go through a quick demonstration of a sample use case.
We will also have a live Q&A just after the demonstration. This is a great opportunity for you to ask questions and clarify any doubts you may have.
APIs published in WSO2 API Cloud are secured with Oauth tokens. Therefore, before invoking them you need to subscribe to the API and generate an Oauth token. To subscribe to an API you need to create an application (a virtual one). If you are not familiar with the concepts you can find more detail in our tutorials.
One request we had been receiving from our users was the ability to share these subscriptions with others in their teams. This seemed to be a very valid requirement. Most of the times there is a team who develops an application which will consume these APIs. Even-though one person subscribes and generate tokens to invoke an API, it makes sense for others to have some control on that subscription. For example they might need to re-generate a token due to some urgent security reason or subscribe to another API needed by their application without being by the application owner to do it. Basically, this reduces the impact of a centralized ownership in your API consumption process. After considering this, we have released a feature which allows subscriptions to be shared with the team.
How this works?
When users create applications in the API developer portal they can define a group(s) which they want to share the application with. Here, what is meant by a group is a role in their organization. You can read more about roles and assigning users to them from this tutorial.
If there is a “Finance” role in the organization and if it is provided as the group to share the application (as shown in the above image), then anyone signing into the developer portal who has that role is able to see that application.
Others in the team can see the subscriptions made by this application, view the tokens and also re-generate the tokens if needed. But, if they are not the application owner, they cannot do the token generation for the first time. i.e. It has to be the owner who does the first token generation. Application owner has full control over the application and the others have less control. For example they cannot unsubscribe from an API which was subscribed by the application owner. But the owner can unsubscribe from APIs which were subscribed by others using his/her application.
You can follow the steps in our tutorial to implement this for your organization.