This article can also be found in the Premium Editorial Download "Information Security magazine: CISO survival guide: 18 of the best security tips."
Download it now to read this article plus other related content.
|SOA: Built on Standards|
WS-Security, SAML put Web services in the fast lane on the Information Highway.
Because SOA is not predicated on a single technical development platform, the security services the architecture requires, such as authentication and authorization, must be provided not through a single security solution, but rather through interoperable security standards, such as WS-Security and SAML. Since SOA spans business, geographic and technical boundaries, the security services that protect identity, data and applications require interoperable standards, such as XML Encryption and XML Signature, that can make security assertions no matter the development platform used by either the service provider or requester. (See figure, right). The most important of these standards include:
WS-Security 1.1, which describes how to attach security tokens (such as Kerberos tickets and X.509) to messages.
WS-Trust 1.3, which extends WS-Security, describing how to move security tokens around in integrated systems.
WS-SecureConversation 1.3, which shows how to optimize performance in message security by creating security contexts and a more efficient channel.
WS-SecurityPolicy 1.1, a specification for describing a policy for a server's security requirements.
SAML 2.0, an XML-based security assertions markup language for making and evaluating authentication, authorization and attribute assertions.
All of these standards may be applied at the message level, the XML document, enabling end-to-end security models, not point-to-point security models. For example, if SSL is terminated at the edge of the corporate network, an unencrypted XML document and the confidential data it describes is then in the clear. But requiring security, such as encryption, to the XML document builds assurance into the security infrastructure as a whole, so there's no need to audit every endpoint between Bangalore and Tokyo every day. Likewise the XML signature allows for authentication and integrity at the message level.
Additionally, security services can be applied at a more granular level; think of an airport security model, which includes fundamentally different risk and policy concerns for baggage scanning, tower-to-plane communications, physical checkpoints and passport checking. Historically, IT security architectures for Web applications rely on technologies like SSL and username/password, all-or-nothing security implementations that do not scale to distributed endpoints with different security concerns. The SOA goal of reuse means the service provider cannot always predict how the service requester will use the data it provides. The goal of virtualization means that the endpoint address and location may change-- the claims processing site in Tokyo goes down, and calls are rerouted to Bangalore.
The standards landscape is rapidly evolving. One of the chief value-adds IT security can bring to the table in SOA is to understand the maturity, role and utility of the key SOA security architecture standards and implementations so the enterprise can take full advantage.
Setting the architectural direction for standards in your organization is key to success. The standards should be published in the service registry, ideally as part of prescriptive security architecture that can be used in the software development lifecycle. The IT security team should collaborate with the software developers to define what level of security is appropriate for a given application. Finally, the IT security strategy should identify key standards it wants to deploy, in a security as a service model, and look to the marketplace for tools that allow for cost–effective, wide-scale deployment of the key enabling standards.
This was first published in July 2007