I want to execute the signup user-flow in Azureb2c from an ASP.NET Core Web API instead of executing it from our frontend app. To achieve this I found an approach of using API connector.
The documentation of API-Connector says
You can use API connectors to integrate your sign-up user flows with REST APIs to customize the sign-up experience and integrate with external systems
I assume with this explanation that I can execute a user-flow defined in AzureB2C for signin-signup from a Web API as a Http Request. What that is not clear is how the API connector actually work. When we still are in development phase and want to execute the API-Connector (and execute the user-flow via this), what type of http request we are supposed to send? Will it contain the Id/password we had defined when creating the API-Connector along with the user-details that needs to be passed to signup user-flow? What the URL which we had added when creating the API-Connector will be used for?
Unfortunately there is not much data available on API-Connector apart from the Azure official documentation, which I felt a bit confusing.
I am looking into developing integrations for the Acumatica Cloud ERP. I am developing a SaaS product on Azure which extracts accounting data from various sources. From the documentation provided by Acumatica, I can see that the API connects to a local instance of Acumatica. If I were to connect to a local instance I would need to use some sort of gateway which connects to a local machine. I also had to install a local instance myself to be able to create a client application and use OAuth 2.0.
I am having issues to understand how to create integration with Acumatica.
Do I need to know the instance name / URL of each of my clients? Do I need to have a local instance running to be able to use Acumatica APIs? Can client Acumatica instances be publicly accessed? If the client using authorization code flow, authorizes my application to extract data from Acumatica, what is the Acumatica ERP URL that I should be using? Mine or the client's? The documentation always uses localhost to connect to an API.
If you use any of the Apis provided by Acumatica:
Contract Based REST (Recommended)
Contract Based SOAP
Screen Based SOAP
You only need the a set of credentials and the URL of the site to communicate with it from the outside. By set of credentials I mean that the credentials that you use need to be able to access and perform the appropriate action on the Acumatica screen that you want to integrate with.
You can find more information on how to do so on the help web site at the following link:
https://help-2019r2.acumatica.com/(W(12))/Help?ScreenId=ShowWiki&pageid=ff22837c-cd3a-410e-b768-88ca6e53b165
It is the Development Integration Guide
Edit
Since you are mentioning Authorization Code Flow in the comment, here is the link that contains more information
https://help-2019r2.acumatica.com/(W(14))/Help?ScreenId=ShowWiki&pageid=ff780860-09c2-46c9-bdd7-c6c3b1fc442c
On that screen you will see the following information:
After the user is authenticated in Acumatica ERP, the client application receives an authorization code, exchanges it for an access token, and then uses the access token to work with data in Acumatica ERP.
Which means that even if your application does not handle the user credentials, the users will need a set of credentials in order to connect the application to the Acumatica site. The user used here will defined the access rights that the application has.
Say I would like to implement an application used by several institutions which each have several associates. The associates would need the ability to interact with the application (but aren't necessarily nodes (?)). Thus I would like to build a web interface, providing a way to easily interact with the blockchain. Each institution would like a different interface, conforming to their house style. Also, an associate has to be authenticated to the web interface to be able to use its functionality.
As I understand, each institution would run several nodes. Each node is able to provide a REST API to interact with the blockchain. Each institution would then run their own web service with their own interface interacting with the REST API (ran by one of their nodes)? and thus the blockchain. Then the web service would also have its own (institute-centralized and institute-specific) database which contains associate login details, providing a way to first authenticate the associate before having access to the actual functionality.
Is my way of thinking about this wrong? Also, the REST API would still be directly accessable without authentication. Is there a solution for this?
Thank you for any help or direction.
You don't specifically say if you are looking at Hyperledger Composer - but assuming you are, then having a REST server and a differently styled Web app for the separate institutions is good. Perhaps the Web Apps would function slightly differently for the different institutions too - integrating with different legacy systems for example.
With regard to the authentication, there is authentication built into the Composer Rest server with Multi User mode. The example and the tutorial in the documentation use Guthub and Google as authentication mechanisms, but there are options to use Ldap, AD or other strategies.
Multi User Mode for the Composer Rest server is described here.
I would like to develop a system that can help any developer to create an application based to my API.
My problem is authentication.
I have see (for example) as work google with your services; I would like create an system of oauth (private) such as google (concept) that an developer, after sign to my portal, get APP ID and APP SECRET.
When developer self create these credentials, can use for call API based to https.
My API are developed by nodejs and express system.
I say which way is more stable for create an system robust for this scenario.
Thanks for any support. Any idea is appreciate
You can try http://passportjs.org/, it can work as a middleware with express.
I have the following scenario:
1.- A web api project in Azure, that I want to secure using Azure AD (I don't mind Token, cookie, whatever, as far as it meets the entire scenario)
2.- An Azure web site in asp.net MVC, also secured by Azure AD. This website has to call the web api controller with SSO (I'm using same Azure AD in the entire scenario)
3.- Some JavaScript code running in a page in SharePoint Online, also calling the web api controller in any secure way (The Office 365 tenant is also using same Azure AD). If you don't know about SharePoint, let's say I have an SPA project where I can only use Javascript and html (no server side code).
Following some of the MS Azure AD samples and some blogs from Vittorio Bertocci I'm able to get the points 1 and 2 working fine, using OWIN and Oppen ID connect. However, seems impossible to achieve point 3. As I'm inside a page in SharePoint Online, I can only use javascript, and not any server side code. I'd like to get a valid token for the current user, that is already logged in SP, and remember that SP uses same Azure AD that web api site.
Can I call the Azure AD and get a valid token, just from client code?
I'm open to any possible solution. I can do whatever in the web api project. If you are thinking in a SharePoint app with an appPart, and the appPart calls the web api from server side code, I agree that will work, but it's an option that is not allowed at the moment :(
Many thanks.
I have similar needs. While waiting for a Microsoft sponsored solution we’re working on the following approach.
3) in Your solution (i.e. HTML page with JavaScript, hosted in SharePoint Online and running in Browser) will call Services in 1) (i.e. Web Api Service layer in Azure).
In Our case we only want to validate that the calls made from SharePoint Online (via users browser, i.e. JavaScript) originate from a correct Office 365 / SharePoint Online user in our tenant.
We are opting out of using the App Model as we only want some simple HTML / JavaScript pages in our Intranet and don’t want App Webs. The Web Api server side code is kind of our “Web Part” code behind.
Change to the solution after trying it out and having workable code:
The auth cookies are ReadOnly and cannot be used. Instead we have registered one metod in our service layer as App in SharePoint Online (via appregnew.aspx). That methods url (e.g. https://cloudservice.customer.com/api/authentication/token) is registered as App start page in the app manifest and is deployed to a site Collection.
Now we can call our App via https://customer.sharepoint.com/sites/devassets/_layouts/15/appredirect.aspx?instance_id={GUID} i a jQuery ajax call and parse the result. AppRedirect sends the correct SPAuthToken which we use in our service endpoint (i.e. App start page) to call back to SharePoint and check context.Web.CurrentUser. User email is then stored in Table Storage with a generated Token which we send back to the caller (i.e. the jQuery ajax call to app redirect).
That token is then used in all other service layer calls in order to be sure of who is calling our service layer and in some cases perform authorization in our service layer.
Note, You can use the same approach in order to store Refresh and AccessToken in your client and provide that in all calls to your service from your client and use those tokens in order to do App Calls back to SharePoint. This enables HTML UI in SharePoint host webs and server code using user context in Azure service layer.
To follow up, ADAL.js has recently been released, and the ability to use CORS with O365 APIs was recently added, enabling a scenario for script clients to communicate with services protected by Azure AD, such as your Web API.
http://www.andrewconnell.com/blog/adal-js-cors-with-o365-apis-files-sharepoint
UPDATE 2018:
This is now supported by SharePoint Online and the SPFx development model, and officially documented, for instance here
Consume enterprise APIs secured with Azure AD in SharePoint Framework
Being said that the work done meanwhile by Vittorio, Kirk, and their teams, but extending that also to Andrew that has delivered great samples, is awesome; that doesn't really fully reply the original question because one of the requirements is to don't run the component as Add-in Part.
If you try to use ADAL JS (which starts its own OAuth flow) hosting that directly in a SP page, that's not going to work, or anyway you can expect a weird behavior for the user (cause of client redirects happening on the browser).
The solution proposed by Peter Karpinski is interesting, and will work matching the requirements in the original question, but requires quite some complexity and additional management/resources.
This recent article provides an alternative solution similar to Peter's one, but requiring less 'extras' and somewhat simpler, also reusing user's SP identity.
Consuming Azure Hosted Web API from SharePoint Online using JavaScript and Office 365 identities
and doesn't either require the use of ADAL on the client side and the implementation of custom security provider / token issuer on the server side.
The identity (cookie) will be passed via properly handling CORS (documentation) on both sides.
However, as you can read in my comments to that blog, this won't work normally with IE due to its security zone implementation. You'll have to be sure you have control on IE security zones on the clients, or have an alternative solution specific for IE.
As of today AAD does not support the OAuth2 implicit flow (or OpenId Connect variants) hence you can't obtain a token from AAD using a user-agent (browser), regardless of whether you hit the wire handcrafting the protocol or using a library.
However keep an eye on future announcements, as this is an important scenario for us!
HTH
Cheers,
V.
update we now support the implicit flow on our server, and we released a library for helping you consume the new feature: http://www.cloudidentity.com/blog/2015/02/19/introducing-adal-js-v1/
Thank youi for r your patience!
The fact that you say you can use only HTML/JS let me guess you're having a SharePoint-hosted App.
Azure AD Authentication Library (ADAL) doesn't provide yet in this moment support for HTML5.
I've been looking since a while (almost one year) on how to implement something as you say; but I couldn't find any working solution, which doesn't make use also of some 'code-behind'.
I'd suggest you then to move to a Provider-hosted App, where you'll be able to have some C# code, and make use of ADAL to retrieve and reuse the OAuth token.
Also, I think is worth to look at this documentation page:
Choose patterns for developing and hosting your app for SharePoint
at section Match your hosting pattern with your development goals
thanks for your help.
Well, it's not a SP-Hosted App, but it's same scenario. It's just a SP page in SP Online, so I can only use JS code like in a SP-hosted app.
As I said in my question, I agree the Provider hosted app is likely the right (or at least, the unique) solution, but that means to build and app, deploy it, and add teh appPart manually to the page (is not easy to package in a WSP). So, this solution is quite hard, when you only want to make some AJAX calls and show some data.
However, after all that I've seen, I think we can't do anything else. I'm gonna wait some more days to see if someone know any weird workarround that could work, and if not, I'll mark your answer as valid.
Thanks again!