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.
Related
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.
I'm integrating Autodesk Viewer in an application, and it uses Model Derivative API to translate files, which is a paid service.
Can this integration be restricted to allow access only for users under a organization account? Meaning if a random autodesk account outside the organization tries to use the integration, it will not be allowed.
Presumably you are using 3 legged authentication? As a simple way of filtering out users from outside your organization, once they have authenticated you can get their Autodesk account details https://forge.autodesk.com/en/docs/oauth/v2/reference/http/users-#me-GET/ which includes the email address assigned to their account, and decide from that if they should have access.
I am attempting to build an integration into our web application which allows user's to link their BIM360 account with our account. The ultimate goal is to call the BIM360 API and pull projects on behalf of the Authenticated user.
I am not seeing a way of obtaining the user's account id so that I can make a request to this api https://developer.api.autodesk.com/hq/v1/accounts/:account_id/projects on the user's behalf.
The https://forge.autodesk.com/en/docs/data/v2/reference/http/hubs-GET/ resource is able to provide me with what I need.
I was able to create a project to connect an app to google data, for a specific account (followed Google People API)
But now I would like that each customer log in hisself to his account and manage his data.
I can' t create project in the Google API Console for each customer, my app needs to read auth from each user who will use my app and "auto" create auth to read google contact data of the logged user.
Is possible?
Could you suggest me articles about how to do?
It sounds like you are trying to do exactly what OAuth 2.0 (see the page you linked to) gives you: authenticating users. This differs from using an API key, which is only authorizing your project and has nothing to do with a user's credentials.
OAuth 2.0 combines a Client ID (associated with your Google Developers Console project) and a user's login (specific to the user who is accessing your app/site) to give you an authorization token. This token will let your app act on behalf of that user when calling that API. Just make sure to request the necessary scopes as part of the OAuth 2.0 authorization prompt given to the user.
How to give this prompt varies by environment, but many common options are listed on that link.
Note that you always use the same Client ID, so you only need one Google Developers Console project, but you are given a unique token specific to that user's login when they authorize your app, so this lets you act as any user which grants your app access to their account.
I'm looking for a way to impersonate users of a google app domain using a admin user. I could do it easily with google data document list api but I cant find a way to do it with the new Drive API.
Precisely, what I want to do is authenticate my admin user using Oauth2 (i've already done this), retrieve a list of the users of my domain and then impersonate my users, or at least be able to access files and docs from the Drive of those users.
In the administrative panel of google apps, there are Oauth consumer key and Oauth consumer secret, but these are used in Oauth1 2LO, not Oauth2.
Is there a proper way/workaround/hack to implement what I want ?
Best regards,
Jérôme
I've only been looking at the google-api-ruby-client as an example but you should be able to do this with a service account that is permitted access through the admin panel -> Advanced tools -> manage third party oauath clients. Once permitted you can follow the example for a service account here http://code.google.com/p/google-api-ruby-client/source/browse/service_account/analytics.rb?repo=samples but instead of authorizing with
client.authorization = asserter.authorize()
you can use
client.authorization = asserter.authorize("id#domain.com")
I haven't done a lot with this yet but after authenticating in this method I've been able to list all documents owned by a user on my domain.
Thanks to James Woodward, i've been able to impersonate user. I post an answer to provide Java specific details.
Create a service account in the API console. 3 important resources are created :
Client ID : used to authorize the app on the Google Apps domain
Email address : used to authorize the requests of the app
.p12 key file : used to authorize the requests of the app
Authorize the app on the Google Apps Administrative panel, providing it with Service account client ID, and all the scopes the app will need.
Create GoogleCredential this way :
GoogleCredential serviceCred = new GoogleCredential.Builder().setTransport(HTTP_TRANSPORT)
.setJsonFactory(JSON_FACTORY)
.setServiceAccountId(SERVICE_ID)
.setServiceAccountScopes(Arrays.asList(SCOPES))
.setServiceAccountUser("impersonated.user#domain.com")
.setServiceAccountPrivateKeyFromP12File("key.p12")
.build();
Those credentials can now be used to authenticate the requests made by the app on any scope authorized.