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.
Client-side identity 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 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 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 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.
|
![]() |
|