I am working on a program that uses Azure for it's database. It works pretty good, except that I have to authorize every IP address that I access it from. So, if I go to a friends house I have to authorize that IP, and if I go to a coffee shop I have to authorize that IP...
I am hoping that there is a way to authorize the connection from the program, whatever IP it is coming from. Or, worse case senario, turn off that security measure.
DON'T.
The idea behind Firewalling your DB is to protect your data from anything that could have the SQL Server credentials should they somehow leak. It's for your own safety.
Instead, try to write a quick Web Service with ASP.Net WS/Jax RS/Rails/... to expose the DB data in a sane, secure and thoughtful manner. It's not hard and there are tons of tutorials and books on the matter out there.
Although NOT Recommended, but if you want to turn off this security measure you can allow connections to your SQL database from all IP Addresses by setting the IP address range to 0.0.0.0 - 255.255.255.255 in Azure Portal.
Another alternative would be to dynamically manage allowed IP addresses by using Azure Service Management API. You can manage Firewall rules using this API. You can read more about it here: http://msdn.microsoft.com/en-us/library/azure/dn505717.aspx
So what you could do is have a small service running in Azure. When your application starts, it sends the current IP address to your service and your service sets the IP address in the firewall rules. When the application terminates, it sends another request to your service and then your service removes that IP address from the firewall rule.
As #Machinarius so eloquently said DON'T. .NET already has a way of exposing data through OData services. You get SOAP or Json, LINQ queries, caching, security even down to the entity or operation level.
Exposing an EF model as an OData service is very easy. You can create an ASP.NET Web API OData endpoint using the "Web API 2 OData Controller with actions, using Entity Framework" template as described in the "Creating an OData Endpoint" tutorial.
To call the service from a client, you add a service reference to it and then use the proxy to execute LINQ queries. It could be something as simple as:
Uri uri = new Uri("http://localhost:1234/odata/");
var container = new ProductService.Container(uri);
var myProducts=container.Products.Where(....);
Check "Calling an OData Service From a .NET Client" for a detailed tutorial.
As an alternative, if you need to access your application from random places, why not have a VM configured in Azure with your application installed. And whenever you need your app, fire up that VM, RDP there and work via RDP. Would not need to update connection and much more secure rather then having to allow random IPs to access your database.
I realise this is not an answer to your question, but other stackoverflowers already provided a significant input on your problem. And I do agree with them all. Do not disable the firewall. It is for your own good!
Related
Good morning everyone,
My apologies if this post is too similar to this post:
Dynamics 365 and Azure integration
but I am struggling to understand exactly what is needed in order to setup a web service on an Azure server that is consumable by a Dynamics 365 plugin. Based on my research it appears that it goes as follows but I would like to see if any knows of a better guide.
1.) Construct the web service as normal on the Azure Windows Server.
2.) Register a proper DNS Domain name (friendly-name) and route it to the Azure server.
3.) Secure that Azure server/URL with a certificate.
4.) Call the web service from my C# Dynamics 365 plugin.
Is that everything or might I be missing something critical? Thank you!
4 might be an issue, given you want to use certificate based security, not sure that will work, you might need to use another mechanism, e.g. basic user name and password. Otherwise looks okay.
Plug-in isolation, trusts, and statistics
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.
I have written a web application that is, typically, installed internally by customers (based on IIS/MSSQL server).
When a customer wants to provide external access to the application, we offer the following supported scenarios:
Publish the application in their DMZ (pretty standard deployment).
Use our own platform where we host the application in our own cloud infrastructure for them.
However, because I have more and more customers who misunderstand the requirements for publishing an internal application, I would like to add a "one click" way of providing that service.
My idea is to have a reverse proxy installed on the customer's web server that will connect to a cloud server we control. When the application starts, it will connect to our server, authenticate and maintain the connection. When a user wants to use the application, she will use an URL that directs it to our server (say https://myapp.mycompany.org/CustomerID or https://CustomerID.myapp.mycompany.org). The server will then lookup the list of connections from reverse proxy to find the one matching the customer ID and, if found, use that connection to relay the end user connection.
In essence, that is the same thing as what Azure Application proxy or TeamViewer do, only without the need for using Azure AD or TeamViewer.
Is there an existing framework I can use for building such a service ? I know I can write it on my own but that is quite a large development.
This might sound completely stupid but I'm new to this.
Anyway, here's my question:
I have a virtual WordPress server (bitnami) running on VirtualBox. Currently it's in my local network with an IP of 192.168.43.11. With a Gravity Forms plugin for WordPress I made a survey website.
How do I attach my survey website to ServiceNow? I think I'm supposed to utilize Service Now Web Services, but I'm lost after that..
Do you know what version your ServiceNow instance is? If it's Eureka or later, you can use the REST API: https://wiki.servicenow.com/index.php?title=Getting_Started_with_REST. All tables are accessible for CRUD operations via the Table API.
If it's prior to Eureka (Dublin, Calgary, etc.) you can use SOAP: https://wiki.servicenow.com/index.php?title=Direct_Web_Services.
I have an cloud sql instance up and running and have made a link using a jdbc driver to the instance ip using android studio project. I can successfully run queries from an ip address that I insert manually into the google cloud sql settings and not any other network. This makes my app accessible only from certain ip addresses. Is there a way i can authenticate my google cloud sql to all ip addresses. I do not wish to use the google app engine if possible as I believe it will only complicate my application. My app works well enough is there an easy way to access my sql from any network having supplied my username and password in the code itself?
You can use the console to authorize 0.0.0.0, which will allow connections from any IP address. However, this is not necessarily a good solution. If you embed your database's username and password in your Android app, it can be found by someone else taking apart the apk. If they do that, they will then have complete access to your database. It is more complicated, but you should put some kind of server in front of your database, and have the user authenticate with that server/application, and only have that server communicate directly with your database.
If i am hosting a WCF service so that someone(i.e someone whom i know) can consume my service, but what if someone else(i.e someone whom i don't know) consumes it then would do i? How do i prevent that?How can this be achieved?
Can it be done through service throttling or what are the other ways of achieving this?
If you want some some clients to be able to use (or view) your service and some clients to not be allowed to use (or view) your service then you need to setup authentication on your service so that only clients that you allow can access (or view) your service.
I don't know your entire scenario, but transport security with Basic authentication would probably be enough. To enable that you would disable Anonymous access in IIS, configure IIS to use Basic Auth and then in the binding configuration set:
<security mode="Transport">
<transport clientCredentialType="Basic" />
</security>
Set your mex binding to use the secure binding instead of the default mexHttpBinding.
You would also need an SSL certificate for your site (if using WSHttpBinding).
UPDATE: Here's a sample, Custom Secure Metadata Endpoint that demonstrates how to implement a service with a secure metadata endpoint.
No, there's no mechanism in WCF to allow certain clients from using your service while prohibiting others. You'll need to approach this from a different angle.
One way is to not automatically publish your metadata from your service - e.g. make it almost "invisible" - and then distribute the necessary metadata information in the form of one or several WSDL and one or several XSD files to those clients you want to connect to your service. If your metadata is not available, someone just browsing to your service address will not get any information about what to call.
The metadata exchange is controlled by the <serviceMetadata> behavior, and by having a "mex" endpoint on your service. Remove both and your service is invisible.
The other way would be to prohibit any external users to access your WCF server based on firewalls and network rules. This cannot be done by WCF, but your network administrator could limit which IP's have physical access to the machine where your WCF service runs.
Marc
UPDATE:
In order to ship metadata to those users who should be able to call your service, you can do one of two things:
1) Using svcutil.exe /t:metadata (path+name of your service assembly), you can extract the metadata from your service assembly (e.g. MyServiceLibrary.dll). This will give you one or several WSDL and one or several XSD files, which you need to ship to your intended users. They can put these files somewhere on their harddisk and then in the "Add Service Reference", instead of entering the URL to discover the service, they can type in the name of the main WSDL (which imports all other files) and they'll get their client proxy.
Or:
2) With the service up and running, you could "Add New Project" to your solution, choose a Class Library (MyService.Client), then do a "Add Service Reference" and enter your service URL. This will create all the necessary files and everything in your new class library. Compile this class library and ship that assembly MyService.Client.dll to the users you want to allow access to your service.
With both solutions, you don't need to have metadata exchange enabled, and someone else cannot just walk up to your service and get all the information needed in order to call it.