How can I secure an webservice so my clients can use it on their applications without having to fear that their api keys will be used in other applications?
views:
45answers:
1
A:
Assuming that:
- you're using WCF to implement your services
- You are writing some webservices for your client, so they will host the webservices.
Take a look at the WCF Security Guidance from P&P group: http://wcfsecurity.codeplex.com/
It helped us a lot in defining our security strategy, based on our requirements.
In summary you need to understand how your webservices will be used, what your users will be authenticated and authorized, and based on this, implement the required configuration/code changes.
I hope this helps.
Wagner.
Wagner Silveira
2010-03-24 20:14:16
I'm using WCF but they won't host the webservices, everything is hosted in my servers. They just consume it.The problem I'm trying to handle here is someone disassembling their application, retrieving their API key and using it.
Pai Gaudêncio
2010-03-24 20:37:18
By API key you mean some kind of authentication token, right? In my case, what I did was to use certificates, during authorization I matched the key to the thumbprint of the certificate being passed during the authorization process. If they didn't match, I would refuse the call.
Wagner Silveira
2010-03-24 21:21:37
Yes, the api key is some sort of auth. But the problem is that it's easy for people to disassemble the application, get the auth token (api key, cert., whatever) and start using the services without permission (using my clients key). That's what I'm trying to prevent.
Pai Gaudêncio
2010-03-24 21:29:35
What I had in my application was an API key on the configuration, and a certificate on their personal store. My server had a registration process which associated the API key to the certificate. I then used the certificate thumbprint and the API key in order to authorize them. The certificate could be revoked if a breach is noticed. If you want to go further than that you might need to match your API key to some sort of machine key, which traps the application to a single machine. If it is used in a different machine then you refuse the connection.
Wagner Silveira
2010-03-25 00:28:52
Youre missing the point. LEts take youre case for example, what would happen if i extracted the certificate/key from your clients app and used it from my app? Thats what im worried about, people getting the keys from the app and using it...
Pai Gaudêncio
2010-03-25 01:29:05
I think you're missing mine... ;-) The certificate is not part of the application. The certificate is loaded from a Certificate Store when the application requires it. This and, in our case an unique identifier, is used to authorize. But if you need to guarantee that you key doesn't reside in the application, you might need to generate it on the fly based in something like user name/password, for example, use the same logic on the other side to derive the key and compare. So instead of having it stored, you will generate the authentication token based on some kind of algorithm.
Wagner Silveira
2010-03-25 02:19:51
Yeah, sorry, I misread the part about the cert store.. You have a good auth scheme, but what if the users of this application knows nothing about the key/password/cert needed for this webservice?As I said in the question, I'm trying to secure a webservice for my clients to use on their applications. They will release these apps to their clients and there resides the problem.They cant ask for their customers to input this info because the clients don't need to know this. Hence the need to embed the info (key, cert, login/pwd) on the application.
Pai Gaudêncio
2010-03-25 03:00:06
Actually, our application was also for a third party to distribute to their clients. Our way to circumvent this kind of problem was to provide them with a snippet of code that allowed certificates to be installed on the certificate store. So as part of their installation process, they would provide the application, the required configuration and the certificate, and the installer would take care of business. Of course this took them some time to digest and some iterations with us in order to get it right, but was a pretty solid solution in the end.
Wagner Silveira
2010-03-25 20:01:01