Authenticating and Authorizing Trading Partners

The topic includes the following sections:

• Trading Partner Authentication in WebLogic Integration

• Trading Partner Authorization in WebLogic Integration B2B

 

---

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:

• The first level involves verification of the trading partner certificate.

• The second level involves authentication of the trading partner message.

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:

• A Certificate Revocation List (CRL) implementation

• An Online Certificate Status Protocol (OCSP) implementation that interacts with a trusted third-party entity, such as a certificate authority, for real-time certificate status checking

• Your own certificate verification implementation

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:

• Traversing the certificate chain to the root certificate authority

• Checking a certificate revocation list (CRL) for all the certificates in the chain to identify any of those that have been revoked

• Performing a real-time certificate check with a trusted vendor, who can verify the certificate

• Checking to make sure all dates in the certificate chain are valid

• Verifying the signature of each certificate in the chain

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

 

In the preceding figure, note the following callouts.

Callout	Description
1	Certificate verification is used only in SSL. The trading partner and the WebLogic Server system perform an SSL handshake, during which they exchange certificates to establish each other's identity. The Certificate Authority of the trading partner digital certificate must be trusted in WebLogic Server. During this handshake, WebLogic Server verifies the following: The Certificate Authority of the trading partner certificate must be one that is trusted in the WebLogic Server environment. The trading partner certificate has not expired. When the SSL handshake is completed, the trading partner's network connection to the WebLogic Server system is established.
2	WebLogic Server invokes the WLCCertAuthenticator class in the B2B engine. The WLCCertAuthenticator class in turn implements the weblogic.security.acl.CertAuthenticator interface in order to map the trading partner certificate to the corresponding WebLogic Server user that has been configured for the trading partner.
3	The WLCCertAuthenticator class invokes the CVP interface to the implementation that calls out to the third-party certificate verification service.
4	The CVP implementation calls out to the third-party certificate verification service, which returns the status of the trading partner certificate.
5	The CVP implementation returns the appropriate status of the certificate to the WLCCertAuthenticator class.
6	If the trading partner certificate is valid, the B2B engine attempts to map the certificate to a valid trading partner name in the repository. If the certificate maps to a valid trading partner, WebLogic Integration returns a WebLogic Server user to WebLogic Server.

 

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:

• A trusted third-party vendor that conforms to the service provider interface, as described in Using the Service Provider Interface.

• Your own certificate verification application.

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:

• void init()

  This method is automatically invoked by the B2B engine to invoke any custom initialization processes in the class you create that implements this interface. This method is invoked only once, at the startup of WebLogic Integration.

• String verify(Certificate[] certs)

  This method validates the certificate chain obtained during the SSL handshake. It returns one of the following String values:

  • good—the trading partner certificate is valid and not expired.

  • revoked—the trading partner certificate has been revoked by one of the certificate authorities in the certificate chain, or the trading partner certificate has expired.

  • unknown—none of the certificate authorities in the certificate chain is able to establish the validity of the trading partner certificate.

  The implementer can choose the validation procedure performed by this method. For example, this method can check certificate revocation lists (CRLs) stored in files, it can check the certificate status in real-time using the Online Certificate Status Protocol (OCSP), or it can use any other mechanism, as appropriate.

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:

• After you create the CVP Java class, you must compile it and place it in the system CLASSPATH.

• You must configure the CVP via the B2B Console or the Bulk Loader utility. After you configure the CVP, restart WebLogic Server so that the CVP can take effect. If you do not configure a CVP, any certificate issued by a trusted certificate authority is considered by the B2B engine to be valid.

Configuring a Certificate Verification Provider with WebLogic Integration B2B

For complete details about using the B2B Console to configure a CVP, see Configuring a Certificate Verification Provider Interface. After you configure a CVP, restart WebLogic Server so that the CVP can take effect.

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

 

In the preceding figure, note the following:

• The transport servlet is the entry point into the B2B engine. When the trading partner message arrives in the B2B transport servlet, as shown by callout 1, the transport servlet verifies the trading partner message. Verifying a trading partner means ensuring that the trading partner name is valid by retrieving its value from a valid certificate associated with the trading partner.

• When the trading partner message is authenticated, the trading partner is authorized for access to WebLogic Integration resources, such as the repository and WebLogic Integration business process management (BPM) templates and workflows, shown by callout 2. The access is made available via the B2B system user context.

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:

• Authorization of the trading partner for access to the B2B transport servlet

• Authorization of the conversation associated with the trading partner business message

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:

• wlctransport is the transport servlet whose endpoint is defined in the WebLogic Integration repository.

• TradingPartnerGroupA is a WebLogic Server user group in which all the trading partner WebLogic Server users are members.

• CLIENT-CERT specifies that the mode of authentication required to access the transport servlet is SSL with mutual authentication.

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:

• Party information (trading partner and role)

• Conversation definition

• Document exchange ID

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