I like to have User-A can contribute to the API-A but doesn't have access to the API-B.
When I look at the Azure APIM Built-in roles (link below) I am noticing that the API Management Service Contributor role is defined for all APIs.
Is it possible to to define a "Service Contributor" role per API as opposed with all APIS?
If not, is there any other technique that help me to achieve the same goal
AFAIK, you can restrict the user to specific set of APIs.
1) Through Product Level where you can add the APIs and allow all APIS to the specific set of users by keeping the Scope level to Product for the users.
Created 2 different APIs in APIM Instance like the below:
Open the New APIM Developer Portal after adding the APIs and publish the APIM instance > Portal Overview under Developer Portal.
In APIM Instance > Products > Added new product "Dotnet6FunctionAPIs" - Added the Net 6 Function App APIs > Checked the options "Requires Subscription", "Requires approval" and then published the product.
4. In APIM Instance > Users - created a user and in Products > Dotnet6FunctionAPIs Product > Access control > Allowed the access to Developers group.
Login to the developer portal with the new user login credentials https://<apiminstance_name>.portal.azure-api.net/ > Products > Dotnet6FunctionAPIs product > Click on Subscribe.
Here the Admin can approve the access of that product APIs to the user and can cancel the subscription whenever admin wants to.
After Subscription approval, the user can test the API present in the product.
If you observe here, I have allowed the users (under Developer group) to the product "Dotnet6FunctionAPIs" that contains specific APIs added to it.
This is one of the ways to restrict users from not accessing the other APIs by adding only specific APIs to the product and giving that product access to the users.
Updated Answer:
As Markus told, there are 3 built-in roles in APIM. API Management Service Contributor is for CRUD access to Complete APIM Instance (all APIS & Operations) and cannot be restricted to specific APIs.
I have seen the permissions given to API Management Service Contributor built-in role. Among those permissions, I believe we need to modify at API Policy Level which is
Write (Access) - Set API policy configuration (Permissions) - Creates or updates policy configuration for the API.
Related
I want to control the content on the Developer Portal on Azure API Management base on role user
We have the RBAC roles in Azure API Management (APIM) for giving permissions like Read-only access to services and entities of APIM, managing the developer portal of APIM.
Even we can restrict the users from the APIM Instance APIs based on User Access Control in the Products, Subscriptions Level available in the APIM Developer Portal.
Refer to this MSFT Article for more information.
We have a centralized development instance for Azure API Management Service where developers from different agencies/organization creates their Products, API and subscription. Essentially they have contributor role on resource group of APIM instance. This is a centralized shared APIM instance.
I can probably create a Custom RBAC role that allows me to edit only my API but not sure how to hide my own API and products from others.
Is there a way for developers to hide their Products and API entirely from other developers in Admin portal as well as in Developer portal?
Have you tried implementing the restriction at the product level?
Check your user list.
Create a group with by selecting the required members.
Create an product( Add required APIs) -> Go to access control -> Add a group (you may remove the Administrator group)
Is it possible, using the 3-legged authentication workflow, to determine if a user is an Autodesk contract (or software) manager using the OAuth API?
I've noticed the account:read and account:write scopes. Would this allow me to tell if a user is a contract manager?
Unfortunately, the contract info is not part of the Forge platform, and there no API support querying such data for this purpose currently. However, BIM360 Account Admin API GET users supports telling the user role in these three types:
account_admin: user has BIM 360 account administration access
account_user : normal project user
project_admin: user has Project administration privileges at a service level
And commonly, the contact manager will be the account admin of that BIM360 account. Therefore, you could use this as a workaround. Hope it helps, cheers!
Note. Account Admin API only accepts two-legged access token.
I am trying to get the policies for all the resources so I can view the roles and members associated with them. Any method of getting all the policies through the API would work for me.
I am currently trying to list the organizations (resources) so that I can then get the policies for each resource with a command like GetIamPolicy. However, the organizations.list command returns null. Let me know if any of you have had success getting any policy.
I am using the C# API with a service key to connect to my Google Cloud account.
If I understand correctly, you're trying to get the list of all of your GCP Organization resources so that you can cycle through the list to get the IAM policy bindings for each organization.
Get organizations from Cloud Resource Manager API:
To accomplish this, you would first use organizations.search (with no filter) to get a list of all of your organizations.
Try it here with the API Explorer.
Get organization IAM policy from the Cloud Resource Manager API.
Then, for each organization, you would use the organization name to call organizations.getIamPolicy in order to get the IAM Policy for that organization.
Try it here with the API Explorer (update the resource to reflect your organization name).
Note: IAM Policy is how you control access to resources in GCP. There are various levels at which you can manage IAM Policies, including organizations, folders and projects. There is a entirely separate concept called Org Policy, which allows you to control which API services can be enabled in each of your projects.
I am trying to understand what is the intended use case for app auth and app users. Im basically thinking about building an app that would use Box to store data of users that would subscribe to our service. Our service would allow each user to access and view their data.
If I have an account that basically owns the data of all the subscribed users, can I use the enterprise access token as a base for authentication while using the user account token to restrict the user to only viewing the data from their specific sub directory. Or do I have to have a unique account with its own api key for every user?
I hope this makes sense. Any assistance would be appreciated.
Thanks.
App Auth and App Users -- which is officially called Box Platform -- is essentially a white-labeled version of Box. I think of it this way: "Box" as we know it is software-as-a-service. It offers a web app, mobile apps, and all the trimmings. Box Platform is the platform layer upon which the SaaS is built, providing API-based management of users/content/comments/collaborations/etc. With Box Platform you have a walled garden in which you can build apps that leverage all the features of the APIs, but are not otherwise "Box apps."
I'm basically thinking about building an app that would use Box to store data of users that would subscribe to our service. Our service would allow each user to access and view their data.
This is an appropriate use case. With Box Platform you will be the owner and administrator of a Box enterprise and all the accounts and data contained within.
If I have an account that basically owns the data of all the subscribed users, can I use the enterprise access token as a base for authentication while using the user account token to restrict the user to only viewing the data from their specific sub directory. Or do I have to have a unique account with its own api key for every user?
I think it's generally cleanest to create unique accounts for each user as opposed to giving users a special subdirectory in the admin account. From there you can use the App Auth workflow to get an access token specific to that user.