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.
Closing remark
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.