Authenticating and Authorizing Trading Partners

 

The topic includes the following sections:

• Trading Partner Authentication in WebLogic Collaborate

• Trading Partner Authorization in WebLogic Collaborate

 

---

Trading Partner Authentication in WebLogic Collaborate

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

WebLogic Collaborate 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, WebLogic Collaborate performs the authorization process on the business message.

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

Trading Partner Certificate Verification

The WebLogic Collaborate 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 Collaborate environment.

Figure 2-1 Trading Partner Certificate Verification in WebLogic Collaborate

 

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 WebLogic Collaborate. 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, WebLogic Collaborate attempts to map the certificate to a valid trading partner name in the repository. If the certificate maps to a valid trading partner, WebLogic Collaborate 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 three 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.

• The BEA-provided CVP application that you can download from the Developer Center, available at the following URL:

  http://developer.bea.com/index.jsp

• 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 Collaborate 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 Collaborate Administration 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 WebLogic Collaborate 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 Collaborate.

• 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 WebLogic Collaborate Server 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 WebLogic Collaborate Administration 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 WebLogic Collaborate Server to be valid.

Configuring a Certificate Verification Provider with WebLogic Collaborate

For complete details about using the WebLogic Collaborate Administration 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 WebLogic Collaborate Server 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 Collaborate repository. After a trading partner message has been authenticated, the trading partner's identity becomes recognized for full access to WebLogic Collaborate 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 WebLogic Collaborate. When the trading partner message arrives in the WebLogic Collaborate 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 Collaborate resources, such as the repository and WebLogic Process Integrator templates and workflows, shown by callout 2. The access is made available via the WebLogic Collaborate system user context.

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

 

---

Trading Partner Authorization in WebLogic Collaborate

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

The WebLogic Collaborate system incorporates two levels of authorization:

• Authorization of the trading partner for access to the WebLogic Collaborate 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 WebLogic Collaborate 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 WebLogic Collaborate 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 Collaborate 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 WebLogic Collaborate 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.WebLogic Collaborate 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 WebLogic Collaborate resources is dictated by ACLs.