Via Richard Turner's blog, the announcement of an architecturally superior token decryption component devised by Dominick Baier at leastprivilege.com.
Dominick and Richard have blogged previously about mitigating the dangers involved in allowing web middleware and front-end software to process encrypted payloads. Decrypting a payload involves access to a private key. The broader the range of applications that can get to the key, the greater the attack surface. This led to discussions about:
- Re-factoring the token decryption code into an assembly that runs under full trust whilst the site runs under partial trust
- Building a Token Decryption Service to which you can pass your encrypted blob and you get back a list of claims, PPID and issuer key.
And that is exactly the problem Dominick has tackled:
Web Applications that want to decrypt CardSpace tokens need read access to the SSL private key. But you would increase your attack surface tremendously if you directly grant this access to the worker process account of your application. I wrote about this in more detail here and Richard Turner followed up here.
Together with my colleagues at Thinktecture (thanks Christian and Buddhike for code reviewing and QA) I wrote an out-of-proc token decryption service that allows decrypting tokens without having to have direct access to the private key in the application, the idea is as follows:
Your web application runs under its normal least privilege account with no read access to the private key. The token decryption service runs as an NT service on the same machine under an account that has read access. Whenever the application has to decrypt a token, it hands the encrypted token to the token decryption service which (in this version) simply uses the TokenProcessor to return a list of claims, a unique ID and the issuer key.
The token decryption service is implemented as a WCF service that uses named pipes to communicate with the applications. To make sure that only authorized applications can call into the service, the application(s) have to be member of a special Windows group called “TokenDecryptionUsers” (can be changed in configuration to support multiple decryption services on the same machine). I also wrote a shim for the WCF client proxy that allows using this service from partially trusted web applications.
The download contains binaries, installation instructions and the full source code. I hope this helps CardSpace adopters to improve the security of their applications and servers. If you have any comments or questions â€“ feel free to contact me.
The approach is a good example of the “alligators and snakes” approach I discussed here recently.
One thought on “Token Decryption Service for CardSpace”
Comments are closed.