My company is building an occasionally connected app, and we're thinking about using the Microsoft Sync Framework.
From what I can tell, though, clients are required to connect directly to the database server in order to sync. This sounds like a security hole. I could use a VPN to connect to the server, I guess, but my database is on EC2, and we've wasted lots of effort trying to get a VPN solution work on EC2 to no avail. I've read plenty of other tales, confirming that software VPNs on Windows/EC2 don't work.
Any suggestions on how to architect this Occasionally Connected App?
Clients do not need to connect directly to the database. It's very easy to sync over a WCF service using wsHttp or netTcp bindings.
See the tag Faq here: https://stackoverflow.com/tags/microsoft-sync-framework/info
Related
I experience really slow performance on SSMS (V 18) when connecting to an Azure database (as opposed to an on-premise database)
I get performance issues when using the Object Explorer -e.g. when opening a View definition or opening table Design view. Regular Query performance is not the issue.
Has anyone else experienced this?
What is the solution?
Your Azure database is hosted in the Azure cloud. You are connecting via port 1433 over the WWW. Things like the object explorer are heavy hits on network utilization and things like default timeouts etc. are going to be highly un-tuned to your situation. Some things you could do:
Fire up a VM in Azure, install SSMS, open the firewall ports and see if you experience a lot more performant SSMS features.
Validate, or improve your internet connection. Latency, down/up speed being highly important.
Lastly, as this is likely NOT your main issue, increase your tier level for the hosted database. Assuming this is a hosted database in Azure? The default tier is NOT very performant and if you have a lot of objects it's trying to pop into your object explorer, this could help.
In addition to #maplemale answer - check whether your database connection is set to Proxy or Redirect.
If you can open the 11000-11999 port range in your corporate network then you can benefit from a Redirect connection where your client connects directly to the VM hosting your database rather than being proxied by Azure.
I am creating simple application where I need get and fetch data to DB. As I find out from Xamarin app is standard using of HTTP request to DB instead of directly connect to DB.
I create Azure SQL DB, I create application with connection to this DB. But I cant really find out how it now should works.
There is no many tutorials or they are not fully described.
I read this one https://learn.microsoft.com/en-us/azure/app-service-mobile/app-service-mobile-xamarin-forms-get-started#download-and-run-the-xamarinforms-solution
I find many references on this one but it seems out of date. Everybody recommended download the project from section
Run the Xamarin.Forms solution
On the settings blade for your Mobile App, click Quickstart (under Deployment) > Xamarin.Forms. Under step 3, click Create a new app if it's not already selected. Next click the Download button.
Under this tab I have only references to next tutorials but not any to Project Download. (screenshot below)
https://imgur.com/THCdUE1
Can you give me some advice if I do something wrong? Or link to updated tutorials? I am little desperate from this
Many Thanks
Azure SQL is not an HTTP/s service-- it runs proprietary SQL Server protocol on port 1433, just like on-premise versions of SQL Server.
If you are trying to connect directly to SQL Server from a Xamarin App, you are almost certainly making a mistake. Doing so would require providing credentials to your Xamarin app that can connect directly to your database, which opens your database up for a malicious user to do pretty much whatever they want to. The reason this kind of 2-tier application is dangerous is because the Xamarin app runs on an untrusted device (your user's mobile device), and a malicious user can intercept any data that your application has in memory, including your database credentials. They can then use those credentials to gain access to your database. Unless you were to use unique database credentials for each user (very impractical) and setup very stringent security roles in SQL Server, it'd be impossible to keep a malicious user from accessing the database for all of your other users (which is very, very bad). The other problem is that many networks block traffic on port 1433, or only allow access via an HTTPS proxy server, so your application would not function on many networks if it tried to connect directly to SQL.
This is the answer to your question, but please don't do this:
If you are certain that you have taken care of the security correctly, you should be able to install the System.Data.SqlClient nuget package and use that to communicate with SQL Server as you would with any .NET application. Here's a code example from Microsoft.
This is my opinion on what you should do instead:
The correct way for most Xamarin applications to communicate with Azure SQL database would be via an intermediary application server.
If your application access data specific to a user, should have per-user credentials in it (username and password that get exchanged for an authorization token when the user logs in is a common technique). The Xamarin app would then use HTTPS to make requests to your application server using those user credentials. The application server would validate the user credentials (authenticate that they are legitimate and authorize the data being requested based on who the user is) and make requests to Azure SQL.
If your application only access public data anonymously, then you can make unauthenticated requests to your application server which will blindly request that data from Azure SQL and return it to your client (though it would also return the same data to any attacker on the internet, so be sure if you use this approach you intend all data served to be public to the world).
In both cases, your application server would be the only piece that communicates with Azure SQL. For a .NET application this would typically be done via System.Data.SqlClient or perhaps indirectly through an ORM like Entity Framreworks. The advantage to this 3-tier approach is that the untrusted client tier does not have unrestricted access to your database tier. Only the middle application server tier has the credentials for SQL Server, and it is trusted and runs in a secure environment (a server you manage, not an end-user's mobile device). This means that an attacker cannot intercept the database credentials and misuse them. It also means that your application only requires HTTPS data access to function, so your application will work on almost any network.
This is probably not the answer you are looking for, since it involves authoring an entire application server that has to be hosted by you (Azure App Service would be my recommendation, if you are already using Azure SQL). It also requires you to implement an API on the server, and then write an API client for your Xamarin application. This is no small amount of work.
Now an application is connected to a database server in the same LAN and performs selects and inserts.
The database will be moved to a remote location accessible throughout internet. Performance degradation will be addressed reducing the number of operations to the db. It is not possible to use vpn or configure access-in rules based on client IP on the firewall of the net where the database server will be moved. So it seems to me it is necessary to create a database front end in order to protect it. I suppose one way to achieve this goal is to create a web service.
Are there easier alternatives?
I'm new to web services: it should run into Glassfish server while the client would be a c# application.
I read a bit about securing a web service but I'm a confused.
One method I found in internet is to use Glassfish built-in authentication mechanism and configure web.xml limiting the access to the web service URL to a group of users.
It seems an easy approach, are there any drawbacks?
Is it easy to use this type of authentication in the C# client?
Other existing web services wants a parameter key in the request. Then this key is compared with valid ones and if the check is successful the request will be accepted.
Is this approach more secure than the previous one?
Another alternative is to use WSIT but at a first glance it seems over-complicated and all the security mechanisms need a server certificate.
Anyway it looks more secure; does it fit well with JAX-RS and restful web services?
You can use L2TP or PPTP VPN in this case.
Let me show you first Network topology.
Client (accessing firewall with L2TP or PPTP )-----> Firewall (L2TP or PPTP VPN Server)---> Firewall LAN where your Server placed.
In above case all Client come from VPN so its secure and On firewall you have to Configure VPN to LAN rule with client base rule.
In our development team we have:
4 developers
one application uses PHP and database Microsoft SQL Server 2008r2, except one using PowerBuilder instead of PHP and one using MySql instead of Microsoft SQL Server
All applications are database-centered, some of them are for general public, some are not.
Question is: for the procedures and functions shared by all applications, what does it make most sense to use, database procedures/functions or web services?
We could not find an agreement within the team.
Whatever you answer, please explain the reasons.
Webservices and Database Proc/Functions are two entirely different things.
Webservices are the services over the web, mainly used when a client and a server interact and client interacts with the server through web or HTTP or any other protocol.
Database proc/func - are created to interact with a login to a DB server.
In your case, if all the application are in the same domain... then you dont need to access through webservices and also it is a lot of overhead.
You can create a common DB server , where you can keep these proc/func and can be consumed by all.
Is this possible through some tcp redirection? If so, how?
Edit: I'd like to connect to on-premises SQL from a worker role to do some custom ATS-SQL synchronization.
About 18 months ago, Clemens Vasters posted an article about building a Port Bridge over the Service Bus, which demonstrates how to connect to an on-premises SQL Server database. No use of Azure Connect. The article is here.
This is just a sample, and not necessarily considered production-ready, but should hopefully get you going in the right direction.
You can try out the new Service Bus EAI & EDI Labs Release. It provides connectivity to various on-premise systems including SQL Server. The connectivity is provided using Service Bus Relay, and may be exactly what you are asking for. In the process, we can do transformations of the data on the cloud etc.
It is not in production yet, but we would like to get feedback on this.
http://blogs.msdn.com/b/windowsazure/archive/2011/12/16/announcing-the-service-bus-eai-amp-edi-labs-release.aspx
Thanks,
Sameer [MSFT]
sameerch # microsft.com
Have you looked at the Sync Framework to synchronise your data?
Sync Framework: SQL Server to SQL Azure Synchronization
Much as I love the idea of routing raw TCP traffic through the service bus the performance is going to be pants (sorry Clemens...)
Have you taken a look at WIndows Azure COnnect
http://www.windowsazure.com/en-us/home/tour/virtual-network/
This will basically give you a VPN like connection back to your on-premise SQL Server. If you can make it work (i.e. can install the agent locally) then this is probably the best approach.
If all you need is data sync, have you looked at SQL Azure data sync?
http://social.technet.microsoft.com/wiki/contents/articles/sql-azure-data-sync-overview.aspx