Configuring Security

This following sections describe how to configure security in BEA WebLogic Collaborate:

Introduction to the WebLogic Collaborate Security Model

The WebLogic Collaborate security model uses the security features of the underlying BEA WebLogic Server^TM platform.

Authentication is the process of verifying a principal's identity before completing a connection. Authentication protects who gets access to the WebLogic Collaborate environment. WebLogic Collaborate uses the following methods to perform authentication:

In the WebLogic Collaborate environment, authorization protects who has access to the available resources. Permission to access WebLogic Collaborate resources is assigned through access control lists and roles. The following figure illustrates the WebLogic Collaborate security model.

Figure 4-1 WebLogic Collaborate Security Model

Security Terminology

The following sections describes the security terminology used by the WebLogic Collaborate security model:

Transport Servlet

A transport servlet is the entry point into a WebLogic Collaborate system for communication between:

A transport servlet is dynamically registered in the WebLogic Server environment for each c-space and c-enabler.

Resources

Resources are objects in the WebLogic Collaborate environment. Some of the WebLogic Collaborate resources are:

Principals, Users, and Groups

Principals are objects that need access to the WebLogic Collaborate environment and resources. WebLogic Collaborate principals include:

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 the c-hub or c-enabler can prove the identity of the WebLogic Server user, the c-hub or c-enabler associates the user with a thread that executes code on behalf of the user. Before the thread begins executing code, the c-hub or c-enabler checks pertinent access control lists (ACLs) to make sure the WebLogic Server user has the proper permission to continue.

WebLogic Collaborate can have the following types of WebLogic Server users:

The following figure illustrates the relationship between principals in WebLogic Collaborate and WebLogic Server users.

Figure 4-2 WebLogic Collaborate Principals

Authorization

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

The following sections describe how authorization is used in the WebLogic Collaborate environment:

Access Control Lists

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 related 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.

You define ACLs for the following WebLogic Collaborate resources:

Transport Servlet, JDBC Connection Pool, and Administration Consoles

Authorization allows a user to access WebLogic Collaborate resources based on ACLs for the resources. The WebLogic Collaborate resources that require authorization are:

WebLogic Collaborate can have the following access control policies:

Conversations

WebLogic Collaborate conversations use a role-based authorization whereby a trading partner is given access to a conversation based on a role that is defined in subscriptions for that trading partner.

A particular trading partner in a c-space can send and receive certain types of documents as defined by the trading partner's role in a specific conversation. Authorization to send a document in a conversation is based on the subscriptions of the trading partner. Subscription information identifies:

The conversation definition identifies:

The c-hub compares the information in the subscription to the conversation definition. Based on this comparison, the c-hub allows a trading partner to participate in conversations by sending and receiving messages.

For example, suppose trading partner x has a subscription to a conversation named aConv with the role of buyer. The aConv conversation has two roles buyer and seller. The aConv conversation specifies that the buyer role has one incoming document (reply.dtd) and one outgoing document (request.dtd).

When trading partner x joins the c-space, it creates a conversation handler for the aConv conversation with a role of buyer. The c-hub prevents trading partner x from participating with a role of seller. In addition, the c-hub permits trading partner x to send only documents of type request.dtd.

To configure the authorization of a trading partner in a c-space, define the following information:

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 corresponding 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 subject.

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.

The recipient of an encrypted message can develop trust in the private key of a certificate authority recursively, if the recipient has a digital certificate containing the public key of the certificate authority signed by a superior certificate authority whom the recipient already trusts. In this sense, a digital certificate is a stepping stone in digital trust. Ultimately, it is necessary to trust only the public keys of a small number of top-level certificate authorities. Through a chain of digital certificates, trust in a large number of users' digital signatures can be established.

Thus, digital signatures establish the identities of communicating entities, but a digital signature can be trusted only to the extent that the public key for verifying the digital signature can be trusted.

SSL Protocol

The SSL protocol provides secure connections by enabling two applications connecting over 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 the c-hub and the c-enabler.

Administrators use a Web browser to access the C-Hub and C-Enabler Administration Consoles. You can use the Hypertext Transfer Protocol with SSL (HTTPS) to secure this type of network communication.

Authentication

Authentication is the process by which WebLogic Collaborate establishes the identity of a principal. Digital certificates with mutual authentication over SSL or HTTPS are used between the c-enabler (on behalf of the trading partner) and the c-hub. Both the c-hub and the c-enabler examine and validate the digital certificates against defined security information. Human users use a username/password combination to authenticate themselves to the WebLogic Collaborate environment.

Configuring the SSL Protocol and Mutual Authentication

To configure the c-hub to use the SSL protocol and mutual authentication, perform the following steps:

Defining Users and Groups

Define identities for users on the c-hub. Define the following types of users:

Include the following properties in the weblogic.properties file to define users.

weblogic.password.tp1=password for tp1 user 

weblogic.password.admin=password for hub administrator user 

In these properties:

To simplify administration, you can define all of the trading partner users in a group. You can then assign ACLs to the group. You can assign new trading partners to the group at any time. You must define a user before you add the user to a group. The following listing includes properties that define trading partner users and create a group, tpgroup, for the trading partner users.

Listing 4-2 Creating a Group

#Define passwords for the trading partner users.
weblogic.password.tp1=password for Trading Partner 1 User
weblogic.password.tp2=password for Trading Partner 2 User
weblogic.password.tp3=password for Trading Partner 3 User

#Create the group tpgroup and add users
weblogic.security.group.tpgroup=tp1,tp2,tp3

Defining Access Control Lists

The ACL for a resource determines whether a user or group can access a resource in WebLogic Collaborate. To define ACLs, you create an ACL for a resource, specify the permission for the resource, and then grant the permission to a specified set of users and groups. Each WebLogic Collaborate resource has one or more permissions for the resource that can be granted.

On the c-hub you need to define the following ACLs:

The following listing includes properties that define the c-hub ACLs. Note that the code example assumes the name of the transport servlet on the c-hub is cspace1.

Listing 4-3 C-Hub ACLs

#ACL for Transport Servlet
weblogic.allow.execute.weblogic.servlet.cspace1=tp1

#ACL for JDBC Connection Pool
weblogic.allow.reserve.weblogic.jdbc.connectionPool.wlcPool=tp1,admin
weblogic.allow.reset.weblogic.jdbc.connectionPool.wlcPool=admin
weblogic.allow.shrink.weblogic.jdbc.connectionPool.wlcPool=admin

#ACL for Administration Console
weblogic.allow.hubconfig.WLCAdmin=admin
weblogic.allow.hubmonitor.WLCAdmin=tp1

You can substitute groups for users in the ACLs as shown in the following listing.

Listing 4-4 Using Groups to Assign ACLs

#ACL for transport servlet
weblogic.allow.execute.weblogic.servlet.cspace1=tpgroup

#ACL for JDBC connection pool for WebLogic Collaborate
weblogic.allow.reserve.weblogic.jdbc.connectionPool.wlcPool=tpgroup,
        admin
#ACL for Administration Console
weblogic.allow.hubmonitor.WLCAdmin=admin

Specifying Information in the Repository

The c-hub repository contains security information about the c-hub and the trading partners that access the c-hub. Repository information can be either configured through the C-Hub Administration Console or specified in a repository data file and then imported into the repository using the Bulk Loader.

Define the following security information for the c-hub:

Define the following security information for each trading partner that accesses the c-hub:

The following listing contains an example of the security information you need to define for the c-hub and trading partners in the repository. For more information, see the readme.htm file in the WLC_HOME/examples/security directory.

Listing 4-5 Security Information for the Repository.

<c-hub
	...
	certificate-location="<WLC_HOME>\examples\security
	        \certificates\hub_cert.pem"
	private-key-location="<WLC_HOME>\examples\security
	        \certificates\hub_key.pem"
	certificate-field-name="email"
	server-certificate-field-name="email"
	...
/>

<trading-partner
	name="SecurityPartner1"
	email="partner1@bea.com"
	user-name="securityPartner1"
	certificate-field-value="e63914a52929a16dce3f6a5cb4bf67a2"
	<server-certificate
	        certificate-field-value="enabler@bea.com"/>
</trading-partner>

<trading-partner
	name="SecurityPartner2"
	email="partner2@bea.com"
	user-name="securityPartner2"
	certificate-field-value="fb8b5a3a39d71c49817fc55384798707"
	        <server-certificate
	certificate-field-value="enabler@bea.com"/>
</trading-partner>

Working with the WLCCertAuthenticator Class

The following sections describe how to work with the WLCCertAuthenticator class:

Specifying the WLCCertAuthenticator Class

WebLogic Collaborate contains an implementation of the weblogic.security.acl.CertAuthenticator class. On the c-hub, CertAuthenticator maps digital certificates from trading partners to their corresponding WebLogic Server users. On the c-enabler, CertAuthenticator maps the digital certificates from the c-hub to a corresponding WebLogic Server user.

You need to specify the WebLogic Collaborate implementation (com.bea.b2b.security.WLCCertAuthenticator) of the weblogic.security.acl.CertAuthenticator class in the weblogic.properties file. The following example shows the property that defines the WebLogic Collaborate implementation of the weblogic.security.acl.CertAuthenticator class.

weblogic.security.realm.certAuthenticator=com.bea.b2b.security.
        WLCCertAuthenticator

Customizing the WLCCertAuthenticator Class

The WLCCertAuthenticator is an implementation of the WebLogic Server CertAuthenticator class. The default implementation of the WLCCertAuthenticator class validates a trading partner and maps the digital certificate of the trading partner to the corresponding trading partner defined on the c-hub. You may want to extend this functionality to use mutual authentication for users other than trading partners. For example, you may want to modify the class to map a Web browser or Java client to a user on the c-hub.

The WLCCertAuthenticator class is called after an SSL connection has been established. The class can extract data from a digital certificate to determine the user which corresponds to the digital certificate.

For a code example of customizing the WLCCertAuthenticator class, see the Javadoc for the WLCCertAuthenticator class.

Configuring WebLogic Collaborate to Use an HTTP Proxy Server

If you are using WebLogic Collaborate in the security-sensitive environment, you may want to use WebLogic Collaborate behind a proxy server. A proxy server allows the c-hub and c-enabler to communicate across intranets or the Internet without compromising security. A proxy server is used to:

When proxy servers are configured on the local network WebLogic Collaborate uses, network traffic (SSL and HTTP) is tunneled through the proxy server to the external network. The following figure illustrates how a proxy server might be used in the WebLogic Collaborate environment.

Figure 4-3 Proxy Server

You need to add permissions to read and write the ssl.proxyHost and ssl.proxyPort system properties for the WebLogic Server. These system properties are stored in the weblogic.policy file which is located in the directory where you installed WebLogic Server. Add the following lines to the grant section of the weblogic.policy file.

permission java.util.PropertyPermission "ssl.proxyHost", "read, write";
permission java.util.PropertyPermission "ssl.proxyPort", "read, write";