Tag Archives: BSP

WS-I Publishes Basic Security Profile (BSP) 1.1

This morning the Web Services Interoperability Organization (WS-I) published the Basic Security Profile (BSP), version 1.1. This is a very significant milestone, because BSP is the definitive reference that we will all use to create secure and interoperable Web services for the foreseeable future.

I have a close personal connection to Basic Security Profile. I was one of the editors of both this specification and its predecessor, BSP 1.0. It took a lot of hard work to get this far, but the results of the our working group’s labours are important for the community. We all use Web services because of their potential for interoperability, but interoperability is only practical with the formalization that WS-I offers.

People have questioned the need for BSP in a world that already has OASIS WS-Security and the handful of WS-* standards that relate to it. The truth is, formal standards like WS-Security are so broad, complex, and new that it just isn’t realistic to expect vendor implementations to integrate perfectly. The WS-I approach differs from conventional standards efforts because the focus is strictly on promoting much needed interoperability. WS-I does not define new functionality, nor does it attempt to show people the “correct” way to use existing standards; it exists to profile existing standards by refining messages, amplifying important statements, and clarifying ambiguities so that systems from different vendors can communicate securely.

WS-I promotes interoperability by providing three important components: a profile of an existing standard (or set of standards), a suite of test tools to validate conformance, and finally sample applications. Microsoft’s Paul Cotton, the chair for the BSP working group, likens this to a three-legged stool—the effort can only stand when all three legs are present. This holistic approach taken by the WS-I distinguishes it from most standards efforts by including both specification and reference.

In the case of BSP 1.1, a very important component of the effort was the vendor interop. Six companies participated in this:

This is your short list of the vendors who are serious about Web services security. Obviously, we are the odd man out in terms of size and market reach, but we believe it’s important to drive the standards, not just implement them. And this is something we will continue to do. The days of big WS-* standards efforts are over. With the release of BSP, we have what we need to secure SOA. The next big challenge will be standardization of the cloud, and Layer 7 will be there.

Randy Hefner on the State of SOA Security

Randy Hefner wrote an encouraging piece recently in ComputerWorld titled SOA Security: Good Enough and Getting Better. I say encouraging because from his perspective—which is broad and well-informed by virtue of his role as a Forrester analyst—most organizations now understand the importance of SOA security, and they are implementing the basics today. The more advanced pieces, particularly around complex identity-centric use cases such as single sign-on and federation, remain elusive; but at least there is a solid baseline to work from. Randy maintains:

“Thus it is important, even if you start with a simple SOA security solution, to anticipate the need for and leave paths open to build additional, deeper security functionality as business requirements demand and SOA security maturity allows.”

This is something I definitely agree with. Security can begin with the basics, as long as you put the time and energy into your basic policy and security architecture upfront. If you design it for growth, you can easily add in support for scenarios like non-repudiation later on. Security should always be an iterative process. It’s something you never finish, and you need to keep this in mind as you are designing your security architecture. You don’t want your tools and infrastructure to let you down at some point in the future.

But Randy’s real gem is here:

“Forrester strongly recommends that you design a solution that does not require application developers to do security-related coding. Even with strong guidelines and code reviews, embedding security into application code is risky both in terms of achieving consistent security and of allowing future flexibility and enhancement of application security.”

Bravo Randy—and Forrester by extension. This is the critical insight that so many people miss. Here at Layer 7, we’ve been evangelizing for years that developers need to be taken out of the equation when it comes to securing the communications that make up a secure SOA application. SOA security is a complex discipline, and it’s risky to assume that each of your development teams will implement it consistently and correctly. You need to dedicate an expert to the problem and make this person (or persons) responsible for implementing a security model across all of your SOA apps.

The fundamental associated risk with standards like WS-Security (WS-S) is their complexity. This is a very broad specification, one that relies on a host of other specifications as its core. By design, it is not prescriptive about how you should use it; rather, it is a framework for securing SOAP transactions to your business needs.

I was (am still am) an editor of the WS-I Basic Security Profile (BSP), along with colleagues from IBM, from Nortel, and from Microsoft (a number of other companies also contributed to the specification as participants in the working group). I’ve worked alongside the best SOA security minds on the planet, and I learned first hand how easy it is to inadvertently create WS-S (or, for that matter, BSP)-compliant security models that are riddled with holes. OASIS and WS-I, through the standards and profiles they produce, do not have a mandate to offer formulas for securing SOA apps. They are in the business of providing frameworks for experts to implement secure solutions, or to promote interoperability.

This is why it’s so important that security for SOA be placed in the hands of dedicated experts, and that the tools to support an overall governance strategy—such as Layer 7 SecureSpan Gateway line—allow security policies to be enacted simply and comprehensively. I’ve always said that the soul of good security is consistency. Your tools need to support this.

In a forthcoming blog entry, I’ll demonstrate how simple it is to implement SOA security using Layer 7’s SecureSpan Gateways, and thus deliver on Randy’s assertion that we must take application developers out of the SOA security process.

SecureSpan Gateway Cluster deployed in a common, edge-of-the-network scenario. This is just one example of many different deployment possibilities. Here, the gateway cluster provides consistent security policy enforcement for all services published by the organization.

SecureSpan Gateway Cluster deployed in a common, edge-of-the-network scenario. This is just one example of many different deployment possibilities. Here, the gateway cluster provides consistent security policy enforcement for all services published by the organization.