CNET también está disponible en español.

Ir a español

Don't show this again

HolidayBuyer's Guide
Culture

Commentary: Four key Web services decisions

Architectures and standards for securing Web services will evolve rapidly, but one consistent theme in the developing standards is the need to support a wide variety of scenarios.

Commentary: Four key Web services decisions
By Forrester Research
Special to CNET News.com
November 11, 2003, 5:15PM PT

By Randy Heffner, analyst, Forrester Research

Architectures and standards for securing Web services will evolve rapidly during the next two to three years, but one consistent theme in the developing standards is the need to support a wide variety of scenarios.

Individual firms will sometimes be dictated which architecture to use by partners and sometimes they will negotiate; either way, it is important to know the choices and their implications. Decide the strategy based on an analysis of the characteristics and risks of the business processes to be supported. Start with accountability and audit requirements, because these may drive the other decisions.

Until secure Web services standards mature, favor low implementation costs that use server-side administration; nonfederated, enterprise-level identities; and audits that are based on simple logging. Use the more advanced options only to meet explicit requirements that are demanded today.


Get Up to Speed on...
Web services
Get the latest headlines and
company-specific news in our
expanded GUTS section.


This is appropriate, because security is not free, and a one-size-fits-all security architecture will be burdensome for certain business situations and insufficient for others. Buried within the wide range of technical choices for secure Web services are four key decisions that have the greatest impact on business process cost and security policy.

Client-side identity
The client-side identity Web services use may be tied to individual end users or to their enterprise. Historically, business-to-business transactions have been identified with the enterprise because, for example, a supplier is primarily interested in knowing that an incoming purchase order was authorized by the buying company and has no way to verify the identity of the end user, who submitted the order through the buyer's systems.

However, emerging B2B connections that involve personal data--health benefits, retirement savings, for example--should be accessed only by the individual whose data it is. Also, a buyer may achieve stronger B2B controls if, in the purchase order example, the supplier is able to validate an incoming purchase against authorized identities the buyer supplies.

Since user-level identities are more expensive to administer (for the simple reasons that there are more of them and they change), firms must weigh these extra costs against the security and auditability benefits gained.

Security infrastructure integration
The administrative costs and burdens of user-level identities may be eased through federation of security infrastructures. For instance, in a federated version of the purchase order, tagging an employee record as "senior buyer" might automatically enable a supplier to authorize the employee to submit orders.

Federation standards, products and deployments are new, and costs and risks are not fully understood. The bigger issue, however, is that the business models for federation are not yet clear, so establishing a federated relationship requires careful negotiation of business terms and conditions: Who is liable for improper authentication or authorization? What service levels are guaranteed? If there are few users, it will not be worth the effort.

Strength of audit
Processing errors and fraudulent activities sometimes happen. When they do, it is important to be able to audit who did what and to be able to hold people or firms accountable, according to applicable business agreements and policies.

The most stringent type of auditing is third-party nonrepudiation, which would involve routing digitally signed Web services requests through an independent service provider, which could attest in court as to when certain transactions flow between business partners. The extra expense may be worth it for sensitive business processes, especially those that involve high dollar amounts. In other cases, simple logging of outgoing and incoming transactions may be deemed sufficient.

Security administration
Although some degree of security administration will always be required on both sides of a secure Web services connection, there are certain security definitions that may be managed on either side.

To continue the purchase order example, suppose the partners agree to user-level identities. Although the buyer firm must approve each user account that is created, there are two options for how the accounts are actually entered into the supplier's systems: The supplier might retain full control of creating and deleting user accounts, or the supplier might delegate control, providing a "super user" account, by which the buyer firm can create and delete its own user accounts. Delegated administration requires additional implementation and careful negotiation of business terms but is notably more efficient for both parties.

The choice of options should be driven by the characteristics and risks of the business process, business partner relationships and the quantities of partners and users involved. Look first at accountability and audit requirements, because these may drive other decisions. A risky, high-dollar business process argues for third-party nonrepudiation. Having many users is a good argument for having client-side administration. Having small, tight partner relationships may be a good argument for federation.

Several factors must be combined to determine the best choices for any one firm. And, in the end, the choice may simply be imposed by a powerful partner such as Wal-Mart Stores or a major automaker.

© 2003, Forrester Research, Inc. All rights reserved. Information is based on best available resources. Opinions reflect judgment at the time and are subject to change.