BEA Logo BEA WLI Release 2.1

  BEA Home  |  Events  |  Solutions  |  Partners  |  Products  |  Services  |  Download  |  Developer Center  |  WebSUPPORT

   http://www.oracle.com/technology/documentation/index.html   |   Site Map   |   Search   |   PDF Files   |   Contact   |   Glossary

 

   WLI Doc Home   |   B2B Topics   |   B2B Security   |   Previous Topic   |   Next Topic   |   Contents   |   Index   |   View as PDF

Introducing WebLogic Integration B2B Security

 

This topic includes the following sections:

 

WebLogic Integration B2B Security Model

The WebLogic Integration B2B security model incorporates the following primary features:

This section describes the WebLogic Server and B2B entities involved in providing the authentication and authorization features of WebLogic Integration.

WebLogic Integration B2B authentication is the process of verifying a principal's identity. Authentication is concerned with who an entity is; it is the association of an identity with an entity. Authorization is concerned with what that identity is allowed to see and do. WebLogic Integration B2B uses the following methods to perform authentication:

Authorization protects who has access to the available resources. Permission to access B2B resources is assigned through access control lists (ACLs) and roles.

For complete details about how WebLogic Server and WebLogic Integration B2B work together to authenticate and authorize principals in the WebLogic Integration B2B engine, see Authenticating and Authorizing Trading Partners.

The following figure shows the entities and features in WebLogic Server and WebLogic Integration that provide the B2B security model.

Figure 1-1 WebLogic Integration B2B Security Model


 

The following table describes each of the features shown in this B2B security model.

Table 1-1 Components in the WebLogic Integration B2B Security Model

Component

Description

Conversation authorization

When a trading partner business message arrives, the B2B engine, as part of the business message authorization process, examines the contents of the business message to validate it against the collaboration agreement. That is, the collaboration agreement defines the business messages a given trading partner may send and receive. The B2B engine verifies that the content of the incoming business message is consistent with the business messages that the trading partner is bound, by role and conversation definition in the collaboration agreement, to either send or receive.

This authorization scheme makes sure that only the business messages that are consistent with the relevant collaboration agreement have access to B2B engine resources.

Data encryption service

The data encryption service encrypts business messages for the business protocols that require it. Data encryption works by using a combination of the sender's certificate, private key, and the recipient's certificate to encode the business message. The message can then be decrypted only by the recipient using the recipient's private key.

For details about using the data encryption service, see Configuring Message Encryption.

Authentication in the transport servlet

A transport servlet is a WebLogic Integration-specific servlet that serves as the entry point for both HTTP and HTTPS access to B2B resources, including the following:

A transport servlet is dynamically registered in the WebLogic Server environment for trading partners bound to a specific collaboration agreement.

Authentication for outbound request via the SSL protocol

The B2B engine authenticates the recipient for all outbound messages using the SSL certificate obtained in the SSL handshake to ensure that the messages are consistent with the relevant collaboration agreement to which they are bound.

WLCCertAuthenticator class

The WLCCertAuthenticator class maps trading partner certificates to the corresponding WebLogic Server users that have been configured for the trading partner. The WLCCertAuthenticator class implements the weblogic.security.acl.CertAuthenticator interface.

You can configure this class to invoke your own or a trusted third-party vendor's implementation that verifies trading partner certificates. For more information, see Authenticating and Authorizing Trading Partners.

Nonrepudiation framework

The B2B security system provides a means to implement nonrepudiation support. Nonrepudiation is the ability of a trading partner to prove or disprove having previously sent or received a particular business message to or from another trading partner. Nonrepudiation requires the following services:

WebLogic Integration provides out-of-the-box implementations for nonrepudiation and Service Provider Interfaces (SPIs) that allow you to incorporate your own or a trusted third-party's implementation.

For more information about nonrepudiation, see Implementing Nonrepudiation.

Authentication for inbound requests via SSL protocol

When an inbound trading partner message arrives, both the trading partner and the WebLogic Server system exchange certificates to establish each other's identity. When the SSL handshake is completed, the trading partner's network connection to the WebLogic Server system is established.

For information about configuring the SSL protocol in WebLogic Server to provide mutual authentication, see Configuring the SSL Protocol and Mutual Authentication.

ACLs for JDBC connection pool


ACLs are data structures with multiple entries that guard access to WebLogic Integration B2B resources. An ACL grants permission on a resource, or class of resources, to a list of users and groups. An ACL includes a list of AclEntries, each with the set of permissions for a particular user or group.

Permissions represent privileges required for accessing a resource and are specific to the resource they protect. The exact permissions available depend on the type of resource the ACL protects. For example, there are permissions to send and receive files, delete files, read and write files, and load servlets.

For information about configuring the ACLs for the JDBC connection pool, see Configuring Access Control Lists for WebLogic Integration B2B.

 

For more information about the WebLogic Server security features used by B2B engine, see "Configuring the SSL Protocol" and "Defining ACLs" in Managing Security in the BEA WebLogic Server Administration Guide.

 

Principals, Users, and Groups

Principals are entities that need access to the B2B environment and resources. WebLogic Integration B2B principals include:

Principals are granted access to the WebLogic Integration B2B engine environment and resources through authentication and authorization mechanisms. Principals in WebLogic Integration B2B map to WebLogic Server users.

If the B2B engine can prove the identity of the WebLogic Server user, the B2B engine associates the user with a thread that executes code on behalf of the user. Before the thread begins executing code, WebLogic Integration B2B checks pertinent access control lists (ACLs) to make sure the WebLogic Server user has the proper permission to continue.

WebLogic Integration B2B supports the following types of WebLogic Server users:

Groups are sets of WebLogic Server users. Groups provide an efficient way to manage large numbers of users because an administrator can specify permissions for an entire group at one time.

Note: Because the tasks typically performed via the WebLogic Integration B2B Console requires system level privileges—for creating users, accessing MBeans, and so on—the WebLogic Server username for logging into the B2B Console is configured as a WebLogic Server system user.

About Configuring Trading Partners

When you configure a collaboration agreement in WebLogic Integration, you also specify the trading partner name bound to that agreement. To associate a user with a trading partner in the B2B Console, specify the trading partner username, which is a WebLogic Server username. WebLogic Server maps the digital certificate for that trading partner to the trading partner user at run time.

Figure 1-2 Mapping a Trading Partner Certificate to a WebLogic Server User


 

Therefore, when a trading partner message arrives in WebLogic Server, WebLogic Server is able to match a trading partner to a WebLogic Server user by reading a trading partner certificate, and the B2B engine authentication process may begin.

About Configuring the WebLogic Integration B2B System User

Please note the following about the B2B system user:

 

Digital Certificates

Digital certificates are electronic documents used to uniquely identify principals and objects over networks such as the Internet. A digital certificate securely binds the identity of a user or object, as verified by a trusted third party known as a certificate authority, to a particular public key. The combination of the public key and the private key provides a unique identity to the owner of the digital certificate.

Digital certificates allow verification of the claim that a specific public key does in fact belong to a specific user or entity. A recipient of a digital certificate can use the public key contained in the digital certificate to verify that a digital signature was created with the certificate authority's private key. If such verification is successful, this chain of reasoning provides assurance that the corresponding private key is held by the subject named in the digital certificate, and that the digital signature was created by that particular certificate authority.

A digital certificate typically includes a variety of information, such as:

The most widely accepted format for digital certificates is defined by the ITU-T X.509 international standard. Thus, digital certificates can be read or written by any application complying with the X.509 standard. The public key infrastructure (PKI) in WebLogic Server recognizes digital certificates that comply with X.509 version 3, or X.509v3.

 

Certificate Authority

Digital certificates are issued by a certificate authority. Any trusted third-party organization or company that is willing to vouch for the identities of those to whom it issues digital certificates and public keys can be a certificate authority. When a certificate authority creates a digital certificate, the certificate authority signs it with its private key, to ensure the detection of tampering. The certificate authority then returns the signed digital certificate to the requesting subject.

The subject can verify the signature of the issuing certificate authority by using the public key of the certificate authority. The certificate authority makes its public key available by providing a digital certificate issued from a higher-level certificate authority attesting to the validity of the public key of the lower-level certificate authority. This hierarchy of certificate authorities is terminated by a self-signed digital certificate known as the root certificate, as shown in the following figure.

Figure 1-3 Certificate Authority Hierarchy


 

Before you use a digital certificate, verify a digital signature, or decrypt a business message, make sure that the digital certificate is issued by a trusted certificate authority. Regardless of who encrypts the business message, the digital certificate of the business message must be trusted, which is established by the certificate authority.

 

SSL Protocol

The SSL protocol provides secure connections by enabling two applications linked through a network connection to authenticate the other's identity and by encrypting the data exchanged between the applications. An SSL connection begins with a handshake during which the applications exchange digital certificates, agree on the encryption algorithms to use, and generate encryption keys used for the remainder of the session.

The SSL protocol provides the following security features:

The SSL protocol is used to implement link-level encryption of messages sent between trading partners.

Administrators use a Web browser to access the B2B Console. You can use the Hypertext Transfer Protocol with SSL (HTTPS) to secure this type of network communication.

 

Configuration Restrictions to Ensure a Secure Environment

WebLogic Integration B2B imposes the restrictions described in this section to ensure a secure environment. Some of these restrictions are repeated, as appropriate, in Configuring Security.

The following figure shows how these security restrictions appear in the WebLogic Integration B2B security model.

Figure 1-4 The Secure WebLogic Integration B2B Environment


 

In the preceding figure, note the following callouts:

  1. Any entity named wlcsystem attempting to gain access to the B2B transport servlet is denied access.

  2. After the trading partner certificate and business message are validated, the trading partner certificate is mapped to the corresponding WebLogic Server user.

  3. The WebLogic Server user mapped in previous step accesses the B2B resources required to service the trading partner business message.

 

back to top previous page next page

 

Copyright © 2001 BEA Systems, Inc. All rights reserved.
Required browser: Netscape 4.0 or higher, or Microsoft Internet Explorer 4.0 or higher.