These high-level requirements in turn drive a number of lower-level requirements such as the need for an integrated directory and public-key repository.

Current Solutions
The current state of practice for addressing our high-level requirements is:

While these solutions were successful at addressing the security issues of previous business models, they fail to address the needs of a shared B2B process integration platform in a number of areas.

1.   SSL is a transport-level entity: As such, it cannot be used to protect messages outside the context of a particular transport-level session. SSL also cannot be used to prove the identity of participants (clients or servers) outside the context of a particular transport session. Lastly, since SSL authentication is not valid beyond the life span of the connection, SSL cannot be leveraged to support nonrepudiation.
2.   Username/password authentication It is cumbersome and fragile. Forgotten passwords are the number one source of help desk calls. Weak passwords are the primary source of security breaches.

Recent advances in Web services security overcome these problems and help us meet the four key security requirements we outlined above.

Message Integrity and Confidentiality
The first core security requirement of a shared B2B integration platform is end-to-end message integrity and confidentiality. New protocols and technologies have emerged to address this challenge.

XML-Signature and XML Encryption
Together, the XML-Signature (www.w3.org/Signature) and XML Encryption (www.w3.org/Encryption/2001) specifications - both W3C Recommendations - form the basic building blocks of Web services security.

These specifications relate to signing, verifying, encrypting, and decrypting XML messages. Note that these standards don't define any new cipher suites or signature mechanisms. They apply existing encryption and signature algorithms to XML and capture the results of those algorithms in XML syntax. This last point is important. By working within XML, the XML signature and encryption standards make the results of their operations consumable by XML-aware components. This allows solutions built using XML to add encryption and signature support without having to significantly alter their technology base. This feature is used by the Web Services Security specification to add message integrity and confidentiality to SOAP without having to make changes to the SOAP specification.

In our example, the client side of the purchase order service would use XML Encryption to encrypt the sensitive arguments of the purchase order. The encryption is performed at the business logic level because only the business logic knows which arguments are considered sensitive. The mechanism for signing the purchase order is described below.

Web Services Security
In April of 2002, IBM, Microsoft, and VeriSign jointly published the WS-Security document (www.verisign.com/wss/wss.pdf). This document is part of a larger Web services security architecture detailed in a joint white paper from IBM and Microsoft entitled "Security in a Web Services World: A Proposed Architecture and Roadmap" (www.verisign.com/wss/architectureRoadmap.pdf). The WS-Security specification was accepted as a starting point for specifications being drafted by the OASIS Web Services Security Technical Committee (www.oasis-open.org/committees/wss/#documents).

Like the WS-Security document, the OASIS Web Services Security specifications are about message-level security. Specifically, they define how to use the XML Signature and XML Encryption specifications to add integrity and confidentiality to SOAP v1.2 messages. They also include support for message-level authentication through the various types of security tokens (X.509, Kerberos, SAML, etc.).

Returning to our example, after encrypting a portion of the purchase order document, the purchase order client code invokes the SOAP messaging engine for the purchase order service. Because the purchase order service requires that all messages submitted to the service be signed with the private key of the sender, our SOAP messaging engine transparently invokes the WSS-compliant signing service before transmitting the message. This results in a SOAP message with WSS-defined security headers that contain the digital signature value for the SOAP body along with the X.509 certificate for Trading Partner A. When this message reaches Trading Partner B, the signature can be verified and the identity of the issuer (A) is authenticated (provided the recipient [B] trusts the entity that signed the included X.509 certificate). In addition, the individual SOAP message containing the purchase order, signature, and certificate elements could be archived to a database for purposes of nonrepudiation.

What's Missing?
Our example seems straightforward, but there are a number of unanswered questions. How does Trading Partner A know that the purchase order service requires signing the SOAP message body? How does Trading Partner A know what signature mechanisms are supported?

Trading Partner A could dynamically discover the answers via service descriptions located in a directory (such as extended WSDL entries in UDDI), or could invoke another Web service to negotiate these details. OASIS is currently considering forming a new technical committee to address some of these issues. The recently published WS-Policy (www.verisign.com/wss/WS-Policy.pdf) and WS-Trust (www.verisign.com/wss/WS-Policy.pdf) papers also address this topic.

For the foreseeable future, however, it is likely that most of these issues will be solved via configuration. This is where using a platform is crucial. Each Trading Partner needs to configure and maintain only one set of these parameters to communicate with all the other Trading Partners on the platform. Contrast this with the overhead of settling each of these issues on a per-Trading Partner basis.

Authentication
The second core security requirement of our shared B2B process integration platform is to mutually authenticate all participants in the system. This requirement breaks down into two lower-level requirements - authenticating users and authenticating servers.

Until now our discussion has centered on the security needs of server-to-server communications. A B2B process integration platform also provides access to applications; users must be authenticated to these apps. Authenticating users against an internal LDAP store with a username/password combination is a tried-and-true method for handling this problem. But ideally we would like the Trading Partners' users to authenticate within their own security domain, then use single sign-on (SSO) to access the applications within the platform. Security Assertion Markup Language (SAML) allows us to do this.

SAML
Accepted as an OASIS committee specification in May of 2002, SAML (www.oasis-open.org/committees/security/#documents) allows our platform to configure trust relationships between itself and the Trading Partners such that the users of those Trading Partners can automatically authenticate with our platform. Once more the network effect is evident, as it is much easier for each Trading Partner to maintain a single SAML trust relationship between itself and the platform than with each individual Trading Partner.

The SAML specification defines two browser-oriented single sign-on profiles. These profiles specify how SAML can be used to provide SSO for Web browser-based applications. Nonbrowser-based applications that use SOAP (or SAML-aware server systems) can take advantage of the fact that the WSS specification supports the use of SAML Assertions as WSS "Security Tokens." This allows consumers of WSS-protected services to leverage their SAML infrastructure to provide message-level authentication for those services.

If SAML allows users to authenticate with the platform, how does the platform authenticate with the user? For this we may rely on SSL. Despite the shortcomings outlined earlier, SSL works well at authenticating servers to users.

XKMS
In my discussion of message integrity and confidentiality I made passing references to X.509 certificates. To be explicit, server entities that interact with the platform authenticate themselves using X.509 certificates. This raises a number of questions: Who issues these certificates? For how long are they valid? What are the revocation policies?

The answer to these questions, in the case of our example, lies in the capabilities of the B2B process integration platform. The platform acts as an intermediate certificate authority, creating, storing, and revoking certificates as needed. The interface to all these platform services is specified by XKMS.

The XML Key Management Specification (XKMS 2.0: www.w3.org/TR/xkms2) is a W3C Working Draft. It is made up of two parts - the XML Key Information Service Specification (X-KISS) and the XML Key Registration Service Specification (X-KRSS)

The X-KISS specification defines a protocol for resolving public key information contained in XML Signature and XML Encryption elements. Referring again to our example, Trading Partner B would use the X-KISS protocol to determine whether the certificate in the SOAP message it received from Trading Partner A (via the platform) was valid.

The X-KRSS specification defines a protocol that accepts registration of public key information. Once registered, the public key may be used in conjunction with other Web services including X-KISS. The use of X-KRSS greatly simplifies one of the steps in the server-to-platform provisioning process, discussed later.

Authorization
The third core security requirement for our shared B2B process integration platform is to restrict participants to the services and data that they are allowed to access. To understand how Web services security standards apply to this requirement, you must understand something about the authorization architecture of the platform. Individual components of the platform enforce authorization according to semantics particular to each component. These Policy Enforcement Points (PEPs, to use terminology defined in the "Generic AAA Architecture" - RFC 2903) use a central Policy Decision Point (PDP) to determine if a given user or server should be allowed to perform a specific action on a particular resource. The PDP's decisions are driven by policies stored in a policy repository.

Another SAML Application
The SAML specification defines the request/response protocol used to communicate between the PEPs and the PDP (termed "Authorization Authority" by SAML) as well as the Authorization Decision Assertions that are returned by this protocol. To make its decision, the Authorization Authority frequently needs information about the attributes of the requesting user or server, for which it uses another SAML-defined protocol to request Attribute Assertions from one or more Attribute Authorities. Consider this example:

Claude, a user of Trading Partner A, uses single sign-on to access the platform and launch the report generation application. While in the application, Claude attempts to generate a transaction report for the last 30 days.

The report generation application needs to determine if Claude is allowed to read the information necessary to generate the report. It requests an Authorization Decision Assertion from the central Authorization Authority, passing as parameters Claude's Authentication Assertion, the name the resource needed to generate the report, and the action Claude is attempting to perform on that resource (i.e., "read"). To make this decision the Authorization Authority accesses the repository to determine the security policies applicable to the requested resource. These policies indicate that Claude's role is a factor in this decision. To obtain information about what roles Claude is allowed to perform the Authorization Authority contacts the Attribute Authority for Trading Partner A and requests the Attribute Assertions that describe the roles assigned to Claude. With this information the Authorization Authority is capable of determining that Claude is allowed read access to the requested resource and indicates this fact in the Authorization Decision Assertion it returns to the application.

Provisioning
The fourth core security requirement is to add and remove Trading Partners and their users to and from the platform quickly and with a minimum of human involvement. Normally provisioning and deprovisioning are not thought of as security requirements but these activities are, in fact, central to the platform's overall security fabric.

Referring back to our original example of Trading Partner A sending a (partially) encrypted and digitally signed purchase order to Trading Partner B, although XKMS/X-KRSS handles the certificate creation and registration tasks of provisioning Trading Partner A's server, the following tasks still need to be performed before our example can be executed:

1. "Bootstrap" provisioning to allow A's server to consume the XKMS/X-KRSS services.
2. Grant A's server the authority to look up the certificate for B's server using XKMS/X-KISS.
3. Subscribe A's server to the SOAP endpoint that accepts purchase order messages.
4. Subscribe A's server to the service that routes purchase orders to Trading Partner B.

Current practices for managing provisioning are often manually intensive, and thus expensive and error-prone. Ideally what we would like to be able to do is integrate the provisioning infrastructures of the Trading Partner's with that of the platform. Administrators within the Trading Partners' domains should be able to provision end users and servers for platform services as if they were provisioning them for internal services. The Trading Partners' provisioning engine then calls a platform service to carry out this request. This sort of integration is made possible via the Service Provision Markup Language (SP ML: www.oasis-open.org/committees/provision/#documents) an OASIS working draft.

If provisioning is a security requirement, then deprovisioning is even more so. Stale accounts and access privileges that are never removed provide fertile ground for security breaches. However, integrating the customers' provisioning and directory integration engines with the platform offers the added benefit of making sure that the Trading Partners clean up platform accounts when deprovisioning their users and servers.

Conclusion
The changing needs of the enterprise IT marketplace are driving the adoption of new infrastructure models that include the use of Web services as a common integration fabric. These new models have surpassed the capabilities of currently deployed security technologies and practices. Recent developments in Web services security standards promise to address many of these shortcomings, and open B2B process integration platforms have emerged as an early testing ground for these security challenges.