Locking Down Web Services

If Web services are the future of distributed computing, you need to meet its considerable security challenges head-on—and sooner rather than later.

• By Roberta Bragg
• 11/01/2001

As you've probably gathered from the plethora of hype and hope freely available from the vendor of your choice, Web services are the next distributed computing paradigm. [You can see our October cover stories at www.esj.com for in-depth coverage of Web services.—Ed.] While paradigms come and go, most of us survive—and not because we eagerly embrace every new technological whim. Rather, we've learned to selectively accumulate expertise in new technologies and champion their use where appropriate.

But I like to do more than that—and I'm going to challenge you to do the same. Ask yourself this question: What will be the security challenges of the new Web services model? I'm not talking about the proposed standards and fledgling products at the code level, since I doubt that most vendors will make that code available to us anyway. Rather, I mean examining the areas where your company will be most vulnerable where Web services are concerned—where your services meet with the outside world's.

Get Involved Early Three steps taken now can help assure that when your company does start using Web services in a serious way, security won't be compromised. Educate yourself; have your security team do the same. Now is the time to define for vendors and in-house developers just what standards they'll be expected to adhere to. Demand full details from vendors and programmers about how they're addressing security. PKIs, trusted relationships, CAs, storage of keys—ask for the works. Get involved as security standards are developed industrywide. If you've been in computing a while, your input is especially valuable. If you have an interest in this area, don't wait to have security standards dictated to you. —R.B.

First, I'm suggesting that you study up on the algorithms that define how Web services work. Then put your considerable expertise to work defining significant security practices that every vendor and every in-house programming team can follow in using this new model. You want everyone your firm works with to understand that security goes in before the label goes on; to do that, you have to help vendors and in-house staff understand your intent.

Second, demand that both your vendors and your programming staff give you full details on how they intend to provide for secure transactions with and between Web services. Make them tell you key strengths, standards incorporated and algorithms used. If public key algorithms are part and parcel to their approach, who's the Certificate Authority and what trusted relationships are in place? Where are keys generated and stored? How are they protected? Remember, while a Web server provides for interaction between a browser (and thus an individual) and a Web page, Web services provide for interaction between Web services. If code somewhere is talking to code elsewhere on my—or my company's—behalf, I want to know that hacker Beelzebub's code isn't spoofing, examining, corrupting, stealing or otherwise interfering with the process.

Third, review the proposed security standards and processes already in the works. Participate in the discussion. The opportunity is this: Each succeeding "new model of computing" seems to evolve without the benefit of the participation of the generations of computing experts from the previous one. I'm not saying that anyone working on current projects is clueless—far from it. There are some excellent ideas being incorporated. But let's face it—of the millions of programmers working on your Web services projects, everyone won't be quite so gifted. If Web services are to be secured, their design and implementation requires your participation. Since you probably won't get an invitation, you'll have to jump right in.

Security Essentials
Determining the questions to ask is simple. Secure Web services should provide sophisticated handling of the same security challenges you demand of any computing logic. The problem is, because Web services often will involve outside exposure, making such services safe demands that you take a very different approach.

Authentication: In the information systems world that most of us work in, authentication means proving identity by providing a user ID and password, or in more sophisticated environments, a smart card, token or body part. In modern networks, computers may authenticate each other through certificates, Kerberos or even pre-shared manual keys. In the Web services world, programs of varying ownership, origination and sophistication will be interacting with each other. How can we be assured that these pieces of code can correctly identify and authenticate each other?

Authorization: Let's pretend that you're a medical establishment—a hospital or a doctor's office—and I'm a medical insurance company. I might have Web services in place that receive and respond to your Web services' requests for payment. Once our services have proven their identity, how can we control what they can do with each other? In the course of the transfer of patient information from your Web service to mine, what controls the access my Web service has?

Think of two clerks from different companies talking on the phone. You have strict rules on what types of information can be provided to whom. Indeed, you control the access your employee has as well. Obviously, I could program my Web service to ask certain questions, but will yours be able to determine which it should answer? We can give rules to clerks and restrict their knowledge, and set file permissions to restrict users accessing computer files. Yet how will this model work when the people exchanging information are not people at all but snippets of code?

Privacy: Then there's a question of protecting the confidentiality of any knowledge transfer. Quite frankly, the thought of my medical history or financial status being bandied about the Internet is a bit scary. The obvious solution is encryption, but that fosters a new set of problems. We'll still need to negotiate algorithms and key strengths, and the basics of key exchange. IPSec, which does a spectacular job under controlled network conditions, relies on the comfort of identifying communications between known machines. If Web services are being used on private networks, IPSec will work, but who can pre-determine the exact machines that will be running these Web services when we're talking about choices from millions of machines?

Integrity: What will assure one Web service, or the consumer of Web services (perhaps a real person) that the data received from another Web service is really the data sent? I'm sure there will be plenty of attempts at launching Web services whose job is to establish themselves as illegal intermediaries between sanctioned conversations. While proper mutual authentication will help prevent that, we'll need to add additional safeguards. Will traditional checksums and signatures work here? Add to this the problem of validating data input. Since I can't be sure that your Web service will provide data that exactly meets my Web service input needs, I need to pre-check (validate) all data before it's actually submitted to my Web service functions. Some new protocols (SOAP, for example) can define what the acceptable input parameters are for a Web service.

Non-repudiation: With all these automated services exchanging, negotiating and communicating on our behalf, how will you counter assertions of non-receipt of information, payment or request? Will my insurance Web service be able to argue that your medical Web service never provided a completed claim and that's why payment wasn't made?

Audit: Here's a final question: How can you establish an audit trail with Web services? What will it look like and how will it be used? Where will it be stored? Will there be Web services whose core responsibility is to demand, acquire and store this information? And to diverge slightly from examining Web services from strictly a security angle, how will information system auditors be able to conduct a Web services security audit?

Emerging Standards
It will be interesting as we see how this all pans out. The success of Web services depends on vendor-neutral standards. After all, maybe you can make your business a one-vendor entity, but if we want to utilize Web services available across space and time, my services have to be able to talk to yours.

Proposed new or existing Internet standards that are endorsed by the major players in Web services have enabled the current generation of services to work with most legacy systems. Those include the data representation language XML, the Web Services Description Language (WSDL), the registration database standard Universal Description, Discovery and Integration (UDDI) and the messaging protocol Simple Object Access Protocol (SOAP).

Early Vendor Solutions In addition to SSL and other PKI/certificate-based approaches, vendors are using established and proposed standards, as well as proprietary solutions. Here are a few vendor approaches: IBM (www.ibm.com): IBM's DB2/XML Extender allows access to DB2 version 7.2 by Web services applications. Tivoli Manager for WebSphere Application Server provides a single point of control for access in distributed environments that use WebSphere. Tivoli SecureWay Policy Director can be used by WebSphere developers to build access control into applications. Microsoft (www.microsoft.com): Microsoft's .NET strategy entails the use of security in several areas including file, operation and URL authorization, rule-based security policies and role-based security based on users inside and outside of traditional Windows environments. Microsoft's strategy also provides for authentication of .NET forms, in which a user provides credentials on a form that's submitted to the application for validation. Netegrity (www.netegrity.com): Netegrity's TransactionMinder is intended to provide centrally managed, policy-based access control to XML-based Web services and UDDI registries with initial support for Sun ONE and webMethod's platform. Future support is planned for Microsoft's .NET, BEA Systems and Bowstreet's Web services. Oblix (www.oblix.com): Oblix has released NetPoint 5.0, a management software product that uses XML-based Web services for identity and access. It integrates with Microsoft's Active Directory (user and group controls defined in AD can be used) and Verisign's On-Site Certificate services. Securant Technologies (www.RSA.com): Securant Technologies, now part of RSA Securities, has announced single sign-on, Web-access management for BEA WebLogic's Portal 4.0 through its ClearTrust SecureControl product. Securant's products will use SAML. —R.B.

Security Standards Underway
Some Web services security standards are currently under development. Security Assertion Markup Language (SAML) is a proposed Internet standard for exchanging security information over the Internet. It isn't a new security process, but merely a description language. SAML will be submitted to the standards body OASIS (Organization for the Advancement of Structured Information Standards), which works on standards for XML. SAML works with HTTP, FTP, SMTP and other protocols; it supports the use of Java, XML, BizTalk and ebXML (a collection of specifications for doing e-business over the Internet using open standard technologies).

XML Key Management Services (XKMS) is the IETF-W3C proposed standard for XML Digital Signatures. XKMS defines the XML messages used by applications to register key pairs, locate keys and validate information related to the key. Using XKMS, Web services could be programmed to perform the tasks associated with key management or validation; other Web services could use the keys to encrypt documents or verify signatures. XKMS does not require x.509 certificates but supports them, along with PGP and SPKI. Verisign's XML Trust Services is an implementation of this proposed standard. Currently, Verisign provides an XML Trust Center and supports an API for Java implementation of the XML digital signature specification.

S2ML, the Security Services Markup Language, is a proposed standard for secure e-commerce transactions via XML. The use of S2ML will allow businesses to have security services (authentication, authorization and profiles).

As your organization considers Web services, remember these final points: You can't control Web services that aren't yours, and someone else's failure to secure their process may radically affect you. The linkage of corporate networks via ubiquitous Web services can never be stronger than the weakest link. Establish trust relationships with your partners. Don't blindly develop plans for your company. In the new world of Web services, you'll become your brother's keeper, and he yours.