When IBM, Microsoft,
and VeriSign announced in July 2002 that they planned to move their
proposed WS-Security standard to the OASIS group, they had successfully
convinced Sun Microsystems to join the effort, and thus avoided a potential
prolonged dispute over how to add baseline security -- things like encryption
and digital signature support -- to Web services. But there is a lot
more to it than just baseline security. This could be the beginning
of a major step forward for webservices.
For enterprises making big commitments on XML webservice based application
architectures, there are some important issues that have been put on
WS-Security should �have broad support among actual
WS-Security does not answer all the security needs for
XML-based Web services
Additional specifications may now come from OASIS, not
necessarily W3C. OASIS may be replacing the W3C as most important Web
services standards body.
There is now an opportunity for WS-Security to play
well with Secure Assertions Markup Language (SAML).�
Let's take� a look at these issues:
WS-Security : a broad security standard
The addition of Sun to the "big player list" was an important
step forward, and is likely to have a ripple effect as more players
decide to finally jump into the webservices pool. Getting everyone around
the same table will be good for the entire industry.
Besides Sun's backing of WS-Security is the fact that most mainstream
security vendors -- the big players that will actually deploy and support
the specifications -- are already firmly in the WS-Security camp. In
addition to VeriSign, security-oriented vendors such as Baltimore Technologies,
Entrust, Netegrity, RSA Security, and Novell are WS-Security backers,
and they will be involved in creating more security standards at OASIS.
Many of these vendors have also been behind SAML, a key standard for
enabling cross-platform single sign-on.
What Does WS-Security Do?
WS-Security's goal is to specify how to secure Web services -- including
encryption and access control -- in a platform-independent manner. It's
generally accepted today that security is the key driving force -- and
the biggest bottleneck -- in the deployment of Web services by enterprise
customers. �By using the SOAP extensibility model, SOAP-based specifications
are designed to be composed with each other to provide a rich messaging
WS-Security defines a set of SOAP headers that can be used to implement
security measures for Web services. The WS-Security specification describes
how to add encryption and digital signatures to Web services (in each
case supporting the W3C's XML-Encryption and XML-Signature). WS-Security
also defines a general mechanism for passing around security tokens.
These are the foundations of a standardized, industry - wide SOAP security
The goal of WS-Security is to enable applications to construct secure
SOAP message exchanges. The Web services security language must support
a wide variety of security models. The key driving requirements
for this specification are:
At this point, WS-Security and SAML work together: WS-Security defines
how you insert the information into a SOAP envelope, and SAML defines
what the security information is.
The overall thrust with WS-Security is to build a "security stack"
in a manner similar to the way the industry built a basic Web services
protocol stack with XML Schemas, SOAP, WSDL, and so on. This concept
of simplifying and consolidating Web services security efforts is also
a key force behind WS-Security.
WS-Security: Room for improvement
WS-Security is flexible and is designed to be used as the basis for
the construction of a wide variety of security models including PKI,
Kerberos, and SSL. Specifically, WS-Security provides support for multiple
security tokens, multiple trust domains, multiple signature formats,
and multiple encryption technologies.
As presently composed, WS-Security is not the "end all",
but only a start, and the three main supporters -- IBM, Microsoft, and
VeriSign -- are aware of this. When they kicked off the WS-Security
effort in April, and again when they moved it to OASIS, they emphasized
that they planned to deliver a much broader architectural plan for Web
services security.� Microsoft's Global XML Web Services Architecture
(GXA) is how their version of this vision is laid out.
The partners, who now include the larger OASIS working group members,
are working on specifications in six other important areas.� Of course,
there may be some combination and consolidation of these as time goes
on. The six proposed specifications come in two major areas, policy
which is a general purpose spec describing how to express enterprise
WS-Trust, which defines brokered trust relationships
a Web services environment.
WS-Privacy, which defines a way for Web services
to state and implement privacy preferences and practices.
which defines a general method for managing and authenticating message
exchanges between parties.
WS-Federation, which describes the management and
brokering of trust relationships in a heterogeneous federated environment,
including support for federated identities.
WS-Authorization, which defines how Web services
manage authorization data and policies.
Backers of WS-Security believe that these are the key technologies required
for the provision of a secure Web services architecture. We can expect
to see formal, written specifications for each of these areas by the end
of the year 2002. Once that is completed, the OASIS working group handling
Web services security will work to put all these facets together.
�The W3C and Standards
There appears to have been a shift in power among standards bodies.
The bureaucracy of the W3C is increasingly frustrating many players.�
So while the W3C will continue to hold an important influence over most
core Web standards like XML, the OASIS organization has now moved into
a dominant role in developing and promulgating standards, at least insofar
as webservices security is concerned.
WS-Security and SAML
SAML is a specification which defines a standard, XML-based approach
for passing security tokens defining authentication and authorization
rights. Originally, SAML was targeted more toward distributed authentication
and single sign-on. But those concepts are also central to Web services,
and with both SAML and WS-Security now domiciled at OASIS, some integration
and change is likely to be seen. The two security approaches should
be able to work together and eventually give enterprises some quality
choices about how to secure Web services.
SAML has already adopted WS-Security as the appropriate method for "binding"
SAML assertions into SOAP messages. Version 1.0 of SAML came up to a vote
in July 2002; it is expected to be approved as standard by fall 2002.
SAML 1.0 won't include a formal SAML-over-SOAP definition in its first
iteration, but you can expect future versions of the SAML spec to adopt
WS-Security is a major extension to the concept of the SOAP envelope
header. With WS-Security you can use any security token you want. WS-Security
is the messaging language; SAML is the security language.� These two specifications
should work together very nicely. The bottom line for developers is that
we now have a stable foundation emerging that allows us to forge ahead
with plans for an extensible, standards-based webservice architecture
in our applications, and to be reasonably confident that this foundation
will remain solid and dependable.
|Peter Bromberg is a C# MVP, MCP, and .NET consultant who has worked in the banking and financial industry for 20 years. He has architected and developed web - based corporate distributed application solutions since 1995, and focuses exclusively on the .NET Platform. |