Overview
In API Management, users and groups are a core aspect of the Developer Portal and are used to manage the visibility and access to respective products and their APIs.
One of the common questions that I often get asked is, “how do I appropriately govern the groups effectively so that I can ensure that the correct groups and users have access to the appropriate resources and those who don’t… well don’t?”.
Background
API Management has three immutable built in system groups used to govern access:
-
Administrators | These are not consumers or customers of your APIs but are rather the users who build and manage the API Management service instances, creating the APIs, operations, and products that are used by developers. You can’t add users to this group.
The group contains the admin email account provided at the time of service creation. Azure subscription administrators are members of this group.
-
Developers | These are customers and consumers that build applications using your APIs. Developers are granted access to and are authenticated into the developer portal. Membership to this group is managed by the system and cannot be added to by you.
Developers (Authenticated Users) invited, created, pulled from external groups, or otherwise signed up are all created as a developer and gain automatic membership to this group. -
Guests | These are users such as prospective customers and are able to visit the developer portal without having to be authenticated. APIs that guests can view are managed by yourself as well as the type of access such as read-only access (the ability to view APIs but not call them). As with the previous two groups, membership is managed by the system.
Then there is the ability to create custom groups and or use external groups in associated Microsoft Entra tenants. These custom groups can be used to further govern developer visibility and access to API products.
Note:
User accounts from MS Entra ID or B2C groups are still created as new developer user entities within APIM and associated with the Developers System group as well as the desired Entra ID group.
Governing Access
The key to understanding Group Access is to remember that all developers (no matter how they have been created) are associated with the Developers System group. In effect this means that any product that has been associated with the Developers system group will be accessible to all users (except Guests given association).
Therefore do not blindly associate the Developer System group to your products unless you expect all users past, present, and future to have access to them.
Rather in answer create custom groups/associate Entra ID groups of which can be used to provide access to specific products. Further to this, granularity is key for security, following the good practice of least privilege (A user or entity should only have access to the specific data, resources and applications needed to complete a required task.).
Have a play, and hope this helps.