William Bathurst

Subscribe to William Bathurst: eMailAlertsEmail Alerts
Get William Bathurst: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn

Related Topics: Java EE Journal, SOA & WOA Magazine

J2EE Journal: Article

Identity Propagation in a SOA

The shortcomings of current solutions

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.

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.

More Stories By Marc Chanliau

Marc Chanliau has been in the software industry for more than 20 years and is currently a director of product management at Oracle where he is responsible for Identity Management solutions and innovations. He is heavily involved in security and XML standards groups including serving as the first chair person of the OASIS Security Services Technical Committee (SSTC), which culminated in the adoption of SAML as an official OASIS standard, participating on the WS-Security Technical Committee, helping to define the Liberty Alliance 2.0 specifications, and participating in the Java Specification Request (JSR) committee.

More Stories By William Bathurst

William Bathurst is a senior product manager at Oracle with 18 years of industry experience. He is currently the product manager for J2EE security and web services management.

More Stories By Ramana Turlapati

Ramana Turlapati is a consulting member of the technical staff at Oracle with 12 years of industry experience. In his current role as the security architect for Oracle Web Services Manager, he contributes to Oracle's overall Web Services security strategies and solutions.

Comments (0)

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.