More flexible subscriptions in Azure API Management
Present model for providing access to APIs is based on product subscriptions owned by a user. Each subscription includes a few properties and a pair of API keys. We are working on expanding this model to allow subscriptions and keys to be owned by a group of users or not be associated with any users at all. This will allow customers the flexibility of creating an ad-hoc set of key or having keys shared by a team of users without worrying about their ownership when members leave or are added to the team.
Peter Speden commented
I see in the link http://aka.ms/apimsubscriptions that Subscription Keys don't need to be associated with a user - so you can create a Organisation subscription key.
The one issue I have with this is how can multiple users of an organisation get to see the keys. Ideally we want the appropriate users of an organisation to be able to retrieve the keys themselves.
I guess a tidy way to do this would be to allow a company to be registered, and all users grouped under the company. The Subscription key would be attached to the company, and users could see it. It would probably also require certain roles to be allocated, maybe not all users should see a specific key, and maybe not all users should be able to regenerate the keys.
Peter Anania commented
My team NEEDS this. Simple scenario. I have an API. It's in a product. A developer registers for the product and in turn the API. They complete their application. Now they want a subscription for the application itself, so when connections are made to the API they don't continually come in as that person, as the application itself. They can't. get it. They already have a subscription for the product and they are not allowed another. We can create a 'process user' in the Azure AD, but the developer can't do that and the user isn't real. If anyone else uses the same process user for a different app or for testing we can't differentiate the traffic in Application Insights. We need a way to track developer traffic and traffic from the application they built separately in Application Insights.
Andy McCready commented
This is critical functionality at group and/or organisational level
Can we please make sure there's a way for a user or member of a group to get those keys? The api-specific subscriptions are currently only retrievable from the azure portal.
It would really help to have a single subscription for a group of user
Read about the progress on this item on http://aka.ms/apimsubscriptions.
Patton Hilliard commented
This would be a huge help to us.
we need this too!!
Makele Gebremariam commented
This feature is indeed badly needed!
James Estes commented
This feature is badly needed.
Oliver Tomlinson commented
+1 for "organisational subscriptions"
This is needed badly when trying to create B2B APIs.
Typically the "user" aka a developer, of an integration, is not the "owner" of that integration, the "owner" of that integration is the "customer" aka the business who consumes your API.
A "customer" has 1 or more "users" aka developers.
A "customer" has 1 or more set of subscriptions.
A "user" has access to one or more subscriptions that belong to the customer.
Carles Guitart commented
Will this also cover the "organizational subscription" topic that was present in the previous Trello board? If not, please let me know and I will post a new feedback item.
Having "organizational subscriptions" will be also a very interesting functionality.
Jason Kohlhoff commented
Allowing subscriptions and keys to *not* be associated with any users or groups at all is an important scenario. We would like to programmatically create subscriptions and keys, and display the keys in another web application that is acting as a frontend to API Management. Users of the frontend will ideally have no knowledge that we're using API Management on the backend.
Would be great to have that flexibility as soon as possible, since this is a requirement for us.
Christof Van Geendertaelen commented
It would be great if custom rbac roles can be used in the scope of a management group as well. Therefore, management groups should be able to be added to the AssignableScopes in the json definition file of a role.