Kim Cameron has been en fuego recently on one of my favorite topics - how to propagate security tokens in a distributed system? Wrong headed impersonation:
I’m going to make a categorical statement. No one and no service should ever act in a peron’s identity or employ their credentials when they’re not present. Ever.
How would this work in Cardspace, Kim continues
CardSpace is built on this principle. A delegated authority coupon is just a set of claims. CardSpace facilitates the exchange of any claims you want - including delegation claims. So using CardSpace, someone can build a system allowing users to delegate authority to a service which can then operate - as itself - presenting delegation tokens whenever appropriate.
This is, of course, one of the major advantages to WS-Security and WS-Trust approach instead of bundling everything into a single context. Kim also expands on this issue of separation:
CardSpace is built on top of WS-Trust, though it also supports simple HTTP posts.
One of the main advantages of WS-Trust is that it allows multiple security tokens to be stapled together and exchanged for other tokens.
There are use cases where impersonation, delegation, federation, and other approaches are valid, the question is which framework gives you the best flexibility to handle a wide variety of these use cases? (note - the best overview of apporaches I have seen in open literature is Security Design Patterns)
One of the best areas to look for guidance is widely distributed systems that are in production with a good security track record. Rest people frequently point to SSL, which is fine for point to point confidentiality, but we also know Rest struggles to deal with authentication at all, much less stapling together mutiple claims. So a better example for 2007 is QMail. One of the things that makes QMail's security model more robust is that there is a "clear separation between addresses, files, and programs." In web services I tend to look at this as separating identity, service, message, transactional and deployment concerns. The thing that WS-Security and WS-Trust give you is the ability to build this separation into your apps and messages instead of conflating everything into one token or request. A checkpoint process in QMail should not be dependent on the exact same security model for the request and the content, the security checks that QMail performs against the address are not subject to the same concerns as the checks against the body. This also reflects a design goal of QMail which separates functions into mutually untrusting programs. In Web services world, we may have a XML Security gateway perform some functions such as auditing, and service authentication, but process confidential data farther on down the line. So Cardspace, WS-Security, and WS-Trust all help to build such an architecture.
Comments