Could someone please tell me how to access CRM (IFD) webservices from outside the domain?
First you'll have to set up the instance for IFD support. Microsoft has an IFD setup tool.
You'll then want to make sure your website is exposed to the internet. It sounds like you can successfully ping it from the above comments.
You can then use the web services if you provide the appropriate url and network credentials.
service.Credentials = new System.Net.NetworkCredential("username",
"pass#word1", "domain");
A VPN setup is often a good way to accomplish this. That will involve opening the appropriate ports in your (or your company's) firewall, as well.
thats exactly what i did and i found out that theres nothing wrong with the way i access the web services but sommeone has turned off basic authentication of the CRM application, turned it back on and problem is solved
actually if you right click on the website(from iis) and go into the security section, it lets you select the authentication type , eg: anonymous, basic or windows. you should not require to turn off the authentication in CRM, as i found out you need to have basic authentication enabled in order to access remotely.
regards,
lasa
Related
I have a web application on my domain, I just allow so IPs to connect, talk and retrieves from my app, now the problem is that another API needs to talk to my app and retrieve info, but I can't open my app to the public , also the API doesn't allow token authentication, it just wants to connect to my app from any IP, any ideas to solve this?
a third party is an option but I need another practical option
I am trying to answer your question from whatever I can understand, if api does not allow any token authentication , then you need to implement something which will authenticate/validate/verify the incoming requests.
Now, if you don't have any scope of changing the implementation of the existing api, then probably you need to add a layer of say API Gateway. If you are using or want to use spring boot then it provides very simple implementation of it through Netflix Zuul.
If this doesn't answer your question, please provide more details.
I am currently working on a single-page web application. The web app will make calls to a REST-like API for authentication and data storage. We are currently in the middle of securing the application, and have worked out a strategy securing the site so only registered users can gain access. But one thing we also want to do is securing the API from others to write their own applications, or access it in any other way than through our web application. The problem from my view is that the API will be open for everybody and not only for my web application.
Anyone who knows how to do this, or who can point me in the right direction. Because right now, don't have a clue.
Considered using certificates and validation?
Your API should only be accessible, if the session of the client is authorized. That's pretty much anything you could do.
There are complex approaches like using client- and server-side encryption or something really basic: render a secret in your webpage that validates the user again on every request.
You could check the headers, where the original request comes from. And so on...
But as most of that is public in a users browser, anyone could read it and adopt it in a third party app.
So save yourself and the people that really want to do a third party app some time and provide a public API :)
Simplest way will be to use OAuth 2.0 ( supports both authentication and authorization) which you need.
Also ensure you secure the data on wire using TLS (HTTPS) and any of the options below
1. HTTP Digest
2. OAuthn 2.0
3. Certificates ( Shared secret)
Stick to HTTPS+Oauth2 for now.
You could lock down your you API to accept requests from known IP's. Also depending on how your network infrastructure is designed, your web application can sit in a DMZ and your API on an internal network accessible only by servers in your network, one of which will include your backend API (This article here info https://www.digitalocean.com/community/tutorials/5-common-server-setups-for-your-web-application has some tips). For better security, a secure network design in addition to an application security framework implementation like OAuth2 and HTTPS (mentioned above). For API's, I've found that resource based authorization works better than role based authorization. Lastly, constant review of your security setup is vital as things change all the time. A good approach to this is Threat Modelling described by OWASP here https://www.owasp.org/index.php/Application_Threat_Modeling
I am working on a cross platform app that will be created using C++-> mobile devices, and using Perl-> Desktop PCs (like Windows /Linux/Mac OS).
Now, since the app will be downloadable, I have concerns regarding the ability of hackers to obtain the source code of my app.
Specifically, the app will connect to my central database-- at the minimum, I want that hackers are not able to obtain my database connection details. Ideally, I would want no part of the code to be hacked.
Basically, the user can update some of his information using this app-- if hackers get hold of this data they can easily change any unfortunate user's data. One thing that I have thought of is that the user will have to initially authenticate with OAuth/OAuth2 ( using his email ID #yahoo/#hotmail/#gmail)-- and only after that the app will actually show the admin interface. But at any rate, at some point the app will connect to the central database-- which is why I dont want the database's access details to be compromised.
Many organisations make such apps, so they must be facing this type of problem themself? I would like to know how I can protect my app (ideally entire code), and atleast the db credentials.
The simple answer is you do not expose your database. Ever.
Add a service layer (could be HTTP-based but doesn't have to be) on top that will deal with authentication and authorisation. Your app then logs in using the user's credentials and acts on their behalf. Your service layer exposes an API which your application talks to, but your service makes and controls all calls to the DB.
You already mention OAuth - that's a perfectly acceptable way of adding authentication to such an API.
You cannot.
On the bright side you can put security on your server. The connecting client provides credentials that they are a given user. The server generates the SQL command after proving the request is allowed. Backers can do anything your app can do, but your app becomes incapable of behaving badly to your database.
The previous answers are absolutely correct. You want a server based service layer that provides the authentication/authorization code and interacts with the database. However, it isn't always a perfect world and if you are stuck with the requirement that these applications must act as a database client you want to limit the exposure as much as possible. Typically this is done by having the client use a specific account which has not been granted any access to the general database. You then create specific stored procedures that can only do the operations and queries that are required of the application. This prevents anyone finding the credentials in the code from doing anything in the database that isn't intended, but you still have the problem that anyone can impersonate someone else by reviewing the code. There isn't a way to prevent that without a server side component. This might be okay for a closed/trusted group of users, but I wouldn't release anything to the general public with this method.
If you can do it, use OAuth2 and allow a trusted third party handle authentication. Twitter, Facebook and GitHub are all relatively paranoid about security; and the other poster is correct: never expose direct db access as part of the app the user has access to; put it behind a service of its own.
Good luck! :)
I have a SharePoint server running on my network and I am trying to build an app in Delphi which allows me to access the various SharePoint Web Services hosted there.
Running my app on the same network as the SharePoint server works fine, however, when I attempt to run it on a VM which is not part of the same Domain I can't get authenticated. I was looking for some advice as to how I should be handling authentication for this type of scenario, more specifically, should I be prompting the user for their credentials or is there some built in security model I can use for this?
Ideally I would like to try avoid dealing with Usernames & Passwords in my app and let the OS handle that sort of thing, however, at the moment I can't seem to see any other way around this.
After some investigation, for my particular scenario I decided that the best approach would be to use WinINet. I chose this approach over Indy because after some thorough investigation I found Indy did have some bugs & also it didn't have all the authentication handling we needed built in.
WinINet supports prompting for credentials & automatically authenticating across the wire. See Handling Authentication.
I'm learning about web services and most of the resources I've been reading talk about registering your web service once it's ready for use by others. Is registering a web service required to use the service?
For example, let's say I have a web application on a company intranet and I create another web service app that retrieves some sort of useful information to be displayed on this private intranet site. Would this new web service require being registered just so my web app can use it or can the web app simply interface directly to the new web service (following the WSDL file) without the need of some sort of UDDI registry?
You can certainly use the service without the UDDI registry.
I have created several Web Services and have immediately used them without registering them. Registration gives others confidence that your Web Service is legitimate and descriptions of how to interact with those services.
Imagine doing development where you have to register any Web Service before using it. Yikes!
No, not at all.
You are probably talking about API directories you may register your WS at. Like UDDI or what it’s named. Entirely optional.
Nobody uses UDDI anymore. It's an idea whose time has come and gone.
It was thought that there would be public registries of web services that everyone would use to find a web service to meet their needs. That never happened.
How could either the service or the app know whether or not the service was registered?
Furthermore, why would they care?
If you're trying to use service orientation the right way, your web services should be registered within a service registry. The registry should contain the published contract of the services and any meta-data that helps the discovery process.
A different questions is: does a service consumer program need to look up a registry and dynamically bind the service it needs to call? NO, NOT AT ALL.
But then, what discovery process am I talking about?
I'm referring to a human (developer, architect, etc.) who is designing/developing a program that needs to call a service. This person should have means to search what services are available in his/her organization. If not, the benefit of reusing services is compromised.
Discovery is also about humans finding out there's a service somewhere in the IT organization that offers the functionality they want.
In this case, the registry can be as simple as an html report that is created and updated manually or generated by parsing (xslt comes handy) the wsdl files.