Introducing WebLogic Integration B2B Security

This topic includes the following sections:

• WebLogic Integration B2B Security Model

• Principals, Users, and Groups

• Digital Certificates

• Certificate Authority

• SSL Protocol

• Configuration Restrictions to Ensure a Secure Environment

 

---

WebLogic Integration B2B Security Model

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

• Uses the security features of the underlying BEA WebLogic Server^TM platform to perform authentication and authorization of principals before granting access to B2B resources.

• Is extensible by allowing you to incorporate your own or third-party vendor tools to verify trading partner digital certificates and implement nonrepudiation support, which is a requirement for critical business messages.

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

You must use WebLogic Server 6.x security realms and compatibility mode of the WebLogic Server Security Service. For more information about WebLogic Platform security, see Introducing WebLogic Platform 7.0 Security at the following URL:

http://download.oracle.com/docs/cd/E13196_01/platform/docs70/secintro/index.html

WebLogic Integration B2B authentication is the process of verifying an identity claimed by or for a system entity. 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:

• Username and password—human users (administrators) use usernames and passwords to prove their identity.

• Digital certificates—trading partners use digital certificates to prove their identity to the B2B engine.

• Secure sockets layer (SSL)—the SSL protocol provides data integrity and confidentiality to the connections between principals.

Authorization is a right or a permission that is granted to a system entity to access a system resource. The authorization process is a procedure for granting such rights. 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 business message arrives for a trading partner, 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: WebLogic Integration repository WebLogic Integration workflow templates and definitions JDBC connection pool JMS destinations 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: Data encryption Digital signatures Secure timestamps Secure audit log 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.
Private keystore	File in which you can store the private keys, along with passwords, and certificates that are used in trading partner collaborations. These keys and passwords are embedded in the following certificates: The client certificate—Digital certificate of the remote or local trading partner. The server certificate—Digital certificate of the remote trading partner. The signature certificate—Used for each trading partner business message if digital signature support is required. The encryption certificate—Used for each trading partner if business message encryption is required.
Root CA keystore	File in which you store all the trusted CA certificates associated with each trading partner and server certificate used in the B2B collaborations.
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 WebLogic resources	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.
WebLogic Keystore provider Service Provider Interfaces (SPIs)	Set of interfaces that implement a means to insert and maintain private keys and certificates in a keystore. The WebLogic Keystore provider uses the reference Keystore implementation supplied by Sun Microsystems in the Java Development Kit. It utilizes the standard "JKS" keystore type, which implements each keystore as a file.

 

For more information about the WebLogic Server security features used by the B2B engine, see the following topics:

• "Configuring the SSL Protocol" inManaging WebLogic Security, available at the following URL:

  http://download.oracle.com/docs/cd/E13222_01/wls/docs70/secmanage/ssl.html

• "Defining ACLs in the Compatibility Realm" in "Using Compatibility Security"in Managing WebLogic Security, available at the following URL:

  http://download.oracle.com/docs/cd/E13222_01/wls/docs70/secmanage/security6.html

 

---

Principals, Users, and Groups

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

• Trading partners

• Human users—WebLogic Integration B2B administrators

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:

• Trading partner users on WebLogic Integration

• WebLogic Integration B2B system user

• WebLogic Integration B2B administrator

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.

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, wlisystem:

• This user has access to all B2B resources except the transport servlet. This restriction prevents an external entity from entering the WebLogic Integration system as a B2B system user.

• This user is predefined in the sample configuration shipped with the product. The default password for the wlisystem user is wlisystem. If, however, there is no BEA system user, create the username wlisystem (password wlisystem) using the WebLogic Server Administration Console.

• If you want to change the wlisystem password, do so in the B2B Console and in the fileRealm.properties file. (If the wlisystem password does not match the one specified in the fileRealm.properties file, a warning is entered in the system log, and the B2B engine throws an exception.)

  Note: You should change the wlisystem password only via the B2B Console. If you use the WebLogic Server Administration Console to modify the wlisystem password, the wlisystem password stored in the WebLogic Integration repository is not updated simultaneously, and subsequent attempts to start the B2B engine may fail.

 

---

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. The recipient of a digital certificate can verify that the certificate, including the public key of the subject, was issued and signed by a trusted certificate authority (CA). The recipient does this by using the trusted certificate authority's public key to ensure that the digital signature was created using the corresponding CA 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 name of the subject (holder, owner) and other identification information required to uniquely identify the subject, such as a URL or an e-mail address

• The subject's public key

• The name of the certificate authority that issued the digital certificate

• A serial number

• The validity period (or lifetime) of the digital certificate (defined by a start date and an end date)

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 1 (X.509v1) or version 3 (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:

• Server authentication—the server uses its digital certificate, issued by a trusted certificate authority, to authenticate itself to clients.

• Client authentication—optionally, clients might be required to authenticate themselves to the server by providing their own digital certificates. This type of authentication is also referred to as mutual authentication. The authentication model in WebLogic Integration B2B uses mutual authentication.

• Data privacy—all client requests and server responses are encrypted to maintain the confidentiality of the data exchanged over the network.

• Data integrity—data that flows between a client and server is protected from a third party's tampering.

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 B2B system user is not authorized to access the transport servlet. This ensures that no external entity can impersonate the B2B system user.

• Trading partners are not authorized to access B2B resources. (After a trading partner certificate has been authenticated, the trading partner certificate is mapped to a WebLogic Server user. Only after the trading partner business message has also been authenticated, the WebLogic Server user to whom the trading partner certificate has been mapped accesses the B2B resources on the trading partner's behalf.)

• The architecture of the WebLogic Integration environment is designed so that there is never a need to divulge password information for trading partners because trading partners are always mapped in the B2B environment from their digital certificates.

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 wlisystem 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 the previous step accesses the B2B resources required to service the trading partner business message.