SOA Security: One Treacherous Journey
Web services have always been sold as a way to share data among organizations: An enterprise can selectively open internal systems to customers, partners, and suppliers, automating transactions that once required human intervention. While most businesses have so far steered clear, keeping Web services tucked safely behind the firewall, the growth of service-oriented architecture and the emergence of Web 2.0 look set to change that.
Will the rewards be worth the risks of exposing internal services to the Web? It s not helping that interoperability woes are exacerbated by the immaturity of SOA security standards. To lock down a large Web services network involving multiple enterprises, everyone must agree on technologies, even security policies: There s no use demanding that your employees use biometrics and physical tokens if a partner s staff accesses the system with weak passwords.
Before buying the elements of SOA security, do your homework, because the market is in flux. On balance, the movement we re seeing is good news for IT because it means more choices and potentially fewer vendors to deal with. But it also makes buying decisions a lot more complex.
For example, Web services exposed to the Internet need XML firewalls, also known as SOA security gateways. However, this product category is disappearing thanks to ongoing SOA consolidation.
Meanwhile, with XML firewall functionality rolled into everything from management platforms to core switches, what kind of product to use--even basic decisions such as whether to use hardware or software--will depend on the scale and predicted growth of each enterprise s Web services, as well as any existing SOA infrastructure. Virtualization adds yet another twist.
Decisions around encryption and authentication are harder, as they don t depend on a single organization. Everyone in a Web services extranet needs to be using the same technologies, and right now, there are several competing standards.
The biggest conflict is over identity management, the complex exercise of ensuring that a user or process logged on to one company s systems is authorized to use those of a partner. Two incompatible standards have emerged here, offering much the same functionality. The first, SAML (Security Assertion Markup Language), is supported by almost everyone--except Microsoft. Redmond prefers the newer WS-Federation, which is more tightly bound to other Web services standards. Although both use XML, the two are incompatible, meaning enterprises with public Web services must either support both or ensure that all their business partners using secure Web services choose the same standard.
Got that crystal ball handy?
All Web services security technologies are based on XML Encryption and XML Signature, W3C standards for embedding encrypted data and digital signatures within XML documents or messages. Because XML Encryption doesn t necessarily encrypt an entire message, it allows IT to be selective: Private data such as Social Security or credit card numbers can be encrypted, while less-sensitive elements and SOA meta-data are sent in the clear. Different parts of a document can also be encrypted using different keys, making them readable only by intended recipients.
The downside: Scattering encrypted data throughout XML messages can cause interoperability problems because participants must agree in advance on issues such as where in a message encrypted data will be placed, which elements will be encrypted, and how keys can be exchanged. To help, Oasis (Organization for the Advancement of Structured Information Standards) created WS-Security, a standard for applying XML Security and XML Encryption in Web services.
(click image for larger view) WS-Security is among the most mature of the WS-* standards, supported by almost all Web services and SOA vendors. Its main weakness is that, like all the WS-* standards, WS-Security requires SOAP--anyone doing business with Web services running REST (Representational State Transfer, a way of describing XML Web services that don t use SOAP) need not apply.
The main argument for using REST rather than SOAP is simplicity, so most REST users stick to SSL. Because REST requires HTTP and tends to be used for point-to-point links, SSL tunnels are often enough. Enterprises that want to apply message-layer security in REST will need to create their own protocols and data formats.
Pulling together every business partner and designing a custom, secure XML format for REST is a difficult sell for most enterprises, so the existence of WS-Security can be a powerful argument for SOAP. However, large Web services providers, including Amazon.com and Google, have successfully developed their own ways of locking down REST, using security tokens that are essentially shared secrets. Despite being proprietary, these are very popular among users: Amazon also offers a SOAP interface with WS-Security, yet has found that its customers prefer REST by a 5-1 margin. Most Amazon users are only accessing the Amazon service, not building an entire SOA, and so don t need SOAP s complexity.
Though WS-Security helps encrypt and sign SOAP messages, it doesn t say anything about AAA (authentication, authorization, and accounting) or security policies. These are handled through other standards, which within the security space are all based on WS-Security (see "WS-* Security Standards: Too Much Of A Good Thing?" informationweek.com/1148/security_sb.htm).
Most of these standards eventually will be supported by all vendors in both the Enterprise Service Bus and Web services management areas, though at present they re too new to have had much impact on users.
The exception is federated identity, where the relatively new WS-Federation and WS-Trust are competing with SAML 2.0, an established standard also published by Oasis. Federated identity aims to enable single sign-on by separating authentication from the resource being accessed (see "Federated Identity And Single Sign-On," informationweek.com/1148/security_ diagram.htm). A user logs on to an identity provider that provides him with a credential that can then be used to access multiple resources. The credential, called an "assertion" in SAML and a "token" in WS-Trust, is similar to a digital certificate; it vouches for the user s identity and adds information, such as how the user is authenticated and when. SAML covers the entire SSO process, while the WS-* stack splits it into two standards: WS-Trust handles initial authentication and issuing of tokens, then WS-Federation covers the use of those tokens to access other resources.
The main practical difference is that SAML uses XML Encryption and XML Signature directly, meaning it can work with REST, whereas WS-Federation requires SOAP. SAML also has a large installed base, though this may not count for much because Microsoft has thrown its weight behind WS-Federation and said it will not support SAML.
Unlike some other standards battles, this isn t simply a case of Microsoft vs. everyone else. Microsoft developed WS-Federation with IBM, which is also a big backer of SAML, and every other vendor in the SAML camp has promised to support WS-Federation if there s a demand for it. In the long term, it s likely that both will be used: WS-Federation in Microsoft and SOAP environments, SAML in REST Web services.
On the public Internet, firewalls were one of the earliest drivers for Web services. Although different organizations have different security policies, almost all need to keep Port 80 open, so vendors and standards bodies gravitated toward text-based protocols that run over HTTP.
And, for the same reason, so did attackers and malware.
As a result, companies publishing Web services to the Internet have traditionally used application security gateways, appliances that can read and understand application-layer documents, filtering out potential attacks. These devices are usually called "XML firewalls," though a good one will understand more than just XML. A Web service using REST may encode some information inside HTTP headers or URLs, while developers of browser-based RIAs often see XML as too bloated, preferring JSON (JavaScript Object Notation) or plain text.
Security gateways are more than firewalls, adding all the functions found in the SOA management suites that handle authentication, authorization, and accounting. When Web services act as an interface to an enterprise SOA, the security gateway often needs to convert between JMS and HTTP, as the majority of SOAs don t use true Web services internally.
Unless connecting to the outside world, the ability to tunnel through firewalls is big negative.
In addition, a gateway can t effectively scan a document without first decrypting it, so most are also responsible for encryption and authentication, whether using SSL, WS-Security, or SAML. The deep-packet inspection and understanding of XML required to recognize attacks also makes security gateways useful for XML transformation and routing, and often better at it than management software, thanks to specialized SSL or XML acceleration hardware.
Most security gateways are still standalone boxes, installed in much the same way as a traditional firewall and sold by specialized vendors (see diagram, below).
Of the initial crop of security gateway vendors, four have now been snapped up: Sarvega by Intel, NetScaler by Citrix, DataPower by IBM, and Reactivity by Cisco Systems. With the exception of Intel, which uses the Sarvega technology to help other vendors build XML software or appliances around standard CPUs rather than custom ASICs, all are still selling gateways. But they re taking the products in different directions.
Citrix s NetScaler appliances combine an XML firewall with application front end, or AFE, functionality, something Cisco plans to do by integrating Reactivity into its Application Control Engine product line. Because AFEs also sit at the network edge and accelerate SSL, this combination makes a lot of sense, both for customers and for AFE vendors wanting to enter new markets. F5 has already announced that it will add an XML firewall, developed in-house, and competitors are likely to follow suit.
The other independent security gateway vendors--Layer 7, Vordel, and Xtradyne--are moving in the opposite direction, toward software and virtualization. Vordel and Xtradyne have always distributed their gateways as software, intended to be installed on dedicated blade servers. They re embracing virtual appliances, with Layer 7 and Vordel already selling versions of their software that run under VMware.
The performance hit of virtualization means that a virtual appliance can t yet match a dedicated server, so Vordel currently aims its virtual version more at testing and integration than production. Layer 7 started as a vendor of custom appliances with dedicated XML and SSL silicon, so it sees virtualization as an entry point to smaller customers that can t yet justify specialized hardware. But while "software-only" may be a budget-minded mantra for now, it s likely that virtual appliances will soon be used in businesses of all sizes.
Virtual machine performance is increasing rapidly, and the flexibility that virtualization brings is particularly useful in SOA. As new services are rolled out and reused, the SOA infrastructure needs to adapt, and virtualization lets hardware quickly be reassigned between roles. But sharing hardware resources requires that other servers be virtualized, and that can introduce security issues. Although few VMware security vulnerabilities have been reported, the complexity of managing multiple VMs may make it more likely that traffic will accidentally bypass a firewall (see our feature on virtualization security in the Aug. 20 issue of Strategic Security).
Because they include so much overlapping functionality, security gateways are merging with Web services management software. DataPower and Reactivity had both entered the management market before they were acquired, and at least one other firewall vendor is planning to do the same. Management vendors have not yet fought back by adding full XML firewalls, mostly because their software is intended to be run throughout a SOA rather than at the edge.
Because of SSL s popularity, SSL acceleration is ubiquitous in security gateways: Even virtual-appliance vendors support hardware with SSL accelerator cards. XML acceleration is much rarer, with only Layer 7, Cisco, and IBM boxes including dedicated XML chips; IBM builds its own, Cisco and Layer 7 rely on Tarari. This is partly because of Intel s use of its Sarvega technology--Layer 7 believes that the hardware market will gradually transition to software--but mostly because there hasn t yet been much demand for application-layer acceleration.
XML acceleration is useful mostly in Web services that transfer relatively long XML documents, such as SOAP or SAML messages. It isn t used much in Web services designed to support browser-based applications, as these transfer relatively little data in each session, perhaps a single XML element or JSON object, wrapped up in TCP/IP and HTTP headers. Because JavaScript and Flash clients don t need to reload an entire page every time a user performs an action, most Web 2.0 applications involve less application-layer traffic than comparable apps built using static XHTML.
Still, rich Internet applications don t let Web servers off easy. While they may reduce XML traffic, RIAs can dramatically increase the number of HTTP connections that a server has to deal with. Instead of waiting for a user to click on a link, most RIAs run in real time, initiating new connections every few seconds. Servers overloaded by this can often benefit from SSL acceleration and other AFE techniques, including load-balancing and HTTP compression.
By Andy Dornan, InformationWeek
URL: www.informationweek.com
Will the rewards be worth the risks of exposing internal services to the Web? It s not helping that interoperability woes are exacerbated by the immaturity of SOA security standards. To lock down a large Web services network involving multiple enterprises, everyone must agree on technologies, even security policies: There s no use demanding that your employees use biometrics and physical tokens if a partner s staff accesses the system with weak passwords.
Before buying the elements of SOA security, do your homework, because the market is in flux. On balance, the movement we re seeing is good news for IT because it means more choices and potentially fewer vendors to deal with. But it also makes buying decisions a lot more complex.
For example, Web services exposed to the Internet need XML firewalls, also known as SOA security gateways. However, this product category is disappearing thanks to ongoing SOA consolidation.
Meanwhile, with XML firewall functionality rolled into everything from management platforms to core switches, what kind of product to use--even basic decisions such as whether to use hardware or software--will depend on the scale and predicted growth of each enterprise s Web services, as well as any existing SOA infrastructure. Virtualization adds yet another twist.
Decisions around encryption and authentication are harder, as they don t depend on a single organization. Everyone in a Web services extranet needs to be using the same technologies, and right now, there are several competing standards.
The biggest conflict is over identity management, the complex exercise of ensuring that a user or process logged on to one company s systems is authorized to use those of a partner. Two incompatible standards have emerged here, offering much the same functionality. The first, SAML (Security Assertion Markup Language), is supported by almost everyone--except Microsoft. Redmond prefers the newer WS-Federation, which is more tightly bound to other Web services standards. Although both use XML, the two are incompatible, meaning enterprises with public Web services must either support both or ensure that all their business partners using secure Web services choose the same standard.
Got that crystal ball handy?
MIXED MESSAGES
All Web services security technologies are based on XML Encryption and XML Signature, W3C standards for embedding encrypted data and digital signatures within XML documents or messages. Because XML Encryption doesn t necessarily encrypt an entire message, it allows IT to be selective: Private data such as Social Security or credit card numbers can be encrypted, while less-sensitive elements and SOA meta-data are sent in the clear. Different parts of a document can also be encrypted using different keys, making them readable only by intended recipients.
The downside: Scattering encrypted data throughout XML messages can cause interoperability problems because participants must agree in advance on issues such as where in a message encrypted data will be placed, which elements will be encrypted, and how keys can be exchanged. To help, Oasis (Organization for the Advancement of Structured Information Standards) created WS-Security, a standard for applying XML Security and XML Encryption in Web services.
(click image for larger view) WS-Security is among the most mature of the WS-* standards, supported by almost all Web services and SOA vendors. Its main weakness is that, like all the WS-* standards, WS-Security requires SOAP--anyone doing business with Web services running REST (Representational State Transfer, a way of describing XML Web services that don t use SOAP) need not apply.
The main argument for using REST rather than SOAP is simplicity, so most REST users stick to SSL. Because REST requires HTTP and tends to be used for point-to-point links, SSL tunnels are often enough. Enterprises that want to apply message-layer security in REST will need to create their own protocols and data formats.
Pulling together every business partner and designing a custom, secure XML format for REST is a difficult sell for most enterprises, so the existence of WS-Security can be a powerful argument for SOAP. However, large Web services providers, including Amazon.com and Google, have successfully developed their own ways of locking down REST, using security tokens that are essentially shared secrets. Despite being proprietary, these are very popular among users: Amazon also offers a SOAP interface with WS-Security, yet has found that its customers prefer REST by a 5-1 margin. Most Amazon users are only accessing the Amazon service, not building an entire SOA, and so don t need SOAP s complexity.
FEDERATE YOUR IDENTITY
Though WS-Security helps encrypt and sign SOAP messages, it doesn t say anything about AAA (authentication, authorization, and accounting) or security policies. These are handled through other standards, which within the security space are all based on WS-Security (see "WS-* Security Standards: Too Much Of A Good Thing?" informationweek.com/1148/security_sb.htm).
Most of these standards eventually will be supported by all vendors in both the Enterprise Service Bus and Web services management areas, though at present they re too new to have had much impact on users.
The exception is federated identity, where the relatively new WS-Federation and WS-Trust are competing with SAML 2.0, an established standard also published by Oasis. Federated identity aims to enable single sign-on by separating authentication from the resource being accessed (see "Federated Identity And Single Sign-On," informationweek.com/1148/security_ diagram.htm). A user logs on to an identity provider that provides him with a credential that can then be used to access multiple resources. The credential, called an "assertion" in SAML and a "token" in WS-Trust, is similar to a digital certificate; it vouches for the user s identity and adds information, such as how the user is authenticated and when. SAML covers the entire SSO process, while the WS-* stack splits it into two standards: WS-Trust handles initial authentication and issuing of tokens, then WS-Federation covers the use of those tokens to access other resources.
The main practical difference is that SAML uses XML Encryption and XML Signature directly, meaning it can work with REST, whereas WS-Federation requires SOAP. SAML also has a large installed base, though this may not count for much because Microsoft has thrown its weight behind WS-Federation and said it will not support SAML.
Unlike some other standards battles, this isn t simply a case of Microsoft vs. everyone else. Microsoft developed WS-Federation with IBM, which is also a big backer of SAML, and every other vendor in the SAML camp has promised to support WS-Federation if there s a demand for it. In the long term, it s likely that both will be used: WS-Federation in Microsoft and SOAP environments, SAML in REST Web services.
WHERE TO PUT THE FIREWALL
On the public Internet, firewalls were one of the earliest drivers for Web services. Although different organizations have different security policies, almost all need to keep Port 80 open, so vendors and standards bodies gravitated toward text-based protocols that run over HTTP.
And, for the same reason, so did attackers and malware.
As a result, companies publishing Web services to the Internet have traditionally used application security gateways, appliances that can read and understand application-layer documents, filtering out potential attacks. These devices are usually called "XML firewalls," though a good one will understand more than just XML. A Web service using REST may encode some information inside HTTP headers or URLs, while developers of browser-based RIAs often see XML as too bloated, preferring JSON (JavaScript Object Notation) or plain text.
Security gateways are more than firewalls, adding all the functions found in the SOA management suites that handle authentication, authorization, and accounting. When Web services act as an interface to an enterprise SOA, the security gateway often needs to convert between JMS and HTTP, as the majority of SOAs don t use true Web services internally.
Unless connecting to the outside world, the ability to tunnel through firewalls is big negative.
In addition, a gateway can t effectively scan a document without first decrypting it, so most are also responsible for encryption and authentication, whether using SSL, WS-Security, or SAML. The deep-packet inspection and understanding of XML required to recognize attacks also makes security gateways useful for XML transformation and routing, and often better at it than management software, thanks to specialized SSL or XML acceleration hardware.
Most security gateways are still standalone boxes, installed in much the same way as a traditional firewall and sold by specialized vendors (see diagram, below).
Of the initial crop of security gateway vendors, four have now been snapped up: Sarvega by Intel, NetScaler by Citrix, DataPower by IBM, and Reactivity by Cisco Systems. With the exception of Intel, which uses the Sarvega technology to help other vendors build XML software or appliances around standard CPUs rather than custom ASICs, all are still selling gateways. But they re taking the products in different directions.
Citrix s NetScaler appliances combine an XML firewall with application front end, or AFE, functionality, something Cisco plans to do by integrating Reactivity into its Application Control Engine product line. Because AFEs also sit at the network edge and accelerate SSL, this combination makes a lot of sense, both for customers and for AFE vendors wanting to enter new markets. F5 has already announced that it will add an XML firewall, developed in-house, and competitors are likely to follow suit.
The other independent security gateway vendors--Layer 7, Vordel, and Xtradyne--are moving in the opposite direction, toward software and virtualization. Vordel and Xtradyne have always distributed their gateways as software, intended to be installed on dedicated blade servers. They re embracing virtual appliances, with Layer 7 and Vordel already selling versions of their software that run under VMware.
VIRTUALIZATION IN ITS PLACE
The performance hit of virtualization means that a virtual appliance can t yet match a dedicated server, so Vordel currently aims its virtual version more at testing and integration than production. Layer 7 started as a vendor of custom appliances with dedicated XML and SSL silicon, so it sees virtualization as an entry point to smaller customers that can t yet justify specialized hardware. But while "software-only" may be a budget-minded mantra for now, it s likely that virtual appliances will soon be used in businesses of all sizes.
Virtual machine performance is increasing rapidly, and the flexibility that virtualization brings is particularly useful in SOA. As new services are rolled out and reused, the SOA infrastructure needs to adapt, and virtualization lets hardware quickly be reassigned between roles. But sharing hardware resources requires that other servers be virtualized, and that can introduce security issues. Although few VMware security vulnerabilities have been reported, the complexity of managing multiple VMs may make it more likely that traffic will accidentally bypass a firewall (see our feature on virtualization security in the Aug. 20 issue of Strategic Security).
Because they include so much overlapping functionality, security gateways are merging with Web services management software. DataPower and Reactivity had both entered the management market before they were acquired, and at least one other firewall vendor is planning to do the same. Management vendors have not yet fought back by adding full XML firewalls, mostly because their software is intended to be run throughout a SOA rather than at the edge.
Because of SSL s popularity, SSL acceleration is ubiquitous in security gateways: Even virtual-appliance vendors support hardware with SSL accelerator cards. XML acceleration is much rarer, with only Layer 7, Cisco, and IBM boxes including dedicated XML chips; IBM builds its own, Cisco and Layer 7 rely on Tarari. This is partly because of Intel s use of its Sarvega technology--Layer 7 believes that the hardware market will gradually transition to software--but mostly because there hasn t yet been much demand for application-layer acceleration.
XML acceleration is useful mostly in Web services that transfer relatively long XML documents, such as SOAP or SAML messages. It isn t used much in Web services designed to support browser-based applications, as these transfer relatively little data in each session, perhaps a single XML element or JSON object, wrapped up in TCP/IP and HTTP headers. Because JavaScript and Flash clients don t need to reload an entire page every time a user performs an action, most Web 2.0 applications involve less application-layer traffic than comparable apps built using static XHTML.
Still, rich Internet applications don t let Web servers off easy. While they may reduce XML traffic, RIAs can dramatically increase the number of HTTP connections that a server has to deal with. Instead of waiting for a user to click on a link, most RIAs run in real time, initiating new connections every few seconds. Servers overloaded by this can often benefit from SSL acceleration and other AFE techniques, including load-balancing and HTTP compression.
By Andy Dornan, InformationWeek
URL: www.informationweek.com
© Галактика, 2007
© Издание 12NEWS (ИП Маринин А.Л.), 2007
