I have a wcf service hosted in IIS. Currently this service is required to be accessed by only one internet facing application (Client A). Both client and server has proper production certificates installed. I have a feeling that I can use them identify each other as that's one of the purpose of certifcates but I am so confused with so many flair of configuration options available in WCF. What is the best and concise way of achieving it. A lot of solution seems to either rely on username/password way regardless of where the client appiication is or either just identify client by using
<message clientCredentialType="Certificate" />
However I am using clientCerdentialType = "UserName" in order to use username/password scheme of authentication and authorisation.
I looked at the similar question at How to configure a WCF service to only accept a single client identified by a x509 certificate but no luck.
Related
I have a problem with a service I am writing.
We currently have a webapp that is hosted on an internal secure network.
There is now a requirement to provide a service which expose our web app business functionality for a client to consume in order to create a native tablet app.
The mobile device will use VPN to get onto the network. To access our webapp, the user would normally need to use a user name and password. ie. There is no SSL. The username and password is stored in our db in custom set up (no ASP membership, etc).
Now, I have raised the lack of SSL as an issue, but this has been shot down, and those in charge of such matters feel that the security needed to get into the internal network is enough.
I realise this means app is open to INTERNAL user malicious behaviour from those inside network but outside of app user group
SO, this now raises an issue when it comes to creating my service in WCF. Authentication without SSL appears to be quite fiddly. I did manage to find:
[Yaron Naveh's ClearUsernameBinding][1]
http://webservices20.blogspot.co.uk/2008/11/introducing-wcf-clearusernamebinding.html
I felt that this was about to solve all my problems until I realised that I would have to alter my plans to offer RESTful service with json, and I would now have to use SOAP.
Still, I was fine with this until I realised that SOAP had bandwidth issues due to the envelope that comes with the packet. This worries me, as it is a service which will be getting consumed by a mobile app over 3g, and there are bandwidth limits.
So, without SSL being an option (please don't say otherwise), do you think that using SOAP instead of REST here is the better option? Should I be concerned about the bandwidth? (rows counts returned will not be exceeding 200, and most will be MUCH smaller). Roughly how much of an overhead are we talking?
Is there an option with wcf REST config where I can authenticate without a certificate (using some form of custom authentication)? This would be preferable to me.
The performance comparison between REST and SOAP web services was discussed in detail in Rest vs. Soap. Has REST a better performance?.
You can certainly implement custom authentication in a WCF REST service, without certificates or a secure transport. One option is to use a binding similar to the following:
<bindings>
<webHttpBinding>
<binding name="default">
<security mode="TransportCredentialOnly">
<transport clientCredentialType="Windows" proxyCredentialType="Windows"/>
</security>
</binding>
</webHttpBinding>
</bindings>
http://msdn.microsoft.com/en-us/library/bb924478(v=vs.110).aspx
Including the Microsoft caveat: “This mode does not provide message integrity and confidentiality. It provides HTTP-based client authentication. This mode should be used with caution. It should be used in environments where the transport security is being provided by other means (such as IPSec) and only client authentication is provided by the WCF infrastructure.”
The following link provide comprehensive overview of a custom WCF REST authentication solution:
http://www.codeproject.com/Articles/304877/WCF-REST-4-0-Authorization-with-Form-Based-Authent
The WSDL envelope is not in megabytes range. It needs a few kilobytes per request for normal configurations. Therefore, the possible bandwidth bottleneck depends heavily on the requests/time ratio.
You could always implement a custom authentication mechanism with tokens. The basic idea would be this...
When the user authenticates, he gets a token which expires after 20 minutes or so, if the user does not act in that time
The token is stored (encrypted) in a client side cookie
The cookie is used in each client's http request
The REST service examines the user's cookie, extracts the token and concludes if the user is authenticated or not
I would strongly suggest to follow the Membership API path. The logic that I describe is the one used by the Membership API. Implementing it on your own, would just be time overhead and a bug generator. I don't see why you have to reinvent the wheel...
Hope I helped!
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'm very new to web services (please note, not WCF but the old fashioned .asmx files).
Now I may be liking this too much to ports, but if I expose a port on my web facing server then it is exposed to attacks as well as my own use; There are tools which can scan to see what ports are open.
Is this true of a web service? Now, don't get me wrong, I know each service should be coded well enough that nothing malicious can happen or that the calling class doesn't know the 'contract' to implement them, but that's not the question (and I guess port flooding could still occur?); If I put up a few web services on a server, is there a tool/program which can detect them (by name)?
Yes, a web service is basically a web page that takes arguments and response with a formatted result that can be read more easily by a program (technically both are a result of a http request and response - there are other mechanisms as well, but the typical one is over the http protocol).
If you type the link to your web service in a browser you will see you are presented with an interface that allows you to "execute" its services.
Therefor you need the same security as with a web page, meaning login or check of credentials, tokens, signing, encryption and so forth (preferably on a ssl-connection).
I have Android app that talks to .net 2 webservice (IIS7) using http get and managed to make it run on https using self-signed server certificate (but not requiring client certificate).
I see all http traffic is encrypted and it looks secure.
Now what options would I have on how to authenticate client? For example, I like to block webservice access from internet explorer on PC.
Client-authenticated TLS handshake described here would be a way to go?
Then how can I accomplish that? Some advice or example will be appreciated.
Well, given that each user should authenticate anyhow, you probably want to setup some sort of per-user authentication strategy for a variety of reasons. First, given this might be a widely distributed app, having a single "gold master" authentication certificate or credentials will ultimately fail as someone will hack it -- either grabbing the cert or grabbing the account. And then what do you do? Second, its not particularly hard to handle. You can easily use ASP.NET membership to back it, and then take the credentials a number of ways depending on the nature of the service. Third, it is alot easier to manage than client certificates.
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.