Burton: Put Web services security on front burner |
 |
By Colleen Frye, News Writer
09 Jan 2006 | SearchWebServices.com |
|
|
Now that the WS-Security spec is "ready for prime time" and many security products are supporting it, organizations should start to develop a Web services security strategy, according to Anne Thomas Manes, a vice president and research director at Burton Group in Midvale, Utah.
However, in her recent report, Web Services Security: A Plethora of Products, Manes stressed that there are as yet no standards for configuring security. In the interim, she recommends externalizing security so it can be managed and controlled centrally. For now, she said, XML security gateways and Web services management products remain the best way to do this.
|
|
|
|
|
You don't want to use the built-in capabilities of a [Microsoft] Indigo or a WebSphere, because there's no centralized way to manage it.
Anne Thomas Manes
Vice President and Research Director, Burton Group
|
|
|
|
|
|
|
|
|
|
"Most people are getting beyond the prototype stage, and they're starting serious [Web services] deployments," Manes said. "A lot of companies are not really coordinating efforts; they're letting individual teams do what they want."
According to Burton Group, very few organizations are using WS-Security (WSS) in production. Manes said these companies need to start organizing now and put a Web services security plan in place early. "Once the chickens are out of the hen house, it's harder to get them back inside," she said.
WS-Security is a standard for implementing application-level security in SOAP-based applications. It was ratified by Oasis in April 2004. Version 1.0, according to the Burton report, consists of the core specification and four other specs that define token profiles for Username tokens, X.509 certificates, Security Assertion Markup Language (SAML) assertions and Rights Expression Language (REL) licenses.
Manes recommends that organizations use a combination of transport-level security mechanisms -- HTTP authentication, Secure Sockets Layer (SSL) mutual authentication and SSL encryption -- as well as application-level security.
Manes said organizations also need to think through these issues: "You have to know what auditing is required and the minimum requirement for authentication to get into the business. How do you control access to the business? How do you stop people from exposing Web services with no security? Web services open the system up, but you can't open it up without security."
According to Burton Group, more than three dozen vendors support version 1.0 of the WSS spec and/or other Web services security capabilities. Products that support WSS must include a WSS provider -- a routine that can process WSS SOAP headers and one or more token profiles, according to the company. Burton Group puts these vendors into the following categories: Web services platforms, WSS libraries, Web services management (WSM), XML security gateways, XML virtual private networks, Web services fraud detection and Web services single sign-on (SSO) and federation.
For now, though, only WSM offerings and XML gateways provide a centralized way to control security, Manes said, and these vendors are the market leaders in Web service security. "All Web services platforms typically use a deployment description, so if you use the built-in Web services security in [IBM] WebSphere, for example, there's a configuration file you have to write, but it's unique to that specific product. There's no way to go to a central console and say, 'Here are the security options.' That falls to the developer to configure security for every service. Many products support WS-Policy, so it will expose the security requirements, but that's not how you configure it," Manes said.
She continued, "You don't want to use the built-in capabilities of a [Microsoft] Indigo or a WebSphere, because there's no centralized way to manage it. Today, you have an option of using an AmberPoint or an Actional, for example, and the ability to define and implement policy enforcement points, and they also work with [XML] gateways, which are a big advantage."
Two WS* specifications that have not been submitted to a standards body yet -- WS-Policy and WS-Trust -- will help address the security configuration issue, and lessen the need for organizations to standardize on a single WSM product, according to Manes.
"They have to get WS-Policy into a standards body. I expected that to happen this fall, and I was disappointed. It's political. There are too many authors on WS-Policy." Once it's in a standards body, the next step, she said, is to start defining the assertion language [WS-SecurityPolicy] and a standard configuration mechanism. We're still probably three-plus years away we before solve that."
And WS-Trust, she said, "is a more automatic way to get the credentials you need to talk to a service. A nice feature gateway and management products provide is credential mapping; once you get WS-Trust more widely deployed, WS-Trust can do that for you." WS-Trust, she said, "is not so much a major enabler, but it will impact the market."
|
|
|
|
