API Management is still a rapidly developing area. Many API Management suppliers have given the API Store little thought. It’s just a portal to advertise API’s. Since store visitors are mostly not involved in product selection, investments have been kept to a minimum. In the meantime, more mature API Publishers have discovered that the functionality of the API Developer’s Portal is vital for the success of their API Management initiative – and possibly of their larger corporate digitization efforts. Consequently, we’re seeing more investment in developer engagement and support.Subscription Governance, however, is largely still terra incognita. Your typical API Store is a B2C-type shop, where each shopper has an individual account. With some luck, you can notify your Twitter friends of a new API-subscription, and that’s about it. In the B2B-world, there’s actually much more complexity to those shoppers. Often, there’s a whole team of people developing an application, consuming one or more of the available APIs. Moreover, a typical business develops multiple applications, often for different markets and channels, and does so with multiple teams. In more and more cases, this typical business employs both API publishers and subscribers, in other words you are subscribing to the APIs your colleagues have published. After all, API Management is still gaining popularity as a low-friction tool to support integration governance across all the departments in the enterprise.
Subscription Governance must put you in full control of which APIs your applications are consuming, both internally and externally, and at the same time allow your developers to engage fully.
Introducing Group Sharing
With WSO2 API Manager, you have a simple, yet powerful governance feature to manage user groups in the API Developer Portal. It’s called Group Sharing. The idea is simple, and the good thing is: you’re fully in control.
At a user community at an organization subscribing to APIs, either internal or external to the organization publishing the APIs, when you want to implement subscription governance, ‘Group Sharing’ is what to do in the WSO2 API Developer Portal. And this is how to do it.
First, you set up a user account who will technically own your subscriptions. Typically, this is an admin-type digital account, not an individual account. You use it for administrative work only, such as registering an application and subscribing to an API. Not your daily routine, obviously. As subscribing to an API is legally a form of contracting, you may want to share your password very selectively, if at all. During registration, it is essential that you enter a unique domain name for your organization. To do that, when you create your account, you have to click “View Additional Details” and complete the “Organization” field. This will be the domain for your group sharing option. If you forgot to do this during account creation, you can contact your WSO2 Identity Server administrator to correct this. Also, if the field is not available on your registration form, ask your API Manager administrator to activate group sharing.
Once you’ve set this up, you’re good to go on to the second part. This is the registration of your applications (specifically: API consumers). As an example use case, I’ve set up 2 applications, ourWebApplication and ourMobileApp, developed in two separate groups, but supervised by a single architect. The way it works is that each application is shared with a specific group, in my case webappdev.groupsharing.api and mobileappdev.groupsharing.api.
Now, make sure your web developers have the webappdev group in their account, your app developers the mobileappdev, and your architect has both. As a result, your developers will be able to access their own application only. Notice that through group sharing, you only grant “View”access.
Your architect, on the contrary, got access to both applications.
This is how the group sharing feature in WSO2 API Manager works out-of-the-box. So, next time you visit the API Developer Portal to browse analytics, discover APIs or contribute to the discussions going on in the forum, consider using a developer account, rather than a group admin account. After all, you don’t want to risk accidental changes to your subscriptions.
By default WSO2 has no restriction set on the Organization you choose to enter during registration. This gives maximum flexibility, but also introduces a certain risk of unintentional sharing. You can join a group just by registering their name – accidentally or otherwise. At Yenlo, we’ve a number of different strategies on our sleeve, to implement some useful controls when it comes to user group management. Of course, we’d love to discuss how to tune this powerful feature and our implementation strategies to your specific needs.