I have a bridge application test harness which queries the api using GET /contextregistry/v2.5/Repositories/BentleyCONNECT--Main/ConnectedContext/Project?$select=*&$filter=Name+eq+%27Bentley-FutureOn%20Connector%20Handover%27
This is failing with the error "Authorization scheme is not supported".
I believe that this is caused by a change I made to the scopes defined for my spa application.
I believe that I need to add the context-registry-service:read-only to the scopes. However the Apps portal (https://developer.bentley.com/my-apps) no longer seems to be able to add this scope.
context-registry-service:read-only scope, along with some others, was deprecated and replaced with a single itwinjs scope that you can allow by selecting 'Visualization' API group.
Existing applications that had deprecated scopes will continue working, but new applications must use the new itwinjs scope.
Related
I've a situation where I'm creating a Blazor Server front end for an API, and that API may also be used directly by some other systems. Essentially some smaller customers might use the UI, others (perhaps larger with their own dev team) build their own UI and use the API. We control both sets of code (for the Blazor and the API).
Auth in the api is done (at the moment) by sending a userid and a password and getting a JWT Bearer token that is added to all subsequent requests.
Auth on the BS app is (at the moment) done using Azure AD B2C; the templating in VS makes it an easy setup and then no really specialist knowledge is needed to maintain and add new users
There isn't any special link between the two for now; both are in dev and the BS app just has a hard coded u/p for a single dev user inthe API side. At some point that needs to change so the API serves more than one customer via the UI
It seems I have a couple of routes I could go down:
Make the BS app use the API for auth; in my mind this looks like setting up something similar to what you get when you make a new BS app with "Individual Accounts" auth, except it doesn't use EF on a database with tables for tracking identity - it would probably use a custom store and usermanager that asks the API for auth instead of some DB, and then some (hopefully simple) mechanism of getting the returned token from the API into every httpclient that ends up being used to poke the API (they're abstracted away into proxies built by NSwag but it's easy enough to address because NSwag code calls a particular overridable method to setup the headers.. finding a way to have the httpclientfactory do it might be even easier)
Make the BS app and the API use AD B2C for auth. As a workflow I genuinely have no idea how that's done or what it looks like.
Of the two I'd prefer the latter because it hands off some additional responsibility to AD, such as maybe in future we want to have UI customers also do 2FA but I'm not really sure how to go about researching it. How do we go about sharing auth between the two systems?
I'm not looking for code; some rudimentary instructions on how to share the authenticated identity between the BS app and the API is really what I need. If it's not an achievable goal, what alternative mechanism for Blazor Server do I have that would allow easy sharing of a retrieved bearer across a everything the user might do in a "session" (I don't mind if they lose SignalR connection and have to log in again)?
If either of the approaches above look like I'm just making life hard work, and it should be done another way, an outline of the steps required to make it go would be ideal
I'm currently trying to add google sign-in support to our educational website. The majority of time users will just sign in with Google, but occasionally teachers need to be able to import pupil rosters from Google Classroom too. I've got all of this working using the guides from the Classroom developers site (https://developers.google.com/classroom/quickstart/js). I'm using https://apis.google.com/js/api.js to sign users in (gapi.auth2.getAuthInstance().signIn) with just the "profile" scope and then granting the extra classroom scopes if teachers need them.
I'm just reading the Migrating to Google Sign-In guide (https://developers.google.com/identity/gsi/web/guides/migration) and trying to work out if it applies to us or not. It's explicitly saying not to use gapi.auth2/gapi.client etc anymore and to use the new Identity Services Library instead, but there's no explanation how to use that to make API calls to Classroom (or any other Google API). The OAuth 2.0 JS guide (https://developers.google.com/identity/protocols/oauth2/javascript-implicit-flow) is still saying to use gapi.auth2 etc too.
So should I be using the new library to sign users in, instead of api.js?
And if so, am I still supposed to be using gapi.auth2 to make API calls, or should I be using the new library instead somehow?
Authentication for sign-in, and authorization for data access are being separated. Use the new Identity Services library for sign-in instead of api.js and the profile scope. This should be the case for the majority of your users based upon what you've shared.
Later, and as needed, continue using gapi.auth2 to obtain an access token and call the Classroom or other Google APIs.
Functionally, what this will look like is separating out your sign-in flow using HTML or JavaScript from gapi.auth2 and access/refresh tokens. Token requests for calling APIs (using either implicit or auth code) would be made only at the point they're needed. Say you'll use 3 different scopes at some point, each would be requested only when necessary, also known as incremental authorization.
I/we at www.dr.dk are working on a Sonos integration with the bare minimum functionality. This means that we wish to apply anonymous access in this first version of our Sonos integration.
In the API documentation
https://musicpartners.sonos.com/node/289#toc0
is says 'Finally, you can decide not to use any authentication, also knows as anonymous access. ...'
Which we read as an option to not to implement authentication endpoints like 'GetAppLink(...)' etc.
So now we have teste our service and it appears to work fine, as far as we know. Therefore we have now started to fill out the application registration form.
In the registration form we find the following required fields regarding authentication as depicted in the image below
Screenshot from the application registration form
As we see it these fields are related to authentication and seems somewhat confusing to us. So with our logic - anonymous authentication means that no test accounts or customer care accounts are needed etc.
So the question is. What are we missing ?
You can just mark those as N/A for each of the fields.
I've been creating an extension for VSTS, and so far i have stored some data in documents in collections (https://learn.microsoft.com/en-us/vsts/extend/develop/data-storage).
The problem I have now, is that I need to GET these documents somehow from an external application. I have looked into: https://github.com/Microsoft/vsts-auth-samples/tree/master/ClientLibraryConsoleAppSample to get the authorization done, but then I am unable to get the documents. If I try to access through the REST API I have issues authorizing myself(without the personal access token provided. The application is supposed to work for every user, and i cannot get and use every user's personal access token. This is not feasible for 350+ people) as well as I am unable to get the REST API working. The documentation on all of this is severely lacking.
Anyone able to help?
The documentation is lacking, because the Data Storage is isolated for the extension and there is no easy way to access the data from outside of the extension. If you need external access, you also need to store your data externally. Azure storage or in a TFVC/Git repo under the VSTS account.
As for per-user storage access, that's also isolated and would indeed require either a account owner token or a user specific Oauth or PAT token.
I have found the solution. The documentation states that there are 2 ways of working with the documents/collections. REST API and their VSS wrappers. The url required to get all documents in a certain collection is as follows:
https://{account}.extmgmt.visualstudio.com/_apis/ExtensionManagement/InstalledExtensions/{publisherName}/{extensionName}/Data/Scopes/Default/Current/Collections/{collectionName}/Documents/{documentName}.
Using this in a browser works just fine. All that needs to be done in order to use this with an external application is authorization.
If you use sdk methods from docs like VSS.getService(VSS.ServiceIds.ExtensionData) you can view (easiest in dev tool in browser) the request.
Its look like:
https://extmgmt.dev.azure.com/{organization}/_apis/ExtensionManagement/InstalledExtensions/{publisher id}/{extension id}/Data/Scopes/Default/Current/Collections/{collections (by default 'MyCollection')}/Documents
I've implemented an application using Moqui Framework. I provided url:http://localhost:8080/fvl-plus-runtime/rest/s1/example/examples
It is getting error like:
User [null] is not authorized for View on AT_REST_PATH [/example/loginexamples/{username}]
You can add ArtifactAuthz records for all users, like the ones already in place for admin users for the REST APIs. In general it is best to secure all API access, and that is how things are setup by default. There are various examples you can follow to see them in action, see the extensive comments in the rest.xml file (the XML Screen for the /rest path).
This feature as been added in commit #44272ba. You are now able to create a new REST service and set require-authentication=anonymous-view or anonymous-all.
See How to create a publicly accessible REST API in Moqui for more details.