BOSTON -- Standards bodies and acronyms litter the Web services security landscape to the point where security...
by obscurity takes on a whole new, and literal, meaning.
A security professional trying to architect a Web service has to digest an alphabet soup of specifications, schemas and protocols (SAML, XACML, XKMS, XML, XrML, UDDI, SOAP and more) from standards bodies like OASIS, W3C and others.
OASIS and W3C (World Wide Web Consortium) got together this week at the Forum on Security Standards for Web Services to try to iron out this mess, bring users up to speed on where current specifications stand, and in some cases, explain just what Web services security is all about. The forum was part of the XML Web Services One conference.
"What we want is for Web services to be like e-mail. It works and anyone can talk to anyone with a few exceptions," said Phillip Hallam-Baker, principal security architect for VeriSign and the co-author of several Web services security specifications like XML Key Management 1.0 and 2.0, and Web Services-Security. "What we don't want is for Web services to be like the power cord."
Hallam-Baker, the lead speaker at this week's forum, then grabbed a tangle of power cords and adaptors for all the devices he travels with: laptop, PDA, cell phone -- none of them standardized on a particular voltage or adaptor. Hallam-Baker then grabbed his universal adaptor and compared it to a Web service.
As for security?
"Well, think of security as the thing that keeps this all from catching fire," Hallam-Baker said.
Hallam-Baker, like most of the presenters this week, said security standards are beneficial and necessary because they ensure interoperability, vendor independence and define intellectual property constraints.
"The challenge arises, because, you cannot connect the supply chain on the Internet without trust and security," Hallam-Baker said.
Essentially, Web services are an extension of person-to-application communication, only that with Web services, applications are communicating with applications and securing those tunnels require more than SSL (Secure Sockets Layer), for example, can offer.
Applications, Hallam-Baker said, communicate on machines to a sub-routine and that tunnel is protected within the confines of an operating system. With a Web service, applications are talking to remote sub-routines.
We have to provide some set of security assumptions that hold as they do on a single uni-processor machine," Hallam-Baker said. "We have to replicate the security context provided by an operating system -- in other words, protected memory and access control."
Specifications like SAML (Security Assertion Markup Language) and its cousins are supposed to secure Web services beyond what SSL offers.
"SSL is enough for some applications, but as far as an infrastructure for supporting Web services goes, it's simply not enough," Hallam-Baker said. "We need a security infrastructure that secures data when it's moving and when it's stationary."
Hallam-Baker pointed out that SSL supports data when it is in transit, but not in storage and that SSL does not support multi-party transactions, nor does it support non-repudiation.
"SSL messages are opaque to the firewall," Hallam-Baker said.