Authenticating and Authorizing Trading Partners

The topic includes the following sections:

Trading Partner Authentication in WebLogic Integration

Authentication is the process by which WebLogic Integration B2B engine establishes the identity of a principal. Digital certificates using the SSL protocol with mutual authentication (HTTPS) are used between a trading partner and WebLogic Integration. The B2B engine examines and validates digital certificates against security information stored in the repository.

WebLogic Integration B2B incorporates a two-level authentication process:

When a trading partner business message has passed both levels of authentication, the B2B engine performs the authorization process on the business message.

The sections that follow describe both levels of the B2B authentication process.

Trading Partner Certificate Verification

The WebLogic Integration B2B security model provides a Service Provider Interface (SPI) that allows you to insert a Java class that implements an interface that calls out to a third-party service to verify trading partner certificates. Such an implementation, called a certificate verification provider (CVP), can call out to one of the following certificate verification applications:

Benefits of Certificate Verification

The purpose of trading partner certificate verification is to validate the trading partner's digital certificate. For example, verifying a certificate may involve some or all of the following tasks:

Configuring and using a CVP implementation is optional, but doing so can provide an additional level of security in the certificate verification process.

Certificate Verification Process

The following figure shows the sequence of events that occur during the certificate verification process in the WebLogic Integration environment.

Figure 2-1 Trading Partner Certificate Verification in WebLogic Integration

Implementing a Certificate Verification Provider

A certificate verification provider (CVP) Java class must implement the com.bea.b2b.security.CertificateVerificationProvider interface. You have two choices for what a CVP class can call out to:

Regardless of which choice you pick, you need to create a Java implementation of the CVP SPI that calls out to the application that performs the actual certificate verification. Creating, compiling, and configuring this CVP application is explained in the subsections that follow.

Using the Service Provider Interface

WebLogic Integration B2B allows you to implement a CVP via the com.bea.b2b.security.CertificateVerificationProvider interface, which provides the CVP service provider interface (SPI). If you implement or use a CVP using the SPI described in this section, you must later configure this CVP in the WebLogic Integration B2B Console so that the CVP is invoked properly during run time.

The com.bea.b2b.security.CertificateVerificationProvider interface has the following methods, which a CVP application must implement:

Notes: If you implement a CVP, you need to add a default public constructor for the CVP with no arguments. Neither the constructor nor any methods in the class should throw any exceptions.

If you do not configure a CVP, any certificate issued by a trusted certificate authority is considered by the B2B engine to be valid.

Compiling the Certificate Verification Provider Class

If you implement a CVP, note the following:

Configuring a Certificate Verification Provider with WebLogic Integration B2B

Authentication of the Trading Partner Message

After a trading partner's certificate has been validated by WebLogic Server, the B2B engine needs to authenticate the trading partner message before the message itself can be serviced. Authenticating the trading partner message involves verifying that the sender of the business message is a valid trading partner listed in the WebLogic Integration repository. After a trading partner message has been authenticated, the trading partner's identity becomes recognized for full access to B2B resources.

The following figure shows the process of authenticating a trading partner message.

Figure 2-2 Authenticating the Trading Partner Message

Note: Only trading partners can be authenticated to use the B2B transport servlet. If the B2B system user attempts to access the transport servlet to access B2B resources, the access is denied by WebLogic Server. This mechanism ensures that no remote entity can gain access to B2B resources assuming the identity of a B2B system user.

Trading Partner Authorization in WebLogic Integration B2B

Authorization is the process of allowing a B2B principal access to a specific set of B2B resources. The authorization model in the B2B system is based on an ACL and permission mechanism and role-based authorization control.

The B2B system incorporates two levels of authorization:

Trading Partner Authorization

This level of authorization is performed by WebLogic Server. When the trading partner message arrives in WebLogic Server, and the trading partner and WebLogic Server complete the mutual authentication procedure, the trading partner becomes authorized to access the B2B transport servlet.

The path of the transport servlet is dynamic, so you need to edit the web.xml file to allow trading partners to access the URL of the transport servlet. You cannot preconfigure this because of the dynamic nature of the URL corresponding to the transport servlet in the B2B environment.

You need to specify transport servlet ACLs in the web.xml file. The following example shows a web.xml file that specifies the ACLs for a transport servlet named wlctransport.

Listing 2-1 Example Transport Servlet ACL

<!DOCTYPE web-app PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 1.2//EN
" "http://java.sun.com/j2ee/dtds/web-app_2_2.dtd">

<web-app>
...
... 
<!-- Authentication -->
 <security-constraint>
  <web-resource-collection>
   <web-resource-name>wlctransport</web-resource-name>
   <url-pattern>*</url-pattern>
  </web-resource-collection>
  <auth-constraint>
   <role-name>TradingPartnerGroupA</role-name>
  </auth-constraint>
 </security-constraint>

 <login-config>
  <auth-method>CLIENT_CERT</auth-method>
 </login-config>

 <security-role>
  <role-name>TradingPartnerGroupA</role-name>
 </security-role>
</web-app>

In the preceding code example:

Conversation Authorization

When the B2B engine performs conversation authorization, the server examines the content of the trading partner business message with respect to the collaboration agreement to which the trading partner is bound. That is, for a given role and party specified in a collaboration agreement, a trading partner may send only a specific set of business messages. The B2B engine validates the business message against the following information specified in the collaboration agreement for a particular conversation:

Once the conversation authorization is complete for an incoming business message, access to the B2B resources is dictated by ACLs.