I have an application which is structured as:
Web Application - WCF Service - Database
All communicate to and from the database goes through the WCF Service, the Web Application is not able to directly talk to the database. I needed to protect the data as it travels across, so i setup SSL on my local machine to test and configured it in IIS, so now the WCF Service has to be hit using HTTPS. However, I did not setup my Web Application to use HTTPS, is that ok? I thought since the WCF Service is doing all the transferring of data, it's the only one that needs HTTPS.
Thanks.
If you're interested in encrypting your data, you need to make sure it's passed encrypted on all tiers of your application. From your description it seems that the data passed from the user to the WebApplication itself is unencrypted and therefor passed in clear text. This means that anyone that "listens" to the traffic between your users and the Web Application can intercept the data.
I recommend adding SSL on the Web Application too, to make sure that your data passes encrypted through all 3 tiers of your application.
Related
We have built a WCF service for an application and everything is working out well, using WSHttpBinding. We now have been asked to make sure the communication between the Web Application -> WCF -> Database is secure and have been asked to use SSL. Along with that they are requesting we make sure the WCF service can not be accessed by another application.
If we setup SSL, does that block others from trying to get in, or we do still need to setup the clientCredentialType setting on the service? Also the entire application (site, wcf, db) will be within a company's network, so if we setup the clientCredentialType="Windows" which account is used, how does WCF know to allow the website to talk to it, which Windows account are they using, or this an account we need to setup?
Thanks.
SSL has nothing to do with Authentication or Authorization.
It does 2 things:
prevents third parties from intercepting your traffic.
verifies that people are who they say they are.
The requirement "make sure the WCF service can not be accessed by another application" needs to be handled through some Authentication / Authorization mechanism. You could use Basic or Windows depending on your needs.
Since you're in the company's network, I'd attempt to use Windows Authentication. This will force clients to be authenticated through your domain, however it looks like you don't want just any domain user to have access. In this case, you need to set up either Role based authorization, or user based. Either war, you can drop a Web.config file into the same folder as the WCF service endpoint specifying what accounts are authorized. Other users will see a 401 Unauthorized.
This is the general approach I'd take.
I have a public desktop site, a public mobile site, and a private intranet site on the same server. They are all written in C# (ASP.Net 4.0).
Each has their own code to process credit card payments. I would like to write a single application that handles credit card payments for all 3 sites. I want this application to only be accessible from these 3 local applications.
The only way I know how to do this is to create a web service and restrict traffic to the localhost.
Is there a better ("right") way to do this? Should I create a windows service instead?
The general approach is sound. However, I would not only rely on access being restricted to localhost. A single misconfiguration at some later point in time would expose your payment web service. Also, if the server is compromised, any process running on that local host would have unchecked access.
Always use authentication to secure your payment web service.
If you must deploy the authentication service on the same physical box as the front end websites, take particular care securing the payment service (e.g. if you are storing credit card numbers or PII related to the credit accounts e.g. name, address, ... ensure the database is correctly secured). If at all possible, place payment services in an additional layer separate from the public-facing (or co-worker facing) websites, protected by appropriate firewall rules.
I don't think windows service would be good option if you have calling applications. As far as I know about WCF, we have option for NetTcpBinding and NetNamedPipeBinding which you might consider.
NetTcpBinding - A secure and optimized binding suitable for cross-machine communication between WCF applications.
NetNamedPipeBinding - A secure, reliable, optimized binding that is suitable for on-machine communication between WCF applications.
i'd like to recieve comments on the way i'm trying to build an asp.net web application which uses a WCF service that is hosted in another asp.net application. Both applications will live on the same machine, but the app with the WCF service will not be accessible from the outside. there will be two web servers sharing the load behind a load balancer.
The app pool of both applications will use the same local user account (web server is not part of a domain) and so i was thinking to use WsHttpBinding with windows security for communication between client and internal wcf service.
The fron-end asp.net app uses forms authentication through a custom membership/role provider to athenticate and authorize users. The user database is in a sql server database.
i need to somehow pass to the wcf service the user details (username + roles) so that in the wcf it will be possible to validate and authorize according to the roles of who is logged in the front-end. I read i need to use "support tokens", but i haven't figured out how to use this.
I read also something about claims and WIF, which seems interesting but have no idea how i could use these in my scenario.
is there anyone who can give me recommendations about the architecture and maybe also show me how to pass the username to the wcf service and also show me if possible to use claims based authorization?
First of all, if both servers are behind the corporate firewall on a corporate LAN, I would strongly suggest using netTcpBinding instead of any http based binding. NetTcpBinding is much faster due to encoding the message in a binary format.
As for username / password: your ASP.NET front-end server could set the client credentials for the user calling for the WCF service - after all, the ASP.NET servers do have access to the ASP.NET membership database, don't they?
Or if you cannot pass on the user's credentials, you could pass on some headers to your WCF service that would describe the user - actually, you probably only ever need the user's unique ID - since the WCF service could fish out the rest of the info from the ASP.NET user database again, if really needed.
As for claims - I don't think they'd be a good idea here - you don't really have to deal with a multitude of different authorization schemes, and you're not using any federation (e.g. allowing users from a different company or domain to use your services) - so those obvious benefits probably won't really be applicable to your case.
I am getting my head around n-tier applications. I understand seperation of code layers eg/UI, BL (Business Logic), DL(Data Layer).
In a ASP.Net application you would just reference the C# project that is doing the BL and the DL and all is well.
What I don't understand is how you would implement this on seperate servers? Do you have the DLL for the BL and DL in the bin folder but a setting in the web.config file which tells it where to go for communication or do you have the actual BL and DL running on a seperate server and then communication from the UI is made via a web service?
At the moment I have a standard ASP.Net webforms app that needs to seperate the security side to the web server and the main app on a application server, however I dont think thats possible.
When we spit in to physical Tiers we use WCF between the tiers. You actualy end up getting many more layers in your application, so do not use it if you do not need it.
Typical layers would by
Client Tier
UI
Business
proxy
Server Tier
Facade
Business
Data access
Server Tier can be implemented as a single Layer if you use an ORM.
This isn't directly possible without clustering, and even that requires exact copies of the application running on both servers.
If you want to run your security layer as a separate server, create it using web services, and make a web request to that service, and return the (encrypted or otherwise) response.
Hope that helps.
EDIT for continued Explanation:
In your case, I would have my security application running on a server that will authenticate, encrypt, and respond to requests made to it from a specific url or domain/sub-domain. Then my main application can live on another server and the requests to authenticate etc can be on a secondary server. However, ASP.NET authentication uses the machine-level key to create a unique salt for the authentication token. So in order to share auth tokens between multiple machines, your machine keys must be identical in the machine.config.
Separate servers would entail the usage of some form of web services. Here at work:
Server (piglet) - database, sql server 2005, firewall prevents connections to tigger
Server (eeyore) - web services - connects to piglet
Server (tigger) - asp.net server - connects to eeyore, firewall prevents connections to piglet
The business logic would be in a dll assembly used by the data access layer, the presentation layer, or both, and is deployed alongside them.
If you want the layers on physically separate servers, then you have to decide how the layers should communicate. You have lots of options for doing this: web services, Windows Communication Foundation, .Net Remoting...
Application Server - Instead of calling the security logic directly, call a security webservice on the web server.
Web Server - Hosts the security webservice. The webservice here does the actual business logic and can call the data layer.
Scenario
I have an HTML/javascript website that uses javascriptSOAPClient communicate with an ASP.NET 1.1 web service in order to read/write to a SQL database. (http://www.codeproject.com/KB/ajax/JavaScriptSOAPClient.aspx). The database contains anonymous demographic information--no names, no credit cards, no addresses. Essentially the data collected is for data mining purposes.
The site is live, but we want to introduce a more secure communication between the javascript/ajax client and the wbe service for both this and future projects. Working as contractors in the financial industry, at some point we're going to get nailed with the question: is this website hackable? If we don't have a solution we could be out on our ears.
I am already following best practices such as communicating with the database via command parameters and stored procedures). However, currently anyone could browse to our web service description and figure out how to consume our exposed services.
Questions
With my hybrid solution (i.e. not end-to-end Microsoft) how should I go about authenticating client requests on the web service?
If I start passing a username/password or some other identifiable element into the web service as authentication, should I be concerned about how that key is generated/stored on the client side?
A few suggestions to consider:
List the threats, and compare each to your current setup.
Use SSL / HTTPS. This alleviates a whole class of vulnerabilities.
Use username/password, generated on the server side and sent out of band (in the post or by phone) to the user. (Hope this answers question 2).
Use 2-factor authentication. To do this, you can look at security tokens such as RSA's keyfob-type gizmos or look at Steve Gibson's Perfect Paper Passwords
The easiest solution from a programming standpoint is to use two way HTTPS. That is, the server presents a certificate to the client, and the client presents a certificate to the server. Then only clients with proper certs (issued by you) can connect.
That helps reassure clients that your site is not generally accessible, yet the security is transparent to the application and, once they've signed up and received a cert, to them. The downside is that you have admin overhead in issuing and tracking the user certs -- but that's probably less than you'd have dealing with username/password combos.
There are a few simple options:
SSL + Cookie
If the web app is also ASP.NET and hosted along with your web service, then you should have access to the User/Membership/Session of the web app inside your web service (essentially #1, but you get it without doing any work).
If the web app and web service are not on the same domain, then cookies are out due to cross-domain issues - so you can have the web app embed a GUID into a hidden form field, and use that GUID as a sort of cookie (and it will need to be passed as a parameter on all web service requests).
Can you incorporate a certificate authentication mechanism? So that only clients that have keys you can verify can communicate? That's how the product I work with has its managed devices communicate back to the core.