Introducing WebLogic Collaborate Security

 

This topic includes the following sections:

• WebLogic Collaborate Security Model

• Principals, Users, and Groups

• Digital Certificates

• Certificate Authority

• SSL Protocol

• Configuration Restrictions to Ensure a Secure Environment

 

---

WebLogic Collaborate Security Model

The WebLogic Collaborate 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 WebLogic Collaborate 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 WebLogic Collaborate entities involved in providing the authentication and authorization features of WebLogic Collaborate.

WebLogic Collaborate 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 Collaborate 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 in WebLogic Collaborate use digital certificates to prove their identity to WebLogic Collaborate.

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

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

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

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

Figure 1-1 WebLogic Collaborate Security Model

 

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

Table 1-1 Components in the WebLogic Collaborate Security Model

Component	Description
Conversation authorization	When a trading partner business message arrives, WebLogic Collaborate, 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. WebLogic Collaborate 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 WebLogic Collaborate 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 Collaborate-specific servlet that serves as the entry point for both HTTP and HTTPS access to WebLogic Collaborate resources, including the following: WebLogic Collaborate repository WebLogic Process Integrator workflow templates and definitions JDBC connection pool 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	WebLogic Collaborate authenticates the recipient for all outbound messages using the SSL certificate obtained in 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 WebLogic Collaborate 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 Collaborate 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 Collaborate 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 Collaborate.

 

For more information about the WebLogic Server security features used by WebLogic Collaborate, 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 WebLogic Collaborate environment and resources. WebLogic Collaborate principals include:

• Trading partners

• Human users—WebLogic Collaborate administrators

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

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

WebLogic Collaborate supports the following types of WebLogic Server users:

• Trading partner users on WebLogic Collaborate

• WebLogic Collaborate system user

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

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

About Configuring Trading Partners

When you configure a collaboration agreement in WebLogic Collaborate, you also specify the trading partner name bound to that agreement. To associate a user with a trading partner in the WebLogic Collaborate Administration 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 WebLogic Collaborate authentication process may begin.

About Configuring the WebLogic Collaborate System User

Please note the following about the WebLogic Collaborate system user:

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

• The WebLogic Collaborate system user is predefined in the sample configuration shipped with the product. The default password for wlcsystem user is wlcsystem. However, if the system user does not exist for any reason, you can create the username wlcsystem (password wlcsystem) via the WebLogic Server Administration Console. (You may also change the password as desired in the WebLogic Collaborate Administration Console.)

• Do not use the WebLogic Server Administration Console to modify a WebLogic Collaborate system password. The password is stored in the repository for run-time access to WebLogic Collaborate resources.

  Note: When the password does not match the one specified in the fileRealm.properties file, a warning is entered in the system log. When the password for user wlcsystem does not match, WebLogic Collaborate uses the user system for run-time access to the repository.

 

---

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

• 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 Collaborate 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 WebLogic Collaborate Administration 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 Collaborate imposes the restrictions described in this section to ensure a secure environment. Some of these restrictions are repeated, as appropriate, in Configuring Security.

• The WebLogic Collaborate system user is not authorized to access the transport servlet. This ensures that no external entity can impersonate the WebLogic Collaborate system user.

• Trading partners are not authorized to access WebLogic Collaborate 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 WebLogic Collaborate resources on the trading partner's behalf.)

• The architecture of the WebLogic Collaborate 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 WebLogic Collaborate environment from their digital certificates.

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

Figure 1-4 The Secure WebLogic Collaborate Environment

 

In the preceding figure, note the following callouts:

1. Any entity named wlcsystem attempting to gain access to the WebLogic Collaborate 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 WebLogic Collaborate resources required to service the trading partner business message.