Network Computing is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Analysis: SOA Security: Page 4 of 8

chart: One Stop Shopping? Not
(click image for larger view)

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.