Inside WS-Security -- A Developer's View
As the WS-I's Basic Security Working Group convenes this week, IDN takes an in-depth developers' look at WS-Security, a top proposal before BSWG. IDN spoke with Steven Van Roekel, a Microsoft web services director, and one of the co-authors WS-Security with IBM, Versign and others. He details the vision and benefits of the proposal, discusses how developers could implement it, what cross-platform features exist and are planned, and how WS-Security backers are working with other camps.
The WS-I has now begun the formal work of ensuring interoperability among a variety of web services security mechanisms, with the first meetings of the newly formed Basic Security Working Group.
The BSWG's charter is to develop a framework and a short-term work plan for the WS-I Board, prioritizing and scoping security interoperability issues, leveraging usage scenarios and use cases, and creating draft charters for workgroups as required.
This week, IDN takes an in-depth look at one of the more highly visible proposals before the BSWG: WS-Security, a multi-vendor technology that many leading Java and .NET developers and security admins say is poised to become a "core foundation" security standard.
IDN spoke with Microsoft's Director of Web Services Technical Marketing, Steven Van Roekel, who explained how WS-Security is one of the first vendor implementations of the new W3C standards for XML Encryption and XML Signature.
In our conversation, Van Roekel also shared details on how developers can implement WS-Security across multi-vendor (Java and .NET) platforms, the vision for "next steps" for securing web services, and even how the WS-I's BSWG plans to produce a basic Security Profile, to help guide developers in building an interoperable security framework from various products and standards.
Steven Van Roekel, Director of Web Services
I. WS-Security-- Drafting and Deploying an Interoperable Approach
IDN: Before we get into the current details of WS-Security and it's related WS-* proposals, can you give a brief overview of its beginning, and how Microsoft and IBM became partners in WS-Security's development?
Van Roekel: Yes, as we started work on web services for distributed computing, we found those types of customers were demanding more than XML.
Around the fall of 2001, Microsoft identified two major things that need to happen -- one of them was interoperability; the other was to tackle security.
Around that exact same time we wrote a note to the W3C calling for security in web services and after that we published our own version of WS-Security. Later, we found that IBM was doing similar work in that space, and when we held the two pieces of work up to the light, we said there is enough similarities here, and we care enough about factoring this against everything else that's out there, that in we should work together to build an interoperable solution to security. Microsoft, IBM and other published WS-Security in April 2002.
IDN: That came out of work that showed web services needed a more sound foundation for security?
Van Roekel To take it back a bit further, what happened about 2 1/2 years ago was the concept of distributed computing and the concept of XML sort of merged into one concept. Five companies -- two individuals and three companies -- got together to develop SOAP, based on XML, as a way of doing very simple distributed computing across the public Internet.
A lot of efforts grew out of that J2EE, CORBA, RPC, DCOM means being able to tie systems together in a distributed way. But the big thing that people discovered when they started doing all these technologies was they had to buy one vendors' systems at both ends. To do CORBA, you had to have a CORBA vendor at both ends, and usually that meant the same vendor at both ends.
Around that time, we started on the roadmap to develop a development suite to deliver SOAP development tools. What we soon discovered was that SOAP couldn't do everything they needed to do. SOAP was a good way to send a message between two places, but it didn't have native support for security or reliable messaging.
IDN: That's where the follow-ons to WS-Security started to take shape?
Van Roekel: In May of 2002, we published WS-Attachment, in August we published WS-Coordination and WS-Transaction and also delivered our first development tool at that time. So, today, the stack is really starting to take shape and all the pieces are falling into place.
And, as far as WS-Security goes, by last fall (2002), there were development tools, and an addendum to WS-Security to help with interoperability. We also held an interoperability demo between Microsoft, IBM and Verisign to show J2EE-to.Net interoperability. Then, in September WS-Security was first taken to OASIS standards body.
IDN: What about providing developers an overall architecture document for security, so they could better envision how these layers work together, and how different approaches would plug-in? Right now, I believe, many end user developers are afriad that a difference of opinion could mean a lack of interoperability?
Van Roekel: You're right. We need to do a better job there from a WS-I perspective. At Microsoft, we're also working on roadmap areas for security. At MSDN, we have a security roadmap whitepaper that goes through some 20-25 scenarios for web services security.
IDN: You seem very optimistic about B2B web services that go outside the firewall. Why?
Van Roekel: I think tackling security is the first and foremost thing to allow web services developers to go outside their organizations in a much easier way. So, I think adoption of web services for applications outside the organization is actually going to be quite faster than we saw in the past.
Van Roekel: I like the analogy that not until people saw the little padlock down at the corner of their browser were they comfortable about putting their credit card information out on the Internet. That [padlock] helped tell them, 'I've got a secure connection between me and this vendor, and I trust this vendor enough [to buy over the Internet].
Not until we get security as a core element of web services will companies be willing and trusting to put their sensitive information out on the public Internet. It's just a huge hurdle that needs to be crossed.
IDN: Does WS-Security incorporate W3C's recent standards on XML Encryption and Digital Signature?
Van Roekel: Those are the core two elements of WS-Security, completely based on those two specs.
IDN: Do you expect that support should ease any contention about WS-Security, and follow-on proposals, among vendors?
Van Roekel: We built a wrapper around it, so we could say, 'Here are some hooks to put into the WS-Policy and federation stuff. The result was we had a way of expressing encryption and digital signature so that the two specs could be expressed in a SOAP header. It is kind of a nice packaging of more things than just encryption.
IDN: What about tools for implementation?
Van Roekel: As far as developer tools for this advanced web services work, us and IBM and BEA are just starting to ramp up in these areas.
IDN: There had been some special controversy over SAML late last year. What was the final determination on how SAML is supported in WS-Security?
Van Roekel: What we declared as far as SAML goes is that WS-Security will support SAML assertions, which means we'll be able to package up a person's identity via SAML into SOAP via WS-Security. But, WS-Security will not be supporting the SAML protocol, for technologies like the URL redirectors and such.
IDN: So what is the implication for a developer looking to use SAML?
Van Roekel: If you're choosing to use SAML with SOAP with web services, I think you'd use our approach because SAML has said that's the way you should do it. On the other hand, if you're using SAML natively in some mainline security, you'd probably just use the SAML approach is a browser application.
IDN: There has also been some confusion about royalty-free and other types of licenses. What is the current thinking on licensing WS-Security, and its follow-on technologies?
Van Roekel: WS-Security is a licensed piece of technology, so if you wanted to go implement WS-Security, you can go to the Microsoft website, print off a license, sign it and fax it back. It is not royalty bearing. That is a case where Microsoft is trying to protect its IP [intellectual property], but not attach any royalty or fee to it. We took WS-Security to OASIS because XML and SAML were there, so it was a logical place. But if you take a case-by-case view, each standards body has different policies about the way to declare licensing.
II. WS-I's Role in Ensuring Security Interoperability
IDN: So, how do you see WS-I and WS-Security helping to implement an interoperable security framework that will 'factor' with many different technologies?
Van Roekel: WS-I and WS-Security are totally separate worlds. The Basic Profile [for web services 1.0] is very near completion. The next things that WS-I will be tackling is security, and the board right now is working out what that looks like, what kind of spec will be considered, etc.
IDN: I would assume it's important to have as much vendor support for these specs as possible, which would help them 'factor' with many different technologies. What is the status of multi-vendor support for these aspects of WS-*? .
Van Roekel: In the case of WS-Policy and the secure conversation there were multiple vendors in the authoring and reviewing phases of that, including IBM, Versign and Entrust. They were crucial in WS-Security and for some of the work in WS-Policy., From that stage, we are taking [WS-Policy] to workshops to include lots of people to ask them how we should implement this and how to think about the holistic picture, where we need to support other enterprise functions, etc. We'll then take it to a standards body down the road, have anybody join and eventually hopefully take it to the WS-I after that.
IDN: So, what is the status of WS-Security and it's follow-on proposals vis-Ã -vis WS-I?
Van Roekel: Everything that WS-I will ever consider has been in a standards body long enough that enough people are implementing it and doing work with it that we can take a look at it.
IDN: Are you at that stage with WS-Security and the other WS-specs we've mentioned?
Van Roekel: WS-Security we feel is at that stage. WS-Policy and the other ones are still new.
IDN: So, what happens now, to get the WS-I machinery to implement WS-Security into a security profile?
Van Roekel: We're active in the working groups and committee at WS-I, and we'll therefore take WS-Security to the WS-I and say here's something we should have on the plate. Microsoft is very active in the working groups of WS-I and many WS-I members were authors or supporters of WS-Security. This collective group will be encouraging the Security Working Group to consider this technology for interoperable, secure Web services.
IDN: Is that happening now?
Van Roekel: Yes. With the Basic Security Working Group forming in late March, WS-I will now be looking at technologies that relate to securing Web services.
IDN: What should developers watch for?
Van Roekel: By this summer, the WS-I will clearly be working hard on figuring out what security is going to look like.
IDN: Once you have the core WS-Security in place, is it fair to suggest the rest of WS-* will follow?
Van Roekel: From the Microsoft perspective, that's true.
IDN: So, if true, when WS-I begins template development and interoperability work? Do you expect WS-I will also take into account the other WS-* layers now in working groups?
Van Roekel: I don't know. I can't make prediction on which way the community will go. I think it will make sense to look across the board, however, because security is a very confusion area and because there are many pieces of technologies that inter-work with other pieces.
IDN: Will there be a WS-I Basic Profile, so to speak, for security?
Van Roekel: WS-I's charter is to deliver what are called 'Profiles.' 'Basic profiles' means just that "The basic layer" SOAP, UDDI,, WSDL layer the basic stuff. There will then be a security profile and then a 'this' profile and a 'that' profile.
IDN: And the WS-I work comes at the end of the standards process, not in the middle of it? Is that the best way to get web services security projects going?
Van Roekel: With WS-I you have this model where (a) the community, (b) a standards body and (c) WS-I all have been working in stages on interoperability of [a] security [standard]. Interoperability happens in multiple places. So, looking at it this way, I think there are three groups that owe themselves to working on interoperability.
IDN: Is that the scenario for standards moving forward? That interoperability between what may look like different approaches will be worked out by WS-I?
Van Roekel: At WS-I, first a specification will initially be published, and there will be lots of community effort workshops, and things like that. WS-I is always going to be downstream of the standards bodies to take interpretation of specs and say, 'Here is a way to implement them that will promised interoperability.'
IDN: Will WS-I's approach to security also follow the approach used for Basic Profile, where you'll issue sample code, templates and usage scenarios for developers?
Van Roekel: I would assume so. I think that [packaging] approach is going to be a Best Practice that's followed by the WS-I for a long time.
IDN: Let's talk about the WS-I terms of engagement. Are you concerned this 3-stage approach by WS-I, could delay availability of technologies?
Van Roekel: I don't think so. I think in all stages of this process there will be implementations that developers can get their hands on and start working with, and those implementations will keep pace with work that's going on in those space.
As an example, Microsoft in August before OASIS had even met for the first time, had a development tool available on their website that would allow a developer to implement WS-Security. That tool is being revved now because things have happened in OASIS. Microsoft keep pace with things that are going on out there, and I think the broader community will do the same. Once a spec if through the [standards] process, WS-I will then tackle that spec for interoperability and that will put the technology into mainline development by making it easier for vendors to add that technology to their tools.
IDN: So, would you say the WS-I's 3-stage process was important to giving competing (and non-interoperable) .Net and Java vendors the confidence to build SOAP tools and adopt the technology in their products when they did?
I think that's right. I don't want to discredit the standards body. But, [SOAP] is another example of the 3-stage approach I've described and it's effectiveness.
IDN: But security is much more complex. Isn't it possible that if WS-I's work only kicks in mainly at the end of a standards process that WS-I could inherent certain standards that are too vague -- or too vendor-specific -- to 'promise interoperability'?
Van Roekel: Well, usually what happens is that specs haven't left the standards body that is working on them in time for WS-I to go and say, 'Here's how we will interpret this profile.'
IDN: So, how would WS-I cope with that?
Van Roekel: Luckily enough there's enough people in WS-I, and enough people in working groups and tech committees that overlap with one another that I think that won't happen. The vendors that are in WS-I will go back and do the work required in the standards bodies to get the specs they are working on up to speed and provide us something that can be interoperable.
IDN: Seems like a developer -- and even vendors -- might think that's a bit risky?
Van Roekel: What web services is showing us is that flux is good. A lot of what we're doing at WS-I is a 'shaking-out' process to get a lot of people to implement technologies and figure out how they will work together and what will work for different scenarios. That is all good.
IDN: Really? You don't see that process as delaying developer adoption?
Van Roekel: In the past, developers typically had to do the same process, but they had to do it largely on their own -- at their own expense. Then, a developer typically had some vendor that specialized in just one particular thing, but that one thing didn't really represent a full solution for the developer.
IDN: Like with security?
Van Roekel: This happened a ton in the security world. A vendor would say I'm going to solve 'blah' and then it would implement some random spec that totally addressed a good answer for that particular thing. But that part then broke another important thing a developer might be working on -- like 'reliable messaging' or 'transactions' or anything else like that.
III. One Proposed Roadmap for
Interoperable Web Services Security
IDN: So with web services, are you saying this "proprietary pieces" approach to security will start to go away?
Van Roekel: I believe that large vendors will take a holistic view. Large vendors, like Microsoft, IBM, Oracle and others have got hundreds of millions of people out there that are going to utilize their technologies for all kinds of different scenarios. So, we want each of these different scenarios to factor well with the others that are out there.
IDN: Do you have an example?
Van Roekel: When we built WS-Security we asked, 'What kinds of new identification assertions will be out there in the future?' and ' How can we architect this for hooking SAML in or Kerberos in or even hooking some future technology that doesn't exist today.?'
We then asked the tougher question: 'How do you then architect security so it works in a great transacted environment or a great Business Process environment or a great reliable messaging environment?' We also asked: 'Where these are going to be very long running transactions?'
IDN: Why would you ask that?
Van Roekel: A web browser is used to running over the course of minutes to work across the web, reliable web services should be able to run days -- if not weeks. You should be able to go off line with it for a while, and come back into the process and have the process continue to live. You have to think about those different scenarios in the way you factor it in. A lot of vendors who can quickly implement solutions typically just built some monolithic solution, but one that didn't factor with the rest of the environment.
IDN: Talking about a basic layer for web services traffic, is there also a layering picture or schematic for securing web services? If so, what does that look like?
Van Roekel: At Microsoft, I work very closely on WS-Security, so as a MS employee I'm very jaded (laughs). But, I think our solution is actually quite good and I think the industry is showing it is one of the best solutions out there.
IDN: WS-Security is taking on the appearance of a secure suite, or a multi-layer model for security, like the OSI model. Is that a reflection of how WS-Security will 'factor' with other approaches?
Van Roekel: What WS-Security does, and I think this is what needs to happen in a secure suite, is at the very basic level WS-Security does encryption and digital signature support. So, WS-Security allows me to encrypt the message when it moves across the wire and it also allows me to digitally sign the message to guarantee that it hasn't been tampered with as it traverses the public Internet.
On top of that, you then need two more layers; (1) a 'policy' layer and (2) a 'federation' layer.
IDN: What would they do?
Van Roekel: A policy layer allows me to denote policies that I want people to adhere to when we're transacting messages across the Internet. So, a policy might be something like, 'To do business with me, you must be using Kerberos, you must digitally sign every message, and you must use this level of encryption.
I can also do other policies. We've built policies [in WS-Policy] to be very sensible, so you can invoke privacy assertion: I want you to guarantee this certain level of privacy, and if you use this certain bit level of encryption, I will guarantee you this level of privacy protection on the info we're exchanging, for example. So you can up-level things and down-level things; it's a very extensible sort of architecture.
IDN: And would that approach support allow a policy to be message-specific?
Van Roekel: Microsoft has also delivered a spec called Policy Attachments that basically [provides] a framework for attaching your policy along with the message as it transverses the Internet. So, in case the message goes to an intermediary you can continue to enforce your policy. If they don't adhere to your policy, the message is discarded.
IDN: And where are those specs going to be submitted?
Van Roekel: We have published it, and it is out on the MSDN website to download and look at. Right now, we're doing the community and workshop. Going back to our 3-phase standards process, we're still in Phase I.
IDN: You also mentioned a "federation" layer? What would that do, and where is that now?
Van Roekel: Federation allows me to secure a conversation. When you and I are doing business with each other we should establish a security protocol or handshake at the beginning of the conversation. But then we should be able to establish that we have a secure conversation from that point on , and not have to re-authenticate.
Other federation things would be like if you're using PKI and I'm using Kerberos, we should be able to go through an intermediary to do business, who could do the protocol translation for us. Or, we should be able to up-level to a common protocol Federation would allow me to do that. We know everyone is not going to go and say OK now that web services are there, everybody go do Kerberos. So, you have to have solutions that accommodate each users' internal systems.
IDN: Do you expect some of the controversies of WS-Security to abate this spring? Are you happy with the progress WS-Security has made to show it can factor with other technologies, such as SAML, NetWare and Sun's directory service?
Van Roekel: There has been a lot of progress there. First, Sun joined us in taking WS-Security to OASIS last year. Also last year, the SAML people got up at The Burton Group's Catalyst Conference, said they were going to take on WS-Security as a way of manifesting SAML into SOAP, so that was a huge thing there. And, there has been lots of work going on relative to just plugging in all kinds of different protocols using WS-Security as a mechanism to put into a SOAP message. So it's actually quite rich the momentum is going on.
IDN: What about any overlap or factoring between different identity scheme, like the Liberty Alliance and WS-Security?
Van Roekel: When you think about all those things having to do with identity, like Microsoft Passport, Liberty Alliance and SAML, Kerberos and X.509, we had architected WS-Security to be extensible to be able to utilize all those elements. It's quite rich in that way. I'm pretty sure that WS-I will take a look a WS-Security as a way of doing that.
IDN: What about how WS-Security, or other web services security schemes, should work with legacy security approaches? Is there enough work to begin brokering between those two worlds?
Van Roekel: A huge piece will come with the delivery of the policy piece; and the other big piece that needs to be delivered is the federation piece. We haven't delivered those specs yet. That's when we start getting into the world of real interoperability between the different kinds of security approaches.
IDN: So, in some aspects of security do you think we can avoid some of the "War by Press Release" we've seen on some standards fronts lately?
Van Roekel: I think 2003 really going to shape out to be the year of interoperability and agreement between web services. You'll still see some changes here and there, I'm sure, because different vendors want to do different things. But, it's typically those vendors that are taking a very narrow view. We're doing our job to get people to think holistically about security and other end-to-end issues.
IDN: Early on, as you infer, there will certainly be hybrid environments, right.? So, what do you see happening there?
Van Roekel: I would imagine what you'll mostly see is the server-to-server or B2B deploying quickly and the client access applications, like browser based or rich client applications, will probably take a little bit longer on the legacy side.
In hybrid environments, I can use straight SAML, straight Java, straight VB script on the client end talking to the backend server. But, when the servers are running around the Internet grabbing information from one another, they'll be using web services.
IDN: Then what?
Van Roekel: As the other pieces evolves, there should start to be plug-in or migration solutions. We at Microsoft, for instance, are evolving Office, Passport, BizTalk and all these other things to support web services you'll see that start [show] up on the client end even more.