I am developing an .net Winforms application and I need to secure the connection to the sql server 2008 database. I plan to create a webservice as a middle tier that will handle the authentication and that will provide data manipulation. Is there a better way to go with? Does .net have components or tools for that? What is the best technique?
Any info would be appreciated, thanks.
Define "secure". Obviously you wish to restrict access to data to users who really need that data. However, more information about the architecture is needed; is this an in-house app that will only ever be used inside a (secured) LAN, VPN or hosted environment? Or is this an app used on computers you do not control, that will transmit data over the Internet? How much security you need depends on what types of users will be using the software, from where, and how sensitive the data is.
MSS has pretty good security built-in. You can tie SQL users to Windows domain accounts, you can restrict "securables" (tables, views, SPs, etc) in myriad ways based on user or role, etc etc. I would first look at those capabilities, and seriously consider taking advantage of them in your security plan. One SQL user defined for use by any user of a particular piece of software, which has the permissions to do anything the software may require, is simple, common, and highly insecure.
If that's not good enough, or you want to fully abstract your data layer (for instance, if you need the software to be able to be pointed at any DB type from MSS to Oracle to MySql), then it might be a good idea to implement a Repository model with a service proxy. Like Brian, I encourage you to have a look at WCF. A WCF service is highly configurable, and can provide for independent authentication and for encryption. A well-designed WCF service will be very secure indeed.
Behind the service, you can implement a Repository pattern, which abstracts the details of how data is retrieved from the data store and exposes simple methods that return objects containing the data you want in a ready-to-use form. Now, your service methods will just map 1:1 to Repository methods, possibly with some translation to DataContract-serializable objects instead of the richer domain model available on either side of the service.
Have you looked at building a service tier, using WCF? WCF can bring a whole new layer of abstraction and security from the actual physical database.
WCF also allows you to use more secure bindings than a traditional web service allows, with built-in logging.
Also, check out this book sometime if you want a really good read on .NET Security:
The .NET Developer's Guide to Windows Security by Keith Brown
Related
I'm currently devoloping a N-Tier Application with C# as Business Tier. It's a kind of ERP and I need authentication (email/password) for this app.
I need also permissions based on the login (create orders, delete articles)
All this informations should be stored in one database.
As UI Clients I planned to make WPF Client, ASP.Net and maybe in future iPhone/Android.
As message broker I use RabbitMQ (Clients talk to Business Layer only over AMQP. Due to the advanteges I have more than one Business Layer for round robin dispatching).
On my research for authentication in N-Tier applications I found one advise for Windows Identity Foundation. WIF is completly new for me. All the examples I found handle only ASP.Net Applications.
My question now is:
Is WIF the right thing for me or should I implement this session handling on my own?
If WIF can fit my needs, what is the best way to handle this?
Do I have to implement a custom STS and place it within a WCF Service?
As you are explicitly mentioning RabbitMq, I am suggesting ServiceStack for your service interface.
One issue with MQs in general is that they are decoupled from any meta information, such as HTTP Headers, to inject authentication. You should in contrast provide a property Session (with pre authentication) or UserName and Password in your message (where the later one is not prefered, as the credentials are passed in plain). A sample solution with the built-in SessionFeature of ServiceStack is available in their documentation.
Another nice feature of ServiceStack is that you can decorate your handlers not only with AuthenticateAttribute but also with RequiredRoleAttribute and RequiredPermissionAttribute.
Also: How do you plan to queue a message with Android? Can you expose the internal MQ to the outside, and is there a client available for eg Android? Therefore I suggest a dual endpoint over HTTP to queue messages in whatever MQ you choose to use. More information on how to integrate MQ in your HTTP service is available in the documentation.
With ServiceStack you can spin as many consumer instances you want, as there is a plain communication without all the serivce stuff available.
Trivia: As I am authoring an upcoming book on Mastering ServiceStack I am a little bit biased. Nevertheless I do cover most of your questions in the book, and provide code examples: Bits and pieces to your scenario are already covered here (do not get frightened by specific MQ, they are interchangeable).
Following the KISS principle, I suddenly realised the following:
In .NET, you can use the Entity Model Framework to wrap around a database.
This model can be exposed as a web service through WCF.
This web service would have a very standardized definition.
A client application could be created which could consume any such RESTful web service.
I don't want to re-invent the wheel and it wouldn't surprise me if someone has already done this, so my question is simple: Has anyone already created a simple (desktop, not web) client application that can consume a RESTful service that's based on the Entity Framework and which will allow the user to read and write data directly to this service?
Otherwise, I'll just have to "invent" this myself. :-)Problem is, the database layer and RESTful service is already finished. The RESTful service will only stay in the project during it's development phase, since we can use the database-layer assembly directly from the web applications that are build around it. When the web application is deployed, the RESTful services are just kept out of the deployment.
But the database has a lot of data to manage over nearly 50 tables. When developing against a local database, we can have straight access to the database so I wouldn't need this tool for this. When it's deployed, the web application would be the only way to access the data so I could not use this tool. But we're also having a test phase where the database is stored on another system outside the local domain and this database is not available for developers. Only administrators have direct access to this database, making tests a bit more complex.
However, through the RESTful service, I can still access the data directly. Thus, when some test goes wrong, I can repair the data through this connection or just create a copy of the data for tests on my local system. There's plenty of other functionality and it's even possible to just open the URL to a table service straight in Excel or XMLSpy to see the contents. But when I want to write something back, I have to write special code to do just that. A generic tool that would allow me to access the data and modify it would be easier. Since it's a generic setup around the ADO.NET Data services, this should be reasonable easy too.
Thus, I can do it but hoped someone else has already done something similar. But it appears that there's no such tool made yet...
You are referring to ADO.Net Data Services. It basically creates an Entity Database Model and adds a REST frontend to the service using ASMX. There is a How To article availble from MSDN here on consuming the service using .Net. I have also done the same thing using the normally WebClient class in .Net in the past.
You can also look at the WCF REST Starter Kit if you want to roll your own based on Entity Framework. The starter kit also contains a handy new WebClient class that can be used to communicate with REST services.
Clarification
There is no prebuilt application client that I am aware off which will talk to these service, since they are pretty much accessing the data using Web Services. There is the Microsoft Smart Client Factory which is most likely the closest thing I have worked with.
I mentioned the above 2 options since they already have libraries in .Net that work with them directly, either as a referenced Web Service, or for the more adventurious, myself included, using the WebClient library or alternatively the new HTTPClient library in the WCF REST Starter kit.
I have used both, in Windows, Web, Silverlight and WCF. The latter being the easiest since they are focussed at REST.
We are currently investigating Prism which strongly leans to using this method when using WCF for front-end development.
Assumption
With regards to this question, you are making a generic assumption that wrapping ADO Entity Framework with a WCF service it will be generic. ADO.Net Data Services is the closest you will get, however the structure of the database will fundamently change the way you interact with it. Going a level higher in a "generic" way would be dangerous, as these 2 technologies, individually or together, are already as generic as possible.
In addition to Data Services (+1), consider RIA Services. It's like a domain-specific version of data services for Silverlight or WPF clients. Less flexible, but easier, than Data Services.
I have an application that runs on a server and uses SQL server 2005. If I wanted to make this application integratable with other systems such as a CRM, what would be the best strategy? My idea was to create a public Web Service with authentication...does this sound like the right approach?
Any idea's would be appreciated.
Yes, Ideally all integration is done using industry standard communication protocols, requiring some middleware that links these standards. Ideally these protocols would be something like a webservice as you say where the API ensures validation all data imported into your system.
Most basic integration between systems means Transfer of Data between systems. You can either choose to build an API to which you or others provide the middleware to connect. Or depending on the nature of the applications, you your case CRM, it may be worth ising this same API to build an Import/Export mechanism where users can just just Export their data into xml, CSV and also import their data, building a nice interace to map any CSV format to your own fields is a nice touch and means less technical users can perform non-automated tasks.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
With respect to an application that has both a web and desktop client version:
What is the best practice for the desktop client which needs access to a SQL Server?
What are the benefits of connecting to the database from the application vs using a web service?
Which one provides better security?
What type of scope would call for one vs the other (enterprise intranet vs. web app, etc)
Are there any other considerations that are necessary when choosing on platform?
The general rule of thumb is the following:
Write an independent data access assembly that will talk to the database.
If you are looking for interoperability between different platforms/clients then expose this assembly as a SOAP web service.
If you are looking for performance use the assembly directly in your client .NET applications.
What is the best practice for the desktop client which needs access to a SQL Server?
If you're using a local SQL Server then access the database directly. If the client has to use an SQL database on another system, the use of a web service is preferred for an additional protection and the added advantage of having a business layer that should be able to handle multiple users.
What are the benefits of connecting to the database from the application vs using a web service?
Connecting through a web service will always be a bit slower and modifications to the database will be a bit more difficult to add to the whole system. (Basically, that would mean that you need to create a newer version of the web service while maintaining the older web service for backwards compatibility.)
Which one provides better security?
The use of web services tends to be safer, although security is often more a people issue than software issue. But with the web service between the user and the database, the connection to the database is more secure since the user cannot directly access it. (Except for the functionality you provide through the web service.) This point is moot when client and database are on the same system because then the user can get full access.
What type of scope would call for one vs the other (enterprise intranet vs. web app, etc)
Web services are better for client-server applications, where users should not have direct access to the database. Otherwise, a direct database connection would just improve performance.
When creating a web service, start by writing a generic (class) library which will provide the functionality for the web service. Create a web service around this (business) library, exposing the important methods to the outside world. Any web site could call this library directly without using the web service, although you can always opt to even let the web site code access the data through the web service.
Even if you create just a desktop application with a local database, writing a business library with logic to access the database is just a very good thing to do. Your client could call this business library directly or through a web service, depending on your needs.
Are there any other considerations that are necessary when choosing on platform?
Mostly just the amount of hardware that you're willing to use to set things up. If you can afford to set up a database server, a separate web service for the services and a third for your web site, with a dozen or so client systems, then you can opt for the most layered version, where both client and web site call upon the web service, which calls the database. But if everything needs to run on a single system then just stick to the application and the business layer/library instead.
Adding layers will reduce performance from the view of a single user, though. However, working with multiple layers can improve the overall performance because resources get divided better amongst multiple users.
I'd keep it simple and minimize the amount of layers. Layers cost performance, introduce complexity, and require changes to be made in more locations.
So, if the netwerk connection between the application and Sql Server is open (typically tcp port 1433), I'd use Sql connectivity.
Given the context, there can be a big security concern with client access to databases. It requires either giving users access to the db, or creating a service account. Giving users direct access to the db poses risks. Both approaches open the door to exploiting desktop dll's to connect to db outside of application context (Multiple times I've seen cases where there is a common data access class that all functional operations use. And of course, this components initializes all the connection information. Reflection based access makes it is easy to get to protected or private methods, unless you assert Security Privileges).
Web services expose functional operations that don't expose any sql based operations. Not only is this more secure, it abstracts your client away from your data storage implementation.
Again, it depends on your context. In the Enterprise/ISV realm though, it is generally a big no-no.
If you can acces the DB from the desktop then you should do that.
You have multiple kinds of clients. That means your application should have mulitple layers.
It does not mean you need multiple tiers.
Multiple tiers can be necessary if your layers must transfer data over firewalls or if you have diverse technolgies.
I do a hybrid. Direct database access with limited user who can perform read only from the tables. Webservice with a high privileged database user who can perform write functions. The business rules are built in the webservice (audit trials, permission checks etc)
The direct db access makes it easier for me to develop reports, access lookup values from the client app.
Ok, all these methods of getting data in a Silverlight control are confusing me.
I've looked at ADO.Net Data Services, Web Service and Silverlight-enabled WCF services.
I'm just not sure when one is appropriate to use over another. What pros/cons do each offer?
I've built a web app, and a Silverlight control. I will be adding one of those 3 options to my web application and consuming it from my Silverlight component.
From the silverlight perspective, WCF is heavily constrained anyway, so most of the usual benefits of WCF don't apply. However, it is still a fairly nice, consistent programming model.
WCF is primarily a SOAP stack, so it is very good at presenting data as rigid operations. ADO.NET Data Services is a REST stack, and allows very expressive queries to be performed dynamically over the wire.
I don't know how it is in Silverlight, but a regular ADO.NET Data Services proxy (the bit on your client app) has very rich support for both query and data changes back to the server. Note that applying changes requires either a: Entity Framework, or b: lots of work. But you should get query and update very cheaply with this approach.
With WCF, you get a much more controlled stack, so you will need to code all the distinct operations you want to be able to do. But this also means you have a known attack surface etc; it is much harder to exploit a locked down API like a fixed SOAP endpoint.
Re regular web-services (pre-WCF): only go down that route if you want to support very specific legacy callers.
I know this is old, but I just wanted to add my 2 cents.
I would highly recommend using WCF; and use the WCF Service Library project over the Silverlight-enabled web service. They are both essentially the same, but the Silverlight-enabled web service changes the binding to basic instead of ws*. It also adds an asp.net compatibility mode attribute.
WCF is usually faster: See "A Performance Comparison of Windows Communication Foundation (WCF) with Existing Distributed Communication Technologies" # http://msdn.microsoft.com/en-us/library/bb310550.aspx
WCF encapsulates asmx, wse, msmq, enterprise services, and remoting.
WCF services can be included and run within iis, windows forms, etc.
WCF isn't restricted to using HTTP, but with minimal configuration can also use tcp, named pipes etc.
complex data types are easier to expose and serialize.
WCF just scales really well. Plus, they can be used to incorporate workflows from WF.
There's probably not a wrong technology to use, but it seems as if Microsoft is going to be moving forward with WCF. Plus, it's just so much easier to write one code base that can be exposed so many different ways with just a few configuration changes to the WCF service.
I recommend not using the Silverlight-enabled web service, just because the programming structure is set up a little better with the WCF model, but this is probably a matter of opinion.
If you have to choose between a web service and a WCF service, my advice is to go with WCF. It's more modern and more powerful technology. As for ADO.Net Data Services - you can use that if all you need is to retrieve/commit some data from/to a database back on the server.