SSL Certs or CardSpace for Client Certificates with WCF

We're currently designing a number of SOA Services that will be built using
WCF.

We'll be having a number of applications (dozens to low hundreds) connecting
to these services and performing actions that must be robustly
authenticated.

We're looking at two options for doing this:
1 - Generate an SSL Certificate per application, register that cert in our
DB of "Acceptable" certs, and use this for tracking what applications are
performing what actions on the system. This is standard, seems to be deeply
supported by WCF, and should suitable for cross-platform use.

2 - We were also toying with the idea of generating CardSpace Identies for
each of the applications that connect, and performing authentication that
way. Cardspace Identies seem to have a few plusses, in that they're easier
to generate and make use of. The people who start to shake when they hear
"SSL Certificate Generation" seem to be able to handle CardSpace stuff.

Is there any broad support for using CardSpace in this way? In essence, I'm
looking for a set of CardSpace configuration tags in WCF, and the ability to
use CardSpace from other platforms.

I'm 85%+ that we'll go with the SSL Solution, but I wanted to get other
people's opinions. I don't really have a solid enough grasp yet of CardSpace
to know if it is the right/wrong tool for the job.

Any advice?

--
Chris Mullins MCSD.Net, MCPD Enterprise
http://www.coversant.net/blogs/cmullins

As it seems to be important to know who is calling your services; I would go
for the certificate solution. Cardspace is still young and you find no
support for this today, apart from rolling your own STS (token service).

Even though, using Certificates you really are in for a large maintenance
task as I suspect that you want to issue a certificate pr. application to
distinguish them?

Is it more important to know the application than the user? If no - why not
use Kerberos to authenticate using the builtin OS support.

--
rgds.
/Claus Konrad


"Chris Mullins" wrote:

> We're currently designing a number of SOA Services that will be built using
> WCF.
>
> We'll be having a number of applications (dozens to low hundreds) connecting
> to these services and performing actions that must be robustly
> authenticated.
>
> We're looking at two options for doing this:
> 1 - Generate an SSL Certificate per application, register that cert in our
> DB of "Acceptable" certs, and use this for tracking what applications are
> performing what actions on the system. This is standard, seems to be deeply
> supported by WCF, and should suitable for cross-platform use.
>
> 2 - We were also toying with the idea of generating CardSpace Identies for
> each of the applications that connect, and performing authentication that
> way. Cardspace Identies seem to have a few plusses, in that they're easier
> to generate and make use of. The people who start to shake when they hear
> "SSL Certificate Generation" seem to be able to handle CardSpace stuff.
>
> Is there any broad support for using CardSpace in this way? In essence, I'm
> looking for a set of CardSpace configuration tags in WCF, and the ability to
> use CardSpace from other platforms.
>
> I'm 85%+ that we'll go with the SSL Solution, but I wanted to get other
> people's opinions. I don't really have a solid enough grasp yet of CardSpace
> to know if it is the right/wrong tool for the job.
>
> Any advice?
>
> --
> Chris Mullins MCSD.Net, MCPD Enterprise
> http://www.coversant.net/blogs/cmullins
>
>
>

"Claus Konrad" <ClausKonrad@discussions.microsoft.com> wrote

> Even though, using Certificates you really are in for a large maintenance
> task as I suspect that you want to issue a certificate pr. application to
> distinguish them?

Yea, it's important to be able to have a cert per application per
environment. This way we can, just from the cert, what the application is,
and if it's staging, test or production.

> Is it more important to know the application than the user? If
> no - why not use Kerberos to authenticate using the builtin
> OS support.

There are a few reasons - some of which are kind of funny.

At the orginization in question, we have very, very little chance of talking
their admins into creating Active Directory accounts per application, much
less per application per environment. This is just something that gets
stonewalled and isn't worth the trouble to fight. Even if they do create the
accounts, they believe - strongly - that passwords must be changed every 30
days. This isn't very practical for Service Accounts, and therefore nobody
is willing to own the problem. I well know how broken this is, and realize
it would be better to solve at the business process layer, but it's just not
gonna happen. Any orginization who put security in charge, gives them
absolute power, and then has them accountable to nobody, deserves what they
get!

It's also difficult for developers to debug applications that run under
different accounts. It's much easier to debug an application that runs as
me, but pulls it's identifying X.509 Certificate from the store. This is
just pragmatic.

--
Chris Mullins, MCSD.NET, MCPD:Enterprise
http://www.coversant.net/blogs/cmullins