A comprehensive SOA security strategy should use a combination of transport-level security (SSL, VPNs, intrusion detection, proxies, etc) and application-level security (WS-Security, WS-Trust, and WS-SecureConversation).
SSL (a transport-level security measure) provides excellent protection of messages while they are in transit, and SSL also provides strong authentication between two network nodes, but SSL's efficacy is sorely compromised when you throw a mediator into the message path. If you depend only on transport-level security, the message data is decrypted and therefore unprotected on the mediator node, and the original sender's credentials are lost when the message is forwarded to the next node in the message path.
You must use application-level security measures to enable end-to-end security. WS-Security (WSS) provides the foundation for application-level security. It allows you to encrypt and/or sign data at the application-level so that only the intended receiver can get access to the data. WSS also conveys security tokens (containing authentication, authorization, attribute, session, or key information) in the SOAP header. It lets the message maintain the original sender's credentials, as well as capture credentials from any number of intermediaries along the path. The WSS specification includes bindings for 4 types of tokens: Username, X.509, SAML, and Kerberos, and it includes a binding for protecting attachments based on the SOAP with Attachments specification. The WSS v1.0 spec was ratified by OASIS in April 2004. The WSS v1.1 spec is being ratified this month (voting will close on Jan 31).
WS-Trust defines a standard Security Token Service (STS). An application can use an STS to obtain the tokens it needs to communicate with a service. The application submits a set of claims, and if they pass muster, the STS issues a token. The STS can also renew, cancel, and validate tokens. The WS-Trust protocol also supports negotion, which allows the STS to demand additional claims before issuing or renewing a token (typically a fresh signature).
WS-SecureConversation (WS-SC) provides the means to establish a secure session between two end-to-end communicating nodes. By setting up the secure session, the two nodes do not need to re-authenticate on each message being exchanged. (Plain vanilla WS-Security supports authentication if individual messages only.) WS-SC defines a new WSS token binding (Security Context Token [SCT]) and a binding for WS-Trust for obtaining and exchanging SCTs.
WS-Trust and WS-SC are in the process of being standardized by the OASIS Web Services Secure Exchange (WS-SX) technical committee.
The part a mediator plays in security gets a lot trickier when you add application-level security to the mix. At a minimum, the mediator must be able to process WS-Security headers, use it for authentication, and also add its own authentication information to the message. It should also be able to participate in a three-way secure conversation if the nodes are communicating using WS-SC.
Most ESBs have pretty limited capabilities in terms of security. Typically they include a built-in WS-Security provider with support for XML encryption and XML signatures, as well as Username and X.509 tokens. The exception is Sonic, which plans to add support for WS-Security in its imminent next release. ESBs typically don't support SAML or Kerberos, and they don't support WS-Trust or WS-SC. (I recommend using SAML because it lets you abstract away a lot of very complex PKI stuff.)
If you have reached the stage where you are using WSS, my advice is to use a mediation system that has much more robust application-level securitycapabilities, such as an XML gateway (DataPower, Forum, Layer 7, or Reactivity), a web services management (WSM) system (Actional, AmberPoint, or SOA Software), or a secure mediation fabric (Blue Titan, which is a cross between an ESB and WSM). All of these mediation systems support authentication and authorization processing, credential mapping, message scanning, intrusion detection, message validation, and similar security features. They can all also perform ESB-type functionality such as routing, load balancing, and transformations. Some can also handle protocol transformations. DataPower and Reactivity both support legacy application integration. Blue Titan also supports reliable messaging.
(Perhaps now you understand why I don't view ESBs as the center of a SOA effort. There are plenty of other mediation systems to choose from.)
Anne
On 1/17/06, Gervas Douglas <[EMAIL PROTECTED]> wrote:
<<The ESB has the responsibility to preserve the transport layer
security of an incoming message. It follows that in cases where the
threats to the ESB are from unauthorized access only, it may mean that
the ESB does not do any additional security processing on an incoming
request. In other cases the ESB may offer a mediation which validates
that the transport protocol underneath the request is part of a trust
relationship. Included in this level of mediation are "typical"
transport layer security techniques such as virtual private networks
(VPNs) and (mutually authenticated) SSL used to validate the trust
relationship between invoker and service. The ESB, as a trusted
component within a service-oriented architecture, then must be able to
provide transport layer security, and establish a trust relationship,
between the origin of the request and the ESB entry point for services.
Allowing the ESB node to mediate transport level security and trust
relationships establishes the ESB as a component in the security
model. The ESB then supplies a service, that brokers or mediates
security for all the services on the bus, removing the need for each
service to independently manage and evaluate trust relationships with
every possible service invoker.>>
You can read this at:
http://www.ebizq.net/hot_topics/soa/features/6554.html
How useful a security role does the ESB you sell or use play??
Gervas
Yahoo! Groups Links
<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/service-orientated-architecture/
<*> To unsubscribe from this group, send an email to:
[EMAIL PROTECTED]
<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
SPONSORED LINKS
| Service-oriented architecture | Computer monitoring software | Free computer monitoring software |
YAHOO! GROUPS LINKS
- Visit your group "service-orientated-architecture" on the web.
- To unsubscribe from this group, send an email to:
[EMAIL PROTECTED]
- Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
