Looking Ahead: Identity Delegation
Complex business processes that are found in SOAs need the ability to delegate identities. Delegation is essential when a party needs to vouch for another party - for example, when a corporate buyer makes a purchase on behalf of his company. In this case, his company should vouch for him. This means that instead of using the employee's private key for cryptographic operations, the company's private key is used. Typically our fictional corporate buyer invokes a local procurement application (such as the one we used in our portal example), fills out a purchase order, and prompts the application to send the purchase order. The application uses the original user's credentials as is or maps them to another identity format such as a SAML assertion that will be inserted into the WS-Security header. The application certifies the request by providing its own cryptographic key (for example, the company's private key or shared secret), which is where the delegation takes place. The application posts the purchase request to a purchasing Web Service at the provider's site. The Web Service then authenticates and authorizes the request based on the information in the SAML assertion (see Figure 7).

Some scenarios like this have been implemented. However, part of the solution relies on standards - HTTP, SOAP, WS-Security, SAML, and possibly additional Web Service specifications such as WS-Trust if security token brokering is involved - and part of it consists of proprietary extensions to implement identity propagation and delegation. For example, there's currently no standard way to express delegation. Existing standards such as SAML assume that the owner of a security token is fully responsible for the security process. As a result, delegation should be designed into the SAML standard. Likewise, other than SOAP, there's no standard way to bind a SAML assertion to other prevalent SOA protocols. Standards bodies must work to profile SAML token usage for various SOA protocols and transports.

Conclusion
SOAs are full of complex business processes, often traversing multiple services and protocols. One of the challenges in this environment is to propagate identities across these services. In fact it's a necessity in today's age of compliance. Companies must be able to prove who has access to their services. Also, to have truly secure and auditable business processes in SOAs, you need a way to propagate identities. If a transaction spans multiple services, an identity must be bound to a payload and be able to span the service calls from beginning to end.

Currently, there isn't an open standard that completely addresses this issue. We hope the next version of SAML will do so. SAML needs to have robust delegation capabilities and binding profiles added to its resume. Once these are added, IT organizations will have the tools they need to enable identity propagation throughout their SOA business processes.