In-Depth

Integrate SOA Portals With WSE

Effective policymaking with WS-Policy improves your architecture's adaptability with minimal development when external service interfaces evolve and business needs change.

• By Derek Harmon
• 10/01/2005

Technology Toolbox: Visual Basic, C#, ASP.NET, XML, WS-Security, WS-Policy, Web Services Enhancements 3.0, Visual Studio .NET 2005

The service-oriented architecture (SOA) buzz around the industry comes from a groundswell of experience with enterprise application integration and the promise of Web services to fulfill the promise that SOM, COM, and CORBA never fully realized. Yet the advantages of using SOA aren't always plain to see until you need to pull together different services. I'll lead you through the design of a human-resources hiring portal that highlights patterns for successful SOA. I'll show you how to apply the portal integration pattern to aggregating Web services using the ASP.NET 2.0 Web Parts framework and Web Services Enhancements (WSE) 3.0.

Imagine a hypothetical staffing firm, ABC Staffing, responsible for placing educators in schools nationwide. After interviewing a promising candidate, an ABC employee must review that individual's references and licenses. This includes checking teaching credentials, university attendance and grades, and the existence of any criminal history. As you might imagine, this information comes in many formats and through many different providers.

Let's assume ABC Staffing achieved schema independence from the variety of record formats used by state agencies, universities, and law enforcement by selecting the HR-XML vocabulary to represent background reports in a single unified format. By choosing a widely adopted schema within your industry, the number of service providers you can build upon grows (see the sidebar, "Apply HR-XML," for more information on HR-XML applications). ABC Staffing has committed to a portal application for its hiring managers that pools together background reports received from several providers. As time goes by, new providers may replace old providers, so the solution needs to be easily reconfigurable.

The success of SOA relies upon a service-oriented marketplace, so let's focus on aggregating external services. In the ideal free market, countless providers sell interchangeable services, fair competition abounds, and there are no barriers to entry. Web services provide specifications regarding interoperability, identity, and policy for services based on industry experience.

Even without following these ideals, it's possible to aggregate a service building only upon services you have control over and that never leave the boundaries of your department. For instance, you can build internal services using domain accounts for authentication and Kerberos delegation to traverse intermediaries. However, this approach suffers from short-sightedness because it dresses Web services in many familiar trappings (and pitfalls) of Windows Distributed InterNet Architecture (DNA).

The reality is that all services evolve over time. You get greater flexibility over time by designing the solution to permit substitution of service providers. The service architectures you build with this flexibility in mind fit intranet or extranet situations equally well.

WS-Security: A Principle Cornerstone
Web Services Security (WS-Security) is one of the principle cornerstones of Web service specifications. The digital signature portion of WS-Security tells you that messages are from who they claim to be from (they are authentic). It also tells you messages have not been tampered with since they were signed (their integrity is assured). These two qualities indicate that the architects of Simple Object Access Protocol (SOAP) at the World Wide Web Consortium (W3C) and Organization for the Advancement of Structured Information Standards (OASIS) made security a fundamental value. Following the best security practices promoted by WS-Security helps you secure your applications more easily, although this doesn't mean security should slip your mind.

WS-Security includes encryption, which helps you keep the content of messages confidential and away from prying eyes. However, encrypting whole messages also defeats some benefits of service aggregation, so you should take this trade-off into consideration when you encrypt something.

Let's say you want to request a background check by sending your service provider confidential information identifying a job candidate, such as his Social Security Number (see Figure 1). This field is sensitive and should be encrypted from intermediaries, but what about other parameters regarding your query about this individual? Should your request encrypt a list of universities and colleges attended by the candidate? Are these parameters a matter of national security?

Encryption is not always the best answer. At some point, the systems at your service provider might need to decrypt and use the Social Security Number information. At the same time, it's possible for service providers to dispatch other portions of your background check (such as a flag indicating that you're interested in validating the candidate's current mailing address) when those parts of the query do not require sensitive information. Separating steps or referring them to another service provider increases the flexibility within the SOA. This chain of aggregation and reuse in services becomes possible only when you use encryption for protecting fields containing sensitive data, and not for the entire message.

You still want to prevent eavesdroppers on the wire, but there are many ways to do this in a networking environment. For example, instead of paying in performance and public key management for encryption of the message within your application, you can use virtual private network (VPN) solutions that provide encryption of all communications. When a VPN is part of the communications network you're building a SOA on top of, ask yourself if you'll benefit from a second layer of encryption.

You might ask why you can't simply rely on Secure Sockets Layer (SSL), Transport Layer Security (TLS), or some other transport-level security scheme. SSL will suffice if you're going to communicate only with a single fixed end point. However, how much do you really know about what goes on behind that end point? Is it (or will it someday become) only an intermediary that delegates work across other services? When your requests must make multiple hops across the network, the benefit of SSL diminishes because it secures only the first hop.

WS-Security adds information, such as its signature value, into the headers of your message. This information is carried across intermediary nodes until the request reaches its ultimate end point. Any tampering by an intermediary invalidates the message, so an intermediary cannot change the signed parts of the message.

WS-Security supports several forms of tokens to identity a Web service client. Choose the UsernameToken if you need only a username and password pair. WSE makes it easy for you to map tokens directly to Active Directory or the domain accounts on your Windows network to perform authorization. The X509CertificateToken contains a certificate that is specific to your identity and host machine and that a third-party trust authority has signed.

Cash Trumps Gift Certificates
Would you rather have money or gift certificates in your wallet? UsernameTokens are like gift certificates. One vendor vouches for their authenticity, in the same way a username and password combination is valid for one service provider's identity store. X.509 is like cash money. Many service providers can validate your identity when they trust the authority that issued your certificate. The number of service providers you can choose from goes up when you authenticate using credentials issued by a trusted third-party. At the same time, the headache of managing separate username and password combinations in your application subsides.

For these reasons, the client X.509 certificate identifying your user (for example, the hiring manager at ABC Staffing) is what you register with your service providers to prove you requested their service (for billing and privacy purposes, these are all of the claims the service providers are concerned about). Authenticating the partner with whom you're exchanging messages is greatly simplified whenever you can offload the burden of trust onto a third-party issuer that both consumers and service providers can count on. Your application sheds itself of the administrative overhead involved with maintaining private identity stores and dealing with trust boundaries in your architecture.

I've spoken a lot about security and by now, you're probably expecting to see a lot of code. This is where WS-Policy comes in. Authentication, encryption, and integrity of messages are design qualities SOA should have, but you don't have to pay for them with a lot of code. This is especially important because your requirements, and the service providers you choose, might change tomorrow.

WS-Policy makes these services configurable. This standard defines the structure of policy configuration files. Place a list of policy assertions about the messages being sent—such as whether they are secure, digitally signed, and/or encrypted—in these files. The client-side policy configuration file for your portal application ensures that every outgoing request message to a service provider includes your client X.509 certificate to identify the request as legitimately coming from you (see Figure 2).

The corresponding policy configuration on the service provider's side insists that all incoming requests have an authentic and valid X.509 certificate, and any that don't return a SOAP fault immediately. Add this capability to your Web service by checking the "Enable Web Services Extensions" from the WSE 3.0 Settings... dialog in Solution Explorer. This checkbox enables the scanning of incoming SOAP headers with extensions registered by WSE and adds this valuable and supportive substrate to a service provider application.

Don't worry if the XML in the policy configuration file appears overwhelmingly complex at first. WSE dialogs guide you through settings important to your client or service provider and produce a proper configuration. You need to know only the answers to the design questions relevant to your application, such as those regarding authentication, integrity, encryption, transport protocol, and so on.

Take a Bird's-Eye View of Your Portal
Your portal is designed to aggregate three background reporting agencies responsible for feeding it information on a candidate's criminal record, educational history, and teaching license status (see Figure 3). The URLs of these end points are set up in your Web services' configuration, so you can change them when business demands warrant. Right now, each provider is implemented as WSE-enabled ASMX Web services retrieving records based on the candidate's name, and each returns a canned HR-XML conformant response.

Between these three services and the hiring manager stands an ASP.NET portal application that integrates separate background reports into a single view. You accomplish portal integration through custom Web Parts (see the sidebar, "Portal Integration vs. Data Integration Pattern," for an explanation of why the portal integration pattern fits best, and when to consider alternative patterns).

Two types of user-interface elements fulfill a Model-View-Controller architecture for this portal. The custom SearchWebPart is the controller responsible for making Web service requests and presenting hiring managers with a list of candidates whose credentials are checked. A variety of specialized ContentWebParts specialize in presenting their view of a portion of HR-XML, which they're responsible for transforming into HTML. The model spans your aggregation of Web services from different providers.

Public methods exposed on the ContentWebParts can receive IXPathNavigable objects representing an HR-XML background report. The methods transform this report into HTML using an XslTransform from the SearchWebPart (controller). In the Web Parts architecture, you express your willingness to receive objects from other Web Parts by annotating a GetInterface method with the ConnectionConsumerAttribute that names the connection between the Web Parts your ContentWebPart wishes to consume. On the other end, your SearchWebPart exposes a ProvideInterface method marked with the ConnectionProviderAttribute that provides objects to the named connection.

Enterprises are turning increasingly to SOA, expecting to deliver greater flexibility and reduce costs. Hopefully I've introduced you to the architectural decisions that go into making a sound, reusable service-oriented architecture that tackles real business problems. Moreover, you have seen the value both WS-Security and WS-Policy provide service architects by securing information and relieving you from building the infrastructure so you can build solid services.