While it is (technically) easy to CardSpace enable a web application or service, there are some implications regarding certificates and keys you should be aware of. Let’s focus here on the web application scenario as I think this is what most people will try mostly these days. But first some background…

CardSpace only works over SSL – that means the page that triggers the identity selector UI must use HTTPS (which is a good thing). This has two reasons – first the identity selector wants to give the user information about the relying party (information from the SSL certificate as well as the issuer). But in addition to simply sending the token in clear text over SSL transport protection, CardSpace also encrypts the token using the SSL public key found in the certificate.

Now when you want to decrypt the token in the web application, you need access to the SSL private key. This causes some problems and when you search the usual forums you will find a lot of questions around that. Mostly centered around an error message saying “Keyset not found” you will most likely get when using the TokenProcessor that comes with the SDK. This error message means that the application account doesn’t have read access to the private key. Now to get this working I wrote a tool some time ago that allows you to easily change ACLs on key containers (Vista has this functionality built in) – but back up for a second – and think about what you are doing here…

Web applications are the primary targets of attacks and since these key requirements for CardSpace are well known there will be a new class of attacks against such applications directly aimed at stealing your SSL private key. So whenever you application (or IIS itself) has a code defect that allows to disclose files on the file system (e.g. directory traversal) your private key lives in a very risky environment. This would allow an attacker to spoof your web site identity using the correct certificate/key combination – and this, of course, is something very dangerous.

So what’s the recommended way of dealing with such a situation? I think you should never grant your application account direct access to the SSL private key – a better approach would be to factor out the decryption code into a separate secured process that runs under a different account (and only this account should be able to read the private key). Your web app and this process would talk to each other using a locked down communication channel (e.g. using WCF or Enterprise Services).

This is not hard to do – but is of course more work than simply setting an ACL. Now one of the goals of CardSpace is to get rid of the myriad of passwords we have to deal with, also for non high-security applications like forums. I have my doubts that these types of applications will a) enable SSL and b) take the burden of getting such a server side infrastructure in place. And if you are running on a shared host with no access besides to your web directory this is impossible.

Now while at shared hosting – most standard hosting offers don’t give you a separate application pool which means you have to share the process with other customers. In this case there is no way of granting you access to your SSL key in a secure fashion. This of course is also closely related to the fact that the token decryption code has some dependencies on WCF which forces you to run in full trust – and this does not only mean that you are fully trusted – but that you fully trust everyone you are sharing the server with.

I think it would be useful to have an option in CardSpace (for self issued cards) to send the token in clear text over SSL – this would remove the risk of needing access to the private key. This should be of course not the default and opt-in. But I think this would solve some security problems in the end (even if it looks more insecure at first – but making these trade offs is one of the most fascinating aspects of security IMHO).