I just finished integrating DocuSign API into my C# MVC application. My MVC app is NOT .net core. So far I worked with OAuth Token Generator from the developer portal of DocuSign and hard coding the returned token.
Now I need to implement the oAuth token generation on the fly and
I need to do the Authorization Code Grant. But not sure how to implement it with C#. When I make a request to
https://account-d.docusign.com/oauth/auth?XXXXXX
from MVC app I am getting a cross domain error. Please advise how to proceed?
Once again I am using a regular MVC app and NOT Core. In the sample app is in Core and
that doesn't help me.
Any help is greatly appreciated.
thanks
Are you using latest Chrome? its default mode would have strict cookies and not allow an app launched from localhost to store cookies in other domains.
Another option is that you're using an iframe, that is not allowed for auth either.
I would suggest you install the VS Extension and add DocuSign to your app as a way of a shortcut.
Otherwise, may need to debug the issue, try a different browser, host your code somewhere or change the way you do auth.
Good morning everyone,
I am attempting to pull data from a locally-hosted (in IIS) Web API from a Dynamics 365 plugin. I set up the Web API to use "Individual User Accounts" and made it publicly available. That is working correctly in Postman when I test it as I can get the token fine, then use that token for queries.
My thought was that in the plugin I would request a token using an HttpWebRequest and then use that token for future queries.
My problem is that I cannot call that Web API from a Dynamics 365 plugin at all as I get a security error when I attempt to run the code in the Plugin Registration Tool. Here is what my research has yielded on the topic.
1.) I cannot access the Web API because I have not registered it in/as a "Microsoft Azure Web App." My question on this would be that since we were not planning on using Azure (and I am not sure it fits the safety specifications of this project) "do I have to register it with Azure?"
This quote below is from MSDN on the topic of web service calls in plugins. I'm not sure what I'm missing/violating in my setup.
Web access
Sandboxed plug-ins and custom workflow activities can access the network through the HTTP and HTTPS protocols. This capability provides support for accessing popular web resources like social sites, news feeds, web services, and more. The following web access restrictions apply to this sandbox capability.
Only the HTTP and HTTPS protocols are allowed.
Access to localhost (loopback) is not permitted.
IP addresses cannot be used. You must use a named web address that requires DNS name resolution.
Anonymous authentication is supported and recommended. There is no provision for prompting the logged on user for credentials or saving those credentials.
2.) I have found a lot of people saying that the Plugin Registration Tool will always throw a security error due to my plugin being sandboxed. Does everyone just use trace logs for debugging this?
3.) I have been researching the use of Dynamics 365 Web Hooks but I need this plugin to execute on the "RetrieveMultiple" Event. Is that something I can do with D365 Web Hooks?
Thank you all so much for your help. Have a great day.
Your webservice should have a public accessible https-URL, so dynamics 365 can access it from anywhere. You should secure your webservice by a login mechanismn.
As testing, security and configuration advice you should not add url, username and password in your plugin code, instead make it configurable in a crm record. So you can develop and test on a different webservice instance and your production instance connects to the right webservice without changing the code before deployment.
I have a website hosted on azure. The website is expected to get opened only from the UWP application and should be prevented to get open from browser directly. I was checking deep linking Web-to-App approach. Are there any other options to do this?
The only way you could do this would be to setup some kind of client authorization mechanism in a way that the app would add some additional request headers to with authentication information that the server would check to verify that the client is indeed the app.
You should look into IdentityServer4 documentation, as they show how such functionality can be implemented. You could implement this yourself or use IdentityServer4 or some other tool in the respective language you use on your backend.
I am quite new to the world of Xamarin and mobile development, but have been asked to create a simple cross-platform mobile app which is able to log into a secure web server, download some SQL data and then display it in the app.
What I am trying to understand is how to get the mobile app to request the data from my web server securly. I've seen and read a lot of information about requesting data from a web server using HttpWebRequest, but none of the examples describe how to secure this data. Also I see a lot of info about creating a REST API, but again I am not sure if thats the way I need to go?
Can anyone give me a really simple breakdown of the steps I will need to implement in order to achieve this? I feel like I'm drowning in a sea of web technologies and not sure which way to swim :)
I will be using IIS as the database and the Xamarin App will need to run on both iOS and Android.
Any help greatly appreciated!
Mike
It´s a bit confusing the way you want to implement this and the level of security you need. There are many techniques to secure your app and your server. Some are easy to implement and others not so easy.
What I understand is that your application will be hosted on IIS. There is no such thing as a IIS database. IIS is just an application server by Microsoft.
The most common technology hosted in IIS is Asp.NET and Microsoft SQL Server database. But others can be used, like php (installing some extensions) and mysql server. Anyway, using just php in IIS is a bad decision IMO, as there many other light weight and better servers to do that.
Xamarin has nothing to do with server security. Xamarin is just a client technology and the security must reside on your server application.
That said, there are many good practices you should follow to make clients more secure:
Never store user passwords or sensible data on a local store (device database, settings, file system, etc)
As others suggested, send your data to the server through https protocol (SSL must be configured on the server side)
If you must save critical data on the device, use an encryption
algorithm (there are tons of libraries to encrypt local SQL
databases, just google it)
In case you go for Asp.NET I suggest that you go ahead and integrate Asp.Net Identity. It´s the standard authentication/authorization system for ASP.Net and the built-in features will handle you user database as well as security issues you would hardly find out by yourself (ie: storing passwords "as is" in the database is a big security hole)
Afterwards, you will have to choose an authentication (login) system. There are multiple choices but the industry standard would be oAuth2. Use refresh tokens if you want to make oAuth2 more secure. oAuth is supported by Asp.Net identity and Xamarin. For Xamarin you can use an oAuth .NET client library or make simple http calls (HttpWebRequest) to request tokens, refresh tokens, etc.
About REST API: I think that´s the way to go, no matter what client or server stack you´re using. Again, Asp.NET has a WebApi that will enable REST on your application.
If all this sounds like too much, don´t worry. When you create an Asp.Net application in Visual Studio using a template, you will get a ready app with REST (WebApi) and authentication/authorization/security (Asp.Net Identity) by default.
It´s important that you implement oAuth correctly both in the server and the client side. Otherwise you could face some security problems
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!