2

I work in a small software solutions company (50 employees) and I was recently tasked with experimenting with web services. Since we mainly offer solutions for Windows, I started toying around with Microsoft's WCF 4 (.NET 4.0). Basically, these web services would ultimately be consumed be our clients via the internet. We would also be using them internally via our intranet.

Securing these web services is where I am at a loss right now. I want to use a scheme that would cause the least burden in terms of support/maintenance. Basically, I want to make sure that only clients "certified" by us (e.g. clients who have paid us) can consume our web services.

Federated Authentication using Windows Identity Foundation (WIF) looks pretty neat and I have a few working samples using self-signed certificates and self-hosting services (the web services and the STS). These would be hosted in IIS eventually if I go with the Federated scheme. The way I understand it, the STS would have a certificate issued by a Root CA. The web services as well as the clients would also have certificates issued by the same Root CA. The clients would then be able to consume the web services by certificate authentication via the STS.

Now, my question is:

We don't have a PKI in our company. If we were to have a CA (and all that is needed for a working PKI), would clients outside of our domain be able to use our web services with certificates issued by our CA? This is where it is still muddy for me. How would this work? How would the clients request certificates? Would they be able to add our CA to their trusted CAs? How would they access our CRL? I'm thinking Windows Server 2008 R2 with Active Directory Certificate Services.

Have I gone off-course here? Is there something simpler?

Thank you

BenjiZombie
  • 23
  • 2

2 Answers2

3

You could deploy your own PKI. You primary limitation will be getting all your customers to install your CA Cert as a Trusted Root certificate. That is, getting all of them to trust when you say a server is secure, it is (that's a very broad statement, and most IT depts will object).

Otherwise what you propose would work.

I might suggest looking into using OpenID or Windows Live ID or a similar service to handle authentication. You can just keep track of authorization (which IDs are accepted) and wouldn't need to worry about keeping passwords. Encryption and non-repudiation can easily be handled by basic SSL or TLS and a cheap cert from a public CA. Federation Services works great for tightly partnered companies, but isn't normally used for casual client relationships.

Chris S
  • 77,945
  • 11
  • 124
  • 216
0

PKI is really designed for secure communication across an insecure channel. I don't think PKI would work well for limiting access.

I really don't know anything about WIF, but I would guess that PKI certificates would be more for clients being able to authenticate servers, as is done now in browsers.

shapr
  • 437
  • 7
  • 12
  • PKI is for much more than securing access to communications channels... See http://en.wikipedia.org/wiki/Public_key_infrastructure – Chris S Oct 01 '10 at 18:21