The Future of Web Services Security: A Conversation with Eve Maler

Print-friendly Version

Eve Maler

Sun Microsystems' Eve Maler, chair of the Security Work Plan Working Group of WS-I (Web Services Interoperability Organization), is a leading mover and shaker in the world of Web services security. She co-founded, formerly chaired, and is currently coordinating editor of the SAML (Security Assertion Markup Language) committee, which brought together divergent XML-based security efforts in an effort to develop a common standard. A leading XML architect, she currently tracks and coordinates Sun's interaction with XML/Web services security standards. We met with her recently for an update on the development of Web services security.

How long is it likely to take to establish viable Web services security standards?

"What's missing most now is a standard way of negotiating the security constraints that service requesters and responders will adhere to. This may not be fully standardized until late in 2003 and it's important for this work to reflect a clear understanding of the problem space." - Eve Maler, chair of the Security Work Plan Working Group of WS-I

It's best not to think in black and white terms. There are specifications appearing on the scene that attempt to secure different facets of Web services. As each specification becomes standardized and viable over time, the operation of Web services will be better protected. And the parts that are not standardized yet will require a lot of non-interoperable back and forth, as they do now. For example, there's a lot of point-to-point negotiation required when offering a real service on the open Internet -- which is itself rare these days. Many implicit assumptions are built into the services that people are offering, because if they're happening behind a firewall, it's easy to go over to Joe Blow's office and discuss your needs. What's missing most now is a standard way of negotiating the security constraints that service requesters and responders will adhere to.

"We'd like developers to appreciate the idea that they don't have to 'roll their own'. Rolling your own is a dangerous thing in the world of Web services security. Well-meaning, experienced developers can easily go astray." - Eve Maler, chair of the Security Work Plan Working Group of WS-I

This may not be fully standardized until late in 2003 and it's important for this work to reflect a clear understanding of the problem space. And after that, there's going to be a lot more work on trust management. So improvements will occur as long as these processes take place in venues that allow the right experts to look at them.

We'd like developers to appreciate the idea that they don't have to "roll their own". Rolling your own is a dangerous thing in the world of Web services security. Well-meaning, experienced developers can easily go astray. Once all the security specifications are developed, the means to protect exchanges over the Web will become simpler and of higher quality. We must do the right things to ensure this.

A lot of people want to know why we can't use traditional security technologies directly in Web services.

		A Security Shorthand "Security" refers to a variety of specific protective goals: Confidentiality: Can prying eyes see it? Authentication: Are you who you say you are? Trust: Have I agreed to work with you? Non-repudiation: Can you claim that you didn't send or receive it even if you did? Integrity: Was it altered before I got it? Authorization: Are you allowed to have it? Auditing: Can I prove what happened?
		Matching Security Technologies Confidentiality: Key-based digital encryption and decryption. Authentication: Username/password, key-based digital signing and signature verification, challenge-response, biometrics, smart cards, etc. Trust: Key-based digital signing and signature verification. Non-repudiation: Key-based digital signing and signature verification, message reliability. Integrity: Message Digest, itself authenticated with a digital signature. Authorization: Application of policy, access control, digital rights management. Auditing: Various forms of logging, themselves secured to avoid tampering.
		Standards Organizations WS-I (Web Services Interoperability Organization): WS-I promotes Web services interoperability across platforms, operating systems, and programming languages. Its primary focus is on interoperability of widely adopted specifications. OASIS (Organization for the Advancement of Structured Information Standards): OASIS drives the development, convergence, and adoption of e-business standards. W3C (World Wide Web Consortium): W3C develops common protocols to promote the evolution and interoperability of the World Wide Web. IETF (Internet Engineering Task Force): The IETF is an international community of network designers, operators, vendors, and researchers concerned with the evolution of the Internet architecture. Liberty Alliance Project: The mission of the Liberty Alliance Project is to establish an open standard for federated network identity through open technical specifications.

There are a couple of reasons that traditional technologies won't always suffice. First, the trust issues still haven't been fully solved in traditional computing; they haven't scaled to meet our expectations, and Web services present an opportunity to get this right.

Second, with Web services, end to end isn't the same as point to point. Messages are going between a requester and a responding service, but they may also pass through several intermediaries, and thus, several possible hubs. Therefore, a technology that focuses solely on securing the transport channel may not be sufficient. You need security technologies that persist past that transient part. And there are technologies that do that, but without the XML security standards, they don't take advantage of the opportunities inherent in XML's granularity. XML has a nested hierarchy structure inside it with elements containing sub-elements. It's handy to say, "Encrypt only portions of a message." Intermediaries that are allowed to see one portion may not be allowed to see other portions. So, you get benefits from the granularity.

Trust as Competence and Trust as Integrity

You mentioned trust - in our everyday interactions, there are at least two very different kinds. We can trust a person or an institution's integrity, and we can trust their technical competence. We want our car mechanic to be ethical and honestly tell us what the problem is, but we also want to trust that he or she will have the technical competence to understand and fix the problem. How do these two kinds of trust play out with Web services?

That's a really interesting distinction -- trusting a person or entity to operate in good faith versus trusting them to be technically competent. Most discussions of Web services and the use of trust frameworks and technologies don't make the distinction. But when an entity vouches for another entity, which is often how trust frameworks operate, you're basically taking the word of someone you trust; you are assuming that someone else you trust is properly representing themselves, and you want to deal with that entity. In general, the trust framework is conveying to you the kind of trust that's being offered.

When you deal with this sort of good faith kind of trust, you're really talking about contractual trust. Trust enters into all kinds of contractual arrangements. And there are technologies like the ebXML (Electronic Business XML) collaboration protocol profile and agreement system, which enables you to make that kind of contractual arrangement machine-readable. You're agreeing to certain aspects of the interaction that you're going to have on a technical level on a machine-to-machine level. So, in that case, the trust is built by explicitly specifying what it is you're going to do. And it's a violation of a contract to do otherwise.

Can you tell us about the role of Java technology in Web services security?

The Java Web Services Developer Pack (Java WSDP) is going to be including XML signature and XML encryption support in its next release, scheduled for fall 2003. The plan is for it to have Web services security support.

Many people perceive Microsoft as positioning itself to have a tight grip on Web services security, functioning through our personal authentication via Passport. Can you address this perception?

Sun Microsystems is very concerned with the open specification of standards and the specification of systems that don't rely on a single hub to do all the jobs. We have heard some intimations that a system like Passport will ultimately be a federated system so that you won't always have to go through one Web site to start your journey online. That would be a good thing. The Liberty Alliance takes exactly this federated approach to managing and using your electronic identity.

What's best is for all of the relevant security infrastructure for Web services to be standardized in an open venue to be seen by all the right eyes, and especially for the IPR (intellectual property rights) terms to be open enough so that implementations can be widely accepted. This is Sun's goal in participating in Web services security standardization, and it's the key for ensuring that no one company can create lock-in.

What should businesses and IT professionals know about the status of Web services security right now?

Web services are currently being secured in very traditional ways, to the extent that they're being secured at all. Web services on the Internet, as opposed to behind a firewall, might be secured with HTTPS SSL mechanisms, which are quite common in online individual purchase transactions. It does a fairly good job of protecting the contents of the message while in transit. However, in more complex Web services scenarios, this solution won't always be adequate. If many intermediaries are transacting with the messages as they go from initial sender A to ultimate receiver B, the simple SSL solution might not be adequate. The standards are not cooked yet for securing the content of the message and the channel in all the ways that people would want.

Misconceptions about Web Services Security

What are the biggest misconceptions in the minds of developers?

Too many people believe that the Web services security specs that OASIS is working on will be a magic bullet. The current work on Web Services Security at OASIS is the framework for taking the first baby steps to securing individual messages. Because the framework offers a lot of options, it's not necessarily a panacea.

What are the biggest misconceptions about Web services security in the minds of businesses and IT professionals in business?

"Perhaps the biggest misconception is that it's a very simple picture, and that an implementation of a particular spec will make everything completely interoperable and secure." - Eve Maler, chair of the Security Work Plan Working Group of WS-I

It may be that IT professionals have the same misconception about OASIS Web services security specs as developers. The press is fixated on WS-Security as the solution to everything when, in fact, WS-Security itself relies on a number of under-emphasized technologies. I'm thinking specifically of XML Signature and XML Encryption, which are specs coming out of W3C, the Worldwide Web Consortium. And those specs themselves rely on even older and much more mature and established technologies when it comes to public key infrastructure, encryption technology, etc.

So, what we're really building are a number of specs that are explaining how to use the specs that have already gone before, or that explain how to use the building block specs. Once again, perhaps the biggest misconception is that it's a very simple picture, and that an implementation of a particular spec will make everything completely interoperable and secure. As I said, there is no magic bullet.

Creating Standards: Getting the Stakeholders to the Table

How would you characterize the non-technical problems of creating security standards?

It's a challenge to get all of the good ideas out on the table and worked on in a way so that all the players contribute. Complexity and opaqueness are enemies of successfully deployed security. Standards work is hard, and, in a way, the problems involve group dynamics as much as anything else.

The word "security" is shorthand for many different kinds of protection of many different kinds of things. We assume we're going to apply a security Band-Aid to Web services transactions, but that's incorrect. You'll have needs for confidentiality and authentication at a certain level. You'll have needs for non-repudiation and integrity of the data. And there are many ways to solve these problems. There are many kinds of attacks that can happen. And there are new kinds of attacks that can happen in a Web services environment that take advantage of that new environment. And there will be some technical problems to solve as well. In fact, some of the problems are not even new problems. Deploying public key infrastructure is a challenge -- and Web services would benefit from a more widely deployed PKI (public key infrastructure), but I don't know if we're going to get there.

Standardizing Interoperability

What are the standardization problems for interoperability in Web services security?

They're the same problems you have in any technical endeavor. If you make specs that are merely frameworks or provide a lot of options, interoperability suffers. It's important to create specs that are written as tightly as possible so as to prevent misunderstandings and to prevent different conforming implementations that don't interoperate. That's often difficult, especially in framework types of technologies. It behooves you to make profiles of that framework -- named profiles so that people can say, "Well, I've implemented this spec, and I've done Profile X, and so I can work with anyone who deals with Profile X." That's the best way to do it.

Successful Standards: Sanction and Traction

What will make Web services security standards successful?

Patrick Gannon, the CEO of OASIS, argues that to make any standards effort successful you need a combination of both sanction and traction.

By sanction I mean: Has it been formally approved by an open standards body? Has it gone through a process where all the right eyes have looked at it and everyone who has a stake has had a chance to participate? And then "traction" refers to actual uptake in the industry. It's possible for a standard to be embraced by the standards people, and be a critical success, but a failure at the box office, so to speak. And the reverse can occur -- specs that are proprietary in nature can nonetheless get a lot of uptake. But ideally you want sanction. You want to make sure that the franchise -- to mix my metaphors -- is widely enough held to ensure that the right people have strengthened the design of the technology. So, for example, a spec like SAML 1.0, that was developed at OASIS, which is an extremely open standards venue that allows people from all walks to join, has quite a lot of sanction. It also has traction in that more than a dozen vendors have either pledged or already delivered conforming support for SAML 1.0.

In fact, the Sun ONE Identity Server, version 6.0, which is now out, supports SAML and Liberty. So, there's an example of something with uptake and also with the formal kind of approval that you should really look for. It's got both sanction and traction.

See Also

Java Technology and Web Services
(http://java.sun.com/webservices/)

OASIS
(http://www.oasis-open.org/)

WS-I
(http://www.ws-i.org/)

W3C
(http://www.w3.org/)

Liberty Alliance
(http://projectliberty.org/)