How can we improve Azure API Management?

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.

165 votes
Vote
Sign in
(thinking…)
Sign in with: Microsoft
Signed in as (Sign out)
You have left! (?) (thinking…)
AdminAzure API Management Team (none of your business, Microsoft Azure) shared this idea  ·   ·  Flag idea as inappropriate…  ·  Admin →

15 comments

Sign in
(thinking…)
Sign in with: Microsoft
Signed in as (Sign out)
Submitting...
  • Peter Speden commented  ·   ·  Flag as inappropriate

    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  ·   ·  Flag as inappropriate

    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.

  • Anonymous commented  ·   ·  Flag as inappropriate

    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.

  • Oliver Tomlinson commented  ·   ·  Flag as inappropriate

    +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  ·   ·  Flag as inappropriate

    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  ·   ·  Flag as inappropriate

    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.

  • Andreas commented  ·   ·  Flag as inappropriate

    Would be great to have that flexibility as soon as possible, since this is a requirement for us.

  • Christof Van Geendertaelen commented  ·   ·  Flag as inappropriate

    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.

Feedback and Knowledge Base