A Developer's Roadmap to Using WS-Security
This week, WS-Security, one of the core building blocks for interoperable web services security, was adopted by OASIS. To help devs understand what the adoption of WS-Security might mean to their business -- and career -- IDN spoke with the WS-I's Steven Van Roekel, who details how developers can use it, what cross-platform features exist and are planned.
WS-Security, one of the core building blocks for interoperable web services security, was adopted this week by OASIS.
The action means that devs and IT managers could start seeing XML-based security solutions start cropping up in all sorts of enterprise products, from IDEs, to firewalls and even front-end UI designs and back-end servers. It also means that Microsoft, Sun and IBM continue to find more reasons to cooperate, rather than bicker.
To help devs and senior technicians understand what the adoption of WS-Security might mean to their business -- and career -- IDN takes as a look at how developers can best begin to leverage WS-Security technologies, as we conduct an in-depth conversation with Steven Van Roekel, Microsoft's Director of Web Services Technical Marketing, and a leading member of the WS-I's (Web Services Interoperability Organization's) push to implement tools and testing assistance for developer and ISV use of WS-Security.
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.
First some WS-Security background.
Some Basic WS-Security Background
It's key to remember that WS-Security is one of the first vendor implementations of the new W3C standards for XML Encryption and XML Signature.
Also, this week's adoption of WS-Security by OASIS follows the WS-I's issuance in February of its Security Scenarios, which is part are based on original WS-Security work.
WS-I's Security Scenarios document describes several security challenges, threats and countermeasures in building interoperable Web services, as well as usage scenarios and solutions. Among the topics profiled in the WS-I document are:
Â· Challenges: describes several security challenges, including ensuring data integrity, data confidentiality and message uniqueness
Â· Threats: outlines 10 threats on these challenges, such as message alteration, falsified messages, message replay and denial of service attacks
Â· Countermeasures: recommends how technologies like HTTPS and OASIS Web Services Security: SOAP Message Security 1.0 can be used to counter some of these threats
These Usage Scenarios and Solutions describes how these technologies can be used with the Message Exchange Patterns (MEPs) that have been used in WS-I deliverables such as the Basic Profile 1.0 Sample Applications, and suggest how devs might use WS-Security (and higher level security proposals, such as WS-Policy, etc.)
Now, read the interview.
Steven Van Roekel, WS-I Member and
Director of Web Services Marketing
I. WS-Security--Origin of 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.
And, then there [was] a lot of progress [among other vendors]. First, Sun joined us in taking WS-Security to OASIS. Also, 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.
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: 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 the W3C's 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: [Did] that support 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: There had been some special controversy over SAML early in the process. 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: 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. 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?
Van Roekel: 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 might the 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.
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 within web services, [now that there is an OASIS approval of WS-Security], 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 Microsoft 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.
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: 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 [WS-P]olicy piece; and the other big piece that needs to be delivered is the federation piece. 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: 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.
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.