WS-I BSP 1.0 Sample Application
If you are interested in Web Service security and interoperability, stick around and bear with me on a series of posts that I would like to start writing, telling you about my experiences on this field and what we’ve learned along the way, dealing with all these emerging technologies. Introduction In the last months I was working on the Microsoft's implementation of the WSI BSP 1.0 Sample Application project. In a nutshell, this is a kind of “real-life” sample (actually a simple SCM or Supply Chain Management application) that describes how the application implements the requirements of the WS-I BSP 1.0 using various architectural patterns in the design of the application, and shows how the security configuration of the application can be specified declaratively by implementing the functionality within Microsoft Web Services Enhancements Toolkit (WSE 2.0). Note: (Downloads in GDN Workspace and check the MSDN page as well – available soon) Here is a list of the main topics that I would like to explore that may help us in a walkthrough of this project.· A brief description of the project context and its relation to standards and organizations.· Main topics of the project architecture.· Interoperability Issues found and how to design for them.· Examination of the WS-Security implementation and specially the area regarding to WS-Policy The last point is where I’ll put the main focus and the area in which I’ll dive into some hopefully useful extensions (refer to Custom Assertions) that may solve some of the most common issues found in these kind of applications.
Note: A good place to start reading about these specifications is the Web Services Specifications Index Page. If you are new to the use of WSE to secure Web Services, you may want to read a couple of introductory articles like this and this. Now let’s move on with the first topic and take a quick look into the standards that should meet this application. The Web Services-Interoperability Organization (WS-I) Now may of you may be asking what is WS-I BSP 1.0 (you may already guess the WS part) and what has to do with security and interoperability.If you already know all about this stuff, feel free to skip the following paragraphs and go ahead to the next section. Now lets start saying that the Web Services-Interoperability Organization (WS-I) is an open industry organization that promote Web Services interoperability across many technology substrates (platforms, OSs, languages, etc.). However, achieving true interoperability between the current heterogeneous techno-universe has been close to impossible or in the best scenario, a very tough task. This may be in part because of a lack of a well established collection of standards (the nowadays ever emerging and evolving standards facilitates this) and on the other hand caused by a pragmatic guidance and “real life” reference implementation that show you how to apply all these standards to the different platforms and languages provided by the mainstream vendors. Back to the WS-I, their key deliverables are:
- Profiles - provide implementation guidelines for how related Web services specifications should be used together for best interoperability.
- Testing Tools - used to determine whether the messages exchanged with a Web service conform to WS-I guidelines. These tools monitor the messages and analyze the resulting log to identify any known interoperability issues.
- Sample Applications - demonstrate Web services applications that are compliant with WS-I guidelines.
These implementations are developed using multiple platforms, languages and programming tools, demonstrating interoperability in action, and providing readily usable resources for the Web services developer. The WS-I also produces supporting documentation in conjunction with each of these deliverables.
The WSI Basic Security Profile The Basic Security Profile specifies how the OASIS WS-Security specifications should be interpreted to increase the likelihood of use of WS-Security in an interoperable fashion. It builds upon the WS-Security specifications, WS-I Basic Profile 1.1 (BP 1.1 – provides guidelines to help developers build interoperable Web Services) and the Simple Soap Binding Profile 1.0 (SSBP 1.0 – provides guidelines on how to serialize SOAP messages over HTTP). The WS-I also produces supporting documentation in conjunction with each of these deliverables.Note: For further info see: Building Interoperable Web Services: WS-I Basic Profile 1.0 or see here. Enter the Basic Security Profile Sample Application Before start delving into the fine details of the application, let me state the following advice that you will find in the application documentation as well;
Note: The version of the sample application accompanying the final release of BSP 1.0 is expected to be implemented using Visual Studio 2005 and WSE 3.0. However, at the time or writing, the BSP 1.0 is not finalized. In the interim, Microsoft has produced a preview release, implemented using WSE 2.0 SP3 and Visual Studio 2003. This release is not an official deliverable from the WS-I. Instead, it is intended to provide Microsoft customers early access to guidance around securing interoperable web services.
So the idea behind this first glimpse of the project would be to provide emerging guidance on the BSP 1.0 Sample Application preview release.Now let’s start with some general comments about this application. The first thing to note is the fact that we used a contract-first implementation approach (WSCF), starting with the XSD and WSDL driven by the BSP 1.0 spec.In many ways the security implementation is also implemented contract-first – where the security policy is defined up front (in the form of policy statements) and then applied to the code, shielding the application developer from having to implement (or even participate in) security plumbing. Here is the part where we’d unleashed all the potential that WSE 2.0 provides with the WS-Policy implementation that we’ll discuss on the following sections (or posts).Architectural DetailsThe functional requirements for the original WS-I Sample Application can be found in the Supply Chain Management Use Case Model, which describes a simplified Supply Chain Management (SCM) application spanning several fictitious organizations – namely a Retailer, a series of warehouses and a series of manufacturers.The sample application uses the scenario of a retailer selling consumer electronics. The retailer has to manage stock in three warehouses, first checking Warehouse A. If Warehouse A can't fulfill an order, the retailer then checks Warehouse B, and if Warehouse B can't, it checks Warehouse C. When a warehouse's inventory of a particular product falls below a certain threshold, the warehouse orders more units from the appropriate manufacturer. There are three manufacturers.I don’t want to extend explaining all the low level details regarding specific architectural areas like patterns used and all the nifty grifty details because the main focus of this article is centered in the security aspects and how it fits the interoperability requirements. I will say that we used several blocks included in Enterprise Library and it does includes the sources of these blocks with the lates pathes so you may be able to step through the code end to end.Security RequirementsA comprehensive description of the security requirements, analysis and implementation that form the basis for all implementations of the BSP 1.0 Sample Application is currently being developed by the WS-I Sample Application Working Group. The BSP 1.0 Sample application uses a Trusted Subsystem security model. It uses fixed identities to represent each entity (the Retailer, each Warehouse and each Manufacturer). Downstream services are responsible for calling the WebClient that authenticates the original user.Authentication between tiers of the application uses X.509 certificates, with a UsernameToken flowing the identity of the originating users from the WebClient to the Retailer services. This UsernameToken does not include the originating user's password, as the Retailer web service trusts the web client to authenticate the originating user. Policy usage in the Sample Application In this section we’ll start to analyze one of the most interesting areas of the Sample Application regarding the implementation of the aforementioned security requirements. As we said before, the use of WSE and its implementation of WS-Policy let the developer to apply this requirements in a declarative way (in a “simple” configuration file) a therefore decoupling the service and business logic to the cross-cutting concerns (security constrains) in a “clear-cut” flexible approach. Another important point to notice is the extensibility mechanism that WSE supports by implementing WS-PolicyAssertions, allowing custom requirements to be defined as extensions to the WSE Policy Framework and reused by all applications. These extensions are called Policy Assertions and we’ll further examine them in the following section.An interesting question may arise regarding the policy exchange mechanism between both parties (a service and its consumer) and how each one knows the policy requirements of the other before starting to send messages one another. A broader agreement might be reaching around the implementation of WS-MetadataExchange specification that will use each endpoint metadata as the exchange material. However, until there is a general agreement on a standard implementation of policy and its interchange protocol, web services need to communicate their security requirements to calling applications out of band. The members of the WS-I BSP 1.0 Sample Application Working Group chose to use a design document to capture and communicate each services security requirements. This design document will be made available through the WS-I later this year (2005).
Note: A useful tool that helps in building the policy (metadata) files is the WSE Policy Advisor, an unsupported tool from Microsoft Research that examines policy files and generates a report to make security recommendations. Policy AssertionsA policy assertion is an individual preference, requirement, capability, or other general characteristic. WS-SecurityPolicy and WS-PolicyAssertions are specifications that define standard sets of policy assertions that can be used within a policy expression. WS-PolicyAssertions and WS-SecurityPolicy define some standard assertions that address the common needs of Web services applications. The Web Services Enhancements for Microsoft .NET (WSE) has built-in support for the following policy assertions: · SecurityToken – this assertion specifies which kind of security token should be used. It is part of WS-SecurityPolicy.· Integrity – this assertion specifies that a message should be signed. It is part of WS-SecurityPolicy)· Confidentiality – this assertion specifies that a message should be encrypted. It is part of WS-SecurityPolicy.· MessageAge – this assertion specifies the age limit of a message. It is part of WS-SecurityPolicy.· MessagePredicate – this assertion is used to ensure that messages conform to a given assertion. It is part of WS-PolicyAssertions.Custom Assertions We’ll see along the following posts several custom assertions that extend the current WSE built-in policy assertions in order to meet most of the security requirements that the WS-I BSP 1.0 Sample Application has regarding the WS-Policy and the latest OASIS Standard specifications. The following custom assertions extend the Integrity and Confidentiality WSE built-in assertions, and add some other additional functionality.· ConfidentialityEx - extends the built-in Confidentiality assertion functionality and permits to encrypt the Signature element and any other custom header as well.· IntegrityEx - extends the WSE Integrity built-in assertion and by allowing signing the security tokens that are included in a message.· FaultLogging - catch all the security and policy exceptions as well as any other SOAP client fault and log it to the local application event log. Among these custom assertions, we’ll see another interesting addition to this project and this is the X509SecurityTokenManagerBroker, a class derives from the X509SecurityTokenManager WSE built-in class and adds the functionality to selectively take a specified security token (X509SecurityToken) upon configured rules for token selection for integrity and confidentiality assertions. This manager will usually operates on outgoing messages that will need to choose among several SecurityTokens that will be used to sign (integrity) or encrypt (confidentiality) the outgoing message (requests on the sender side or responses on the receiving side). I got the feeling that this post is getting quite long so I propose you to continue with the second part of this series where we’ll start to dissect each of these custom assertions along other interesting things that we found like dealing with null or empty SOAPAction values and other issues the like.Feel free to send me your comments and ask me your questions about this project or some of the topics that I’m presenting here.
Disclaimer.