This question is an updated version of a previous question I have asked on here.
I am new to client-server model with SQL Server as the relational database. I have read that public access to SQL Server is not secure. If direct access to the database is not a good practice, then what kind of layer should be placed between the server and the client? Note that I have a desktop application that will serve as the client and a remote SQL Server database that will provide data to the client. The client will input their username and password in order to see their data. I have heard of terms like VPN, ISA, TMG, Terminal Services, proxy server, and so on. I need a fast and secure n-tier architecture.
P.S. I have heard of web services in front of the database. Can I use WCF to retrieve, update, insert data? Would it be a good approach in terms of security and performance?
A web-service tier is pretty common for smart-clients as a layer between the user-client and the server. This allows:
simple networking (http only)
you have an app-layer in which to put validation etc without upsetting the db
you can have security that isn't tied to the db
the db can run as fewer accounts (app accounts), allowing greater connection pooling
you can "scale out" the app layer
you can cache etc above the db
you can have a richer app layer, with more services than sql server provides
the client has a known API, and never knows about the db (which is an implementation detail)
You can use WCF to talk to the app layer, but you shouldn't think in terms of "INSERT", "UPDATE" etc - you should think in terms of operations that make sense to your domain model - the "CreateOrder" operation, etc. ADO.NET Data Services allows an API more similar to your "INSERT" etc, but it isn't necessarily as controlled as you might like for a secure service.
Performance is really a factor of "what queries am I running?" and "how much data am I transferring?". As long as you keep the operations sane (i.e. don't fetch the entire "Orders" data over the wire just to find the most recent order-date), then you should be OK.
Related
I'm a newbie at SOAP and web services (2 day experience).
I use Bonita Open Solution as a BPMS in which I have a 'WebServer SOAP 1.2' connector. I need to get and write data from/into a database using SOAP. I don't want to use the 'SQL Server' connector which is based on JDBC because the system will be tightly-coupled.
Is there any already implemented SOAP web service in SQL Server 2008 to do that or should I develop my own? In case I should develop my own, I'm guessing the best way to do so is using ASP.NET, am I right?
Before you do anything, you need to decide exactly which data is required by the BPMS system and what access it requires. For instance, it may need read access to some data, but read and write to other data. Your service should only expose the data and operations which are actually required, and nothing more.
Your data is precious - don't expose more of it than necessary.
I recommend that you use Entity Framework in a database-first mode, but only add the required tables to the model. Then, simplify the model by removing columns which are not required, simplifying relationships, etc. Thus, you are exposing a conceptual model of your data which makes sense to the consumer, rather than having to expose every implementation detail of your database (do you really need to expose every junction table, for instance?)
It is then pretty simple to write a WCF service that uses Entity Framework to do the hard work of data access.
Even if deprecated, Sql Server 2008 has native SOAP web services (see Native XML Web Services: Deprecated in SQL Server 2008).
You need to balance the risk of a Sql Server upgrade against the cost of developing (and maintain) a custom service.
My enterprise SQL Server deployment is currently local to our extranet. Now, I would like to expose some of this data to not only be consumed by web services and mobile apps, but allow those apps to actually create new records in the DB.
Also, one of my main hesitations is security. From a conceptual standpoint, what is involved in exposing data via a web service and ensuring that both the data and connection remain secure?
Are REST/OAuth or SOAP the only feasible options?
Speaking from the SQL side: We control the flow of data through stored procedures.
Web service/mobile app uses a sql login to access data in the database. The sql login ONLY has access to execute stored procedures. Those stored procedures use parameters to select/update/insert/delete only the records specified.
This prevents the app/web service from seeing any of the base tables or schema.
However, I can't speak on the security of the connection, that is an issue our developers and architects deal with.
My company is planning to turn an older Winforms application into a WPF/Silverlight Client/Server app.
The idea of having a small server app is to have a list of the accessible data bases combined with the user type that may access each of the databases, instead of having to manage databases in each client's admin control. Additionally, it would be great if the SQL request would be handled by the server which would then return the result.
The app is supposed to work on a arbitrary set of databases which will be "registered" with the server and users get a list of databases according to their authentication rights. They can then do practically everything on those databases what one can imagine. The system should be able to handle up to 2 million rows.
The databases are very different, there can be many of them, they can be MS Access, Oracle, SQL Server etc., so no way for me to specify them all before. On top of that, communication with a SQLite cache is needed.
I already have everything I need for the SQL queries from the Winforms app.
I was thinking:
1) A simple WCF server specifying in a config file the available databases per user type.
2) Interface that specifies all necessary SQL queries that can be made to the server.
3) Client...
The idea is:
a client-server application, where the client uses WCF services to execute SQL queries (INSERT, UPDATE, SELECT, etc.) on tables by invoking services methods.
The service should ideally be consumable for both the WPF and the Silverlight app.
Is that the way to go? Which exisiting technologies might I want to make use of regarding formats, communication, services etc.
If that is problematic, I would consider going back to a desktop app, but then how to ease the user type/database access problem for each client?
I would stick with ADO.NET and start with the DbProviderFactory class. This will let you determine the proper database access based on information supplied by the provider using the Factory Design Pattern. So instead of having to create a specialized objects for each database type and database, you can abstract that logic with the DbProviderFactory.
Here's a link that shows some examples: http://msdn.microsoft.com/en-us/library/wda6c36e(v=VS.100).aspx
I have decided to learn Silverlight, but apart from knowing how to write apps, I also need to know how to connect to a remote server to fetch data. I have seen some examples of database connection in .NET, but I am rather confused by which way to go.
My generic question is how do SL applications connect to remote servers? You could post a subjective response if you like, but this question should be objective in that I want to learn about the possible ways of creating a connection to a remote SQL server.
Where do these (WCF, XML, Ajax, Linq to SQL, Entity Framework, data access providers, and so on) come in handy? If one wants to establish robust and secure connections, which one of those (or others) are a must-learn? I'd like to grab a book and learn stuff, but before I do that, I need to know what to invest my time in.
Silverlight, being a browser technology, doesn't do direct SQL Server connections. Most SL apps speak HTTP to a server (REST, SOAP, POX)- other options are available, but much more limited than with the "big" .NET Framework.
Probably the easiest way to go for a beginner is .NET RIA Services. It allows simple exposure of various kinds of models built off databases (LINQ to SQL, Entity Framework, etc). LINQ to SQL is the simplest on the model side if you're talking to SQL Server, though EF is fine too (a bigger, more complex hammer). RIA Services will allow you to expose table objects from your model over a web service, and the Silverlight client can consume data through LINQ queries that are remoted back to the server (very efficient- the query criteria lives on the client, while the data filtering happens on the server, and it's all compile-time type-checked against the model, so it's much harder to screw datatypes and queries up or expose yourself to SQL injection attacks). RIA Services will also let you apply various security options and data validation on both ends, and the full power of WCF is available to you if you go lower level and do something RIA can't.
I have been reading that direct access to a SQL Server database over the Internet is insecure, so I am wondering what intermediary I can and should use between the client and the server. What are the best practices in terms of security and performance?
For direct access, you would have to use SSL on your connections, but generally, I wouldn't expose a database server to the internet. I would design my way around it, for example by creating web services in front of the db server.
Use an API - Application Programming Interface . This is a frontend door to the data you wish to expose. This means you will need to define what you expose and how.
For example, Stack Overflow does not allow their database to be accessed via anyone directly. BUT, they have allowed people to access certain parts of their database, via their Stack Apps API. What parts? they have exposed certains parts with their own API -> web url's that spit back data, based upon what you request. The results are in JSON format only (at the time of me posting this answer).
Here is a sample API method that exposes some of their database. (EDIT: hmm, none of the API links work ... the link i was trying to show was ...
http://api.stackoverflow.com/0.8/help/method?method=answers/{id}/
)
Now .. if you don't want to actually think about what data (eg DB tables, if you're using a Relational Database like Microsoft SQL Server or Oracle Sql Server) but want to expose the ENTIRE database .. just via the web ... then maybe you could look at using OData to stick in front of your DB, to expose it?
Another Edit:
I was assuming you ment - allowing the public to access your DB .. not private. Otherwise, this should be on ServerFault.
I'd written this lovely reply pertaining to web access to a SQL server, and then you go and update it stating you have a desktop app in place.
With that, as was said above, the best idea is to not expose a database server to the internet. If you absolutely have to, then there's a few possible solutions.
Implement some sort of VPN connection into the network. I had once instance where we had a large number of sites all connecting to a database server (and company network) via VPN. This kept the database server off of the internet, while still allowing a half decent access time to the information. This was for a retail environment with not a great deal of data throughput
Properly setup your firewalls and permissions on the server. This one should be done anyway. You could put the server behind a firewall, allowing access only on 1433, and only from a specific IP range (which i assume would be possible). This way, you can at least lower the amount of locations a possible attack could come from.
This could all be employed in addition to the APIs and services mentioned above.
You can use with config.php. You must write db name, db user, db password, and host in config.php. Then you can use
[?php require("config.php"); ?]
in you page. Please change [ and ] to { and }.
You could just have a page in your web site's language (e.g. PHP, JSP, ASP, etc...) that queries the DB and returns the data you need in whatever format you need. For example:
If you're using jQuery:
from the client-side:
$.ajax({
url: 'ajax/test.php',
success: function(data) {
$('.result').html(data);
alert('Load was performed.');
}
});
Here, test.php would connect to the DB and query it and the result of test.php would be returned in the 'data' variable.