|
|
This topic describes security concepts and tasks in WebLogic Integration trading partner integration solutions. It includes the following sections:
Before you begin implementing WebLogic Integration security for trading partner integration, be sure to read the following documents:
This topic describes the WebLogic Integration security framework for trading partner integration. It includes the following sections:
WebLogic Integration leverages certain functionality from the WebLogic Server security framework and provides additional features for trading partner integration. WebLogic Integration supports secure business transactions between trading partners through:
WebLogic Integration security is based on the WebLogic Server security framework—namely, the Default Security Configuration. For more information, see "The Default Security Configuration in WebLogic Server" in "Overview of Security Management" in Managing WebLogic Security at the following URL:
The WebLogic security model for trading partner integration:
The following figure shows the entities and features in WebLogic Server and WebLogic Integration that support trading partner integration.
The following table describes the features in this security model.
The service profile defines the business messages that a given trading partner may send and receive. When a business message arrives for a trading partner, WebLogic Integration, as part of the business message authorization process, examines the contents of the business message to validate it against the service profile. WebLogic Integration verifies that the content of the incoming business message is consistent with the business messages that the trading partner is bound, by the service profile, to either send or receive. This authorization scheme ensures that only the business messages that are consistent with the relevant service profile have access to trading partner integration resources. For more information, see Service Authorization.
|
|
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 SSL Protocol.
|
|
The User Management module of the WebLogic Integration Administration Console to manage the users, groups, and roles defined in the default security realm. For instructions on configuring users, groups, and roles in the WebLogic Integration Administration Console, see
User Management in Using WebLogic Integration Administration Console Help .
|
|
The Transport Servlet Filter is a WebLogic Integration-specific servlet filter that serves as the entry point for both HTTP and HTTPS access to trading partner integration resources, including:
For more information about these resources, see Trading Partner Integration Resources Requiring Security Policies.
The Transport Servlet Filter performs either basic or mutual authentication and it authorizes access to URL (Web) resources. A Transport Servlet Filter is dynamically registered in the WebLogic Server environment for trading partners bound to a specific service profile. For more information, see:
|
|
WebLogic Integration 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 service profile to which they are bound. For more information, see Authentication.
|
|
The
TPMUserNameMapper class maps a trading partner certificate to the corresponding WebLogic Server user that has been configured for the trading partner. The TPMUserNameMapper class implements the weblogic.security.providers.authentication.UserNameMapper interface. You can configure this class or write your own class. For more information, see Authenticating Remote Users in Two-Way Authentication and reference information for the UserNameMapper interface at the following URL:
|
|
The trading partner integration security system provides a means to implement nonrepudiation support. Nonrepudiation is the ability of a trading partner to approve or disapprove having previously sent or received a particular business message to or from another trading partner. Nonrepudiation requires the following services:
WebLogic Integration provides Service Provider Interfaces (SPIs) that allow you to incorporate your own or a trusted third-party's implementation. In addition, WebLogic Integration provides an audit log provider that can be used for demo / development purposes. For more information about nonrepudiation, see NonRepudiation.
|
|
Store private keys for local trading partners and certificates for both the local and remote trading partners. These certificates are of the following types:
For more information about these certificates, see Types of Digital Certificates. For more information about the identity keystore, see Keystore for Private Keys and Certificates.
|
|
Store all the trusted CA certificates associated with any certificate used in WebLogic Integration in this KeyStore. For more information, see Keystore for Private Keys and Certificates.
|
|
All passwords are kept in encrypted form in the WebLogic Integration PasswordStore, which uses the JCE security provider. For more information, see WebLogic Integration PasswordStore for Encrypted Passwords.
|
|
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 SSL Protocol.
|
|
A security policy is an association between a WebLogic resource and one or more users, groups, or security roles that is designed to protect the WebLogic resource against unauthorized access. For more information, see
Security Policies in Securing WebLogic Resources at the following URL:
|
When you create a new domain using the WebLogic Platform Configuration Wizard and the WebLogic Integration template, the new domain contains default security settings, including:
WebLogic Integration provides the following credential stores to store passwords, private keys, and certificates:
All passwords are kept in encrypted form in the PasswordStore. WebLogic Integration does not require clear-text passwords. The PasswordStore uses the JCE security provider. Configuration of passwords is controlled through an MBean API and passwords are accessed using password-aliases.
You use the WebLogic Integration Administration Console to manage passwords in the PasswordStore. For more information, see the following topics in System Configuration in Using WebLogic Integration Administration Console Help :
WebLogic Integration requires that you use keystores to store all private keys and certificates. A keystore is a protected database that holds keys and certificates. If you have keys and certificates and use message encryption, digital signatures, or SSL, you must use a keystore for storing those keys and certificates and make the keystore available to applications that might need it for authentication or signing purposes.
When you set up a WebLogic Integration domain for trading partner integration, the following keystores are configured:
Stores private keys for local trading partners and certificates for both the local trading partner and remote trading partners. Certificates are of the following types: client, server, signature, and encryption certificates. WebLogic Integration retrieves private keys and certificates from this keystore to use for SSL, message encryption, and digital signatures. For more information about certificates, see Digital Certificates.
|
|
When you create a new domain using the WebLogic Platform Configuration Wizard and the WebLogic Integration template, the new domain contains Demo Keystores of type JKS.
You can use the Demo keystores in a development / testing environment, but you must explicitly create new identity and trust keystores for a production environment. To create a keystore and make it available for trading partner integration:
For information about refreshing the keystore using the WebLogic Integration Administration Console, see "Refreshing the Keystore" in Trading Partner Management in Using WebLogic Integration Administration Console Help .
| Note: | In a clustered domain, you need to create and configure a separate keystore for each WebLogic server. |
You can configure security policies for trading partner integration resources, such as:
bpmarchpool and cgpool) and MBeans that are used to access the TPM repositoryFor more information, see Securing WebLogic Resources at the following URL:
Transport-level security involves authentication and encryption at the transport level (HTTP/HTTPS) and authorization at the endpoint. This topic describes transport-level security concepts and tasks for trading partner integration. It contains the following sections:
In WebLogic Integration, 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. WebLogic Integration examines and validates digital certificates against security information stored in the TPM repository.
For trading partner integration, WebLogic Integration uses the following approaches to authentication:
Trading partner authentication is configured in the protocol bindings that define communications between trading partners. For more information, see "Defining Protocol Bindings" in Trading Partner Management in Using WebLogic Integration Administration Console Help .
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 that WebLogic Integration supports:
Both types of authentication can be used while exchanging business messages between trading partners. In addition, administrators can use HTTPS from a Web Browser to access the WebLogic Integration Administration Console and WebLogic Server Administration Console.
Administrators use a Web browser to access the WebLogic Integration Administration Console. You can use the Hypertext Transfer Protocol with SSL (HTTPS) to secure this type of network communication. For more information about SSL, see:
http://download.oracle.com/docs/cd/E13222_01/wls/docs92/secmanage/ssl.html
WebLogic Integration supports the following types of authentication:
Trading Partner Integration incorporates a two-level authentication process:
Both levels are required for end-to-end access control (authorization) on WebLogic Integration resources. After a trading partner business message has passed both levels of authentication, Trading Partner Integration engine performs the authorization process on the business message. To protect trading partner integration resources, the authorization process requires at least basic or mutual authentication, which are described in Types of Authentication.
Digital certificates are electronic documents used to verify the unique identities of principals and entities over networks such as the Internet. A digital certificate securely binds the identity of a user or entity, 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.
Digital certificates are stored in the identity keystore. For more information, see Keystore for Private Keys and Certificates.
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 1 (X.509v1) or version 3 (X.509v3).
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.
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.
WebLogic Integration supports the following types of certificates in trading partner integration:
Digital certificate of the remote or local trading partner. Configuring the client certificate is required when using the SSL protocol.
|
|||
Certificate required of each trading partner if digital signature support, a requirement for nonrepudiation, is configured. Used in message-level security. For a description of digital signature support, see Digital Signatures.
|
|||
Certificate required of each trading partner when business message encryption is configured. Used in message-level security. Note that encryption support is available only with the RosettaNet protocols. For a description of message encryption, see SSL Protocol.
|
Note the following general rules about configuring trading partner certificates:
Configuration requirements regarding digital certificates differ between local and remote trading partners.
You do not configure a server certificate for a local trading partner. A client certificate, as well as encryption and signature certificates, are required if mutual authentication with SSL is used. All of these certificates require associated private keys. You can use the same certificate and private key pair for all of these functions, as long as the key-usage in the certificate covers these functions.
You use the WebLogic Integration Administration Console to configure digital certificates. Digital certificates are stored in the identity keystore. Before you can configure digital certificates, the trading partner must be defined in the TPM repository and the identity keystore must be configured. For more information, see Keystore for Private Keys and Certificates.
For configuration instructions, see the following topics in Trading Partner Management in Using WebLogic Integration Administration Console Help :
| Note: | WebLogic Integration does not validate any of the trading partner certificates against a trusted Certificate Authority as you load them into the keystore. |
As described in Authentication Levels, after a trading partner's certificate has been validated by WebLogic Server, Trading Partner Integration engine 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 TPM repository. After a trading partner message has been authenticated, the trading partner's identity is recognized and access to various trading partner integration resources is provided—based on the configured policies—while processing that message.
The following figure shows the process of authenticating a trading partner message.
In the preceding figure, note the following:
This section describes the TPMUserNameMapper class, which helps find the association between a remote trading partner's identity and a WebLogic Server user.
| Note: | TPMUserNameMapper applies only to two-way authentication. If your deployment uses a different authentication mechanism, you can skip this section. |
| Note: | TPMUserNameMapper applies only to remote—not local—trading partners. When configuring a local trading partner, you do not need to provide a WebLogic Server username for that trading partner. |
The TPMUserNameMapper class helps find the association between a remote trading partner's identity and a WebLogic Server user. When you configure a trading partner profile in WebLogic Integration, you also specify the trading partner name bound to that profile. To associate a user with a trading partner in the WebLogic Integration Administration Console, specify the trading partner username, which is a WebLogic Server username.
At run time, WebLogic Server maps the digital certificate for that trading partner to the trading partner user, as shown in the following figure.
If mutual authentication is used (CLIENT-CERT in web.xml and SSL configured for mutual authentication in WebLogic Server), the TPMUserNameMapper uses two schemes to find the certificate to the user mapper in the following manner. When a trading partner message arrives in WebLogic Server from a remote trading partner, TPMUserNameMapper is invoked just before completing the SSL handshake. First, it looks into the TPM repository for a trading partner-WebLogic Server user association using the fingerprint of the client certificate of the remote trading partner. If not found, it tries to map an attribute of the client certificate to the WLS user.
You need to configure the DefaultIdentityAsserter settings in WebLogic Server to use TPMUserNameMapper so that the WebService/SOAP, ebXML and RosettaNet protocols can use the same UserNameMapper in WebLogic Integration.
To configure the TPMUserNameMapper:
Security
RealmsmyrealmProvidersAuthenticationDefaultIdentityAsserter
The WebLogic Server Administration Console displays the configuration tabs for the DefaultIdentityAsserter.
com.bea.b2b.security.TPMUserNameMapper.X.509 and click the right arrow.
The com.bea.b2b.security.TPMUserMapper class implements the WebLogic Server weblogic.security.providers.authentication.UserNameMapper interface. You could create your own implementation of this API, if you wanted, but using the TPMUserNameMapper class provides you access to the TPM repository as well. For more information, see "Interface UserNameMapper" at the following URL:
To verify a trading partner's digital certificate in WebLogic Integration, you use a certificate verification provider (CVP). The Trading Partner Integration security framework provides a Service Provider Interface (SPI) that allows you to insert a Java class implementing SPI that can call out to a third-party service to verify trading partner certificates. Such an implementation, called a certificate verification provider, can call out to one of the following certificate verification applications:
If you are using a certificate verification provider (CVP), you need to configure it in the WebLogic Integration Administration Console, as described in "Specifying the Certificate Verification Provider" in Trading Partner Management in Using WebLogic Integration Administration Console Help .
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:
Configuring and using a CVP implementation is optional, but doing so can provide an additional level of security in the certificate verification process.
The CVP is used by WebLogic Integration in the following cases:
The following figure is an example of the sequence of events that occur during the certificate verification process in WebLogic Integration for an incoming message using SSL and mutual authentication.
Note the following callouts in the preceding figure.
A certificate verification provider (CVP) Java class must implement the com.bea.wli.security.verification.CertificateVerificationProvider interface. You have two choices for what a CVP class can call out to:
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.
Trading Partner Integration allows you to implement a CVP via the com.bea.wli.security.verification.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 Integration Administration Console so that the CVP is invoked properly during run time.
The com.bea.wli.security.verification.CertificateVerificationProvider interface has the following methods, which a CVP application must implement:
void init()This method is automatically invoked by Trading Partner Integration engine 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 Integration.
public String verify(X509Certificate[] certs)
This method validates the certificate chain obtained during the SSL handshake. It should return 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. |
| Note: | If you do not configure a CVP, any certificate issued by a trusted certificate authority is considered by Trading Partner Integration engine to be valid. |
If you implement a CVP, 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 Integration 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 Trading Partner Integration engine to be valid.
You use the WebLogic Integration Administration Console to configure a CVP. For more information, see "Specifying the Certificate Verification Provider" in Trading Partner Management in Using WebLogic Integration Administration Console Help .
After you configure a CVP, restart WebLogic Server so that the CVP can take effect.
| Note: | When you are running WebLogic Integration in iterative development mode, no security verification settings are active. The CVP is only active in development mode. |
Authorization determines whether access is provided to trading partner integration resources, such as:
bpmarchpool and cgpool) and MBeans that are used to access the TPM repositoryPermission to access trading partner resources is assigned through policies and roles—for any resource that needs to be protected, its security policy will be defined based on roles. Individual users/entity will thus be able to get access depending upon the roles that they belong to. Whereas 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.
| Note: | Authorization is available (but not required) with basic, one-way plus basic, and mutual authentication. |
For trading partner integration, WebLogic Integration incorporates two levels of authorization:
WebLogic Server performs trading partner authorization. When the trading partner message arrives in WebLogic Server, and the trading partner and WebLogic Server complete the mutual or basic (username and password) authentication procedure, authorization is performed by WebLogic Server to access the Transport Servlet Filter.
The preferred way to configure the B2BDefaultWebApp is to use the WebLogic Server Administration Console to set policies on the B2BDefaultWebApp for access to URLs. For instructions, see "URL (Web) and EJB (Enterprise JavaBean) Resources" in Types of WebLogic Resources in Securing WebLogic Resources at the following URL:
In addition to configuring B2BDefaultWebApp, you can also configure other trading partner integration resources (such as the JDBC connection pool and MBeans used to access the TPM repository, WebLogic Workshop business processes, and JMS destinations) that need to be configured as well. For more information, see Authorization.
When Trading Partner Integration engine performs service authorization, the server examines the content of the trading partner business message with respect to the service profile to which the trading partner is bound. That is, for a service profile, a trading partner may send only a specific set of business messages. Trading Partner Integration engine validates the business message against the following information specified in the service profile for a particular service:
Once the service authorization is complete for an incoming business message, access to the B2B resources is dictated by WebLogic resource policies.
Message-level security involves digital signatures, encryption, and non-repudiation for individual business messages. This topic describes message-level security concepts and tasks for trading partner integration. It contains the following sections:
Using digital signatures prevents tampering with business messages. Using encryption ensures message privacy. Nonrepudiation allows trading partners to prove or disprove having previously sent or received a particular business message to or from another trading partner.
Message-level security is configured in the protocol bindings that define communications between trading partners. For more information, see "Defining Protocol Bindings" in Trading Partner Management in Using WebLogic Integration Administration Console Help .
Digital signatures provide a means of preventing anyone or anything from tampering with the contents of a business message, especially when the business message is in transit between two trading partners. After verifying a signature, WebLogic Integration uses a Certificate Verification Provider (if two-way authentication is configured), as described in Authenticating Remote Users in Two-Way Authentication. Digital signatures are required for nonrepudiation, which is described at NonRepudiation.
WebLogic Integration supports the following types of digital signatures:
| Note: | XML Digital Signatures cannot be used when receiving ebXML messages from WLI Business Connect using ebXML MS 1.0. Instead, ebXML MS 2.0 should be used. |
A digital signature itself is a set of data appended to a business message consisting of an encrypted, one-way hash value of data packaged in a specific format (for example, PKCS7 SignedData or XMLDSIG signature). A digital signature:
The data required to create a digital signature is obtained from the trading partner configuration data in the TPM repository. The information required to create a digital signature also includes the following:
You can configure whether to sign business messages or not in the protocol bindings that define communications between trading partners. For more information, see "Defining Protocol Bindings" in Trading Partner Management in Using WebLogic Integration Administration Console Help .
After validating a signature, WebLogic Integration invokes the certificate verification provider (CVP), which is described in Certificate Verification Process.
WebLogic Integration supports XMLDSig for ebXML 1.0 and ebXML 2.0 message exchanges between trading partners.
WebLogic Integration supports the following XMLDSig features:
For more information about XMLDSig, see "XML-Signature Syntax and Processing" on the W3C web site at the following URL:
http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/Overview.html
WebLogic Integration uses the following algorithms for XMLDSig:
For RosettaNet 1.1 and 2.0, WebLogic Integration supports digital signature with PKCS7 Enveloped Data.
WebLogic Integration supports PKC7 enveloped data for digital signatures for RosettaNet 1.1 and 2.0. Digital signatures for multipart messages apply to:
WebLogic Integration supports the following PKC7 enveloped data algorithms:
Nonrepudiation, or the ability to provide legal evidence of the involvement of a denying party, is a legal requirement for critical business messages. 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. WebLogic Integration supports:
Nonrepudiation is configured in the protocol bindings that define communications between trading partners. For more information, see "Defining Protocol Bindings" in Trading Partner Management in Using WebLogic Integration Administration Console Help .
Trading Partner A has agreed to purchase 1000 ergonomic chairs from Trading Partner B. In the course of this agreement, Trading Partner A has sent a business message to Trading Partner B agreeing to buy the chairs at a set price. Later, though, Trading Partner A disputes the original price and denies having sent a message in which they agreed to pay that price.
If a reliable nonrepudiation system has been in place, Trading Partner B can disprove Trading Partner A's claim by producing a document from Trading Partner A specifying the amount Trading Partner A agreed to pay. Further, if this original document is digitally signed, timestamped, recorded, and secured by a trusted third-party source, the validity of this document has full legal recourse.
To support nonrepudiation, WebLogic Integration provides the following services:
Digital signatures are required for nonrepudation because they provide a means of preventing anyone or anything from tampering with the contents of a business message, especially when the business message is in transit between two trading partners. For more information, see Digital Signatures.
A secure audit log is required for nonrepudation because it typically stores each business message with its digital signature and secure timestamp, allowing a trading partner to reconstruct the sequence of messages and other system events that have occurred during the exchange of business messages with other trading partners, along with the data exchanged.
The default audit log provider (com.bea.wli.security.audit.DefaultAuditLogProvider) logs to a file named secureaudit.log. This file is based on the logging subsystem and is protected by only the underlying operating system's file permissions system. This file is not digitally signed or encrypted. It should be used only for demo or development purposes, not in a production environment.
You enable and disable the audit log and specify the audit log class in the WebLogic Integration Administration Console. For more information, see "Configuring Secure Audit Logging" in Trading Partner Management in Using WebLogic Integration Administration Console Help .
All log messages correspond to the DTD log-message.dtd, which defines the contents for each message type.
All audit log messages have the following three identifiers:
The following table describes the contents of the data for each of the message types. All the log messages contain the timestamp obtained from the timestamp provider that is configured in WebLogic Integration.
The following code example shows the log-message.dtd file:
<!ELEMENT LOG (non-repudiation-origin| non-repudiation-receipt | application)>
<!ATTLIST LOG time-stamp CDATA #REQUIRED >
<!ATTLIST LOG location CDATA #IMPLIED >
<!ATTLIST LOG Principal CDATA #IMPLIED >
<!ELEMENT non-repudiation-origin (#PCDATA)>
<!ELEMENT non-repudiation-receipt (#PCDATA)>
<!ELEMENT application (#PCDATA)>
Trading Partner Integration engine provides a Service Provider Interface (SPI) for you to configure a trusted, third-party provider of the secure audit log. If you incorporate a secure audit log service from a trusted third-party provider, you need to create a class that implements the com.bea.wli.security.audit.AuditLogProvider interface. In the methods of your class (for example, log), you call out to the third party audit log provider.
| Note: | If you implement an audit log service using the SPI described in this section, you must configure this service later in the WebLogic Integration Administration Console so that the service is invoked properly during run time. |
The com.bea.wli.security.audit.AuditLogProvider interface has the following methods, which a secure audit log application must implement:
Your implementation of the secure audit interface must include a default public constructor with no arguments. Neither the constructor nor any methods in the class that implements the AuditLogProvider interface should throw any exceptions.
As an alternative to writing a Java implementation of the com.bea.wli.security.audit.AuditLogProvider interface to call out to an application that writes to the audit log, you can write an application that writes to the audit log directly via an invocation to the com.bea.wli.security.audit.Audit.log(byte[] data) method, as shown in the following code example from a business process. In this example, the bolded code shows the statements that have been added to show writing to the audit log.
package orderprocessing;
import com.bea.jpd.JpdContext;
import org.apache.xmlbeans.XmlObject;
import com.bea.data.MessageAttachment;
// Import the Audit class from the WLI security package
import com.bea.wli.security.audit.Audit;
/**
* @jpd:process process::
* <process name="ServerBuyer">
* <clientRequest name="Receive order request from client" method="start"/>
* <controlSend name="Send PO to enterprise server seller"
method="sendOrder"/>
* <controlReceive name="Receive PO receipt from enterprise server seller"
method="orderService_onMessage"/>
* <clientCallback name="sendAck" method="sendAck"/>
* </process>::
*
*/
@com.bea.wli.jpd.Process(process = "<process name=\"ServerBuyer\">" +
" <clientRequest name=\"Receive order request from client\" method=\"start\"/>" +
" <controlSend name=\"Send PO to enterprise server seller\" method=\"sendOrder\"/>" +
" <controlReceive name=\"Receive PO receipt from enterprise server seller\" method=\"orderService_onMessage\"/>" +
" <clientCallback name=\"sendAck\" method=\"sendAck\"/>" +
"</process>")
public class EnterpriseServerBuyer implements com.bea.jpd.ProcessDefinition
{public com.bea.tutorial.b2B.order.OrderDocument pcOrder;
/**
* @jc:ebxml ebxml-service-name="SecureOrderService" from="BEA-IT-id" to="SUN-id" ebxml-action-mode="default"
* @common:control
*/
@Control()
@EBXMLControl.EbXML(serviceName = "SecureOrderService",
from = "BEA-IT-id",
to = "SUN-id",
ebXMLActionMode = EBXMLControl.EbXML.ActionMode.DEFAULT)
private SecureOrderServiceControl orderService;
/**
*@common:context
*/
@com.bea.wli.jpd.Context()
JpdContext context;
public void start( String str )
{//create an order
pcOrder = ...
}
public void sendOrder()
{//#START: CODE GENERATED - PROTECTED SECTION - you can safely add code
above this comment in this method. #//
// input transform
// method call
orderService.sendOrder(pcOrder);
// output transform
// output assignments
//#END : CODE GENERATED - PROTECTED SECTION - you can safely add code
below this comment in this method. #//
}
public void orderService_onMessage(MessageAttachment[] reply)
{//assume only one object of type XmlObject in reply
XmlObject xo = reply[reply.length - 1].getXmlObject();
if(Audit.isEnabled()) {Audit.log(xo.toString().getBytes());
}
}
public Callback callback;
public interface Callback {public void onAck(String reply);
}
void sendAck() {callback.onAck("This is an ACK from ServerBuyer.jpd.");}
}
A timestamp provider is required for nonrepudation because a secure timestamp service attaches a Coordinated Universal Time (UTC) timestamp to the secure audit log when business messages are also logged to the secure audit log, providing precise time and date information.
For example, when a trading partner receives a business message, a timestamp is entered as a nonrepudiation of receipt (NRR) message in the audit log. When a trading partner sends a business message, a timestamp is entered as a nonrepudiation of origin (NRO) message in the audit log.
You configure the timestamp provider in the WebLogic Integration Administration Console. For more information, see "Configuring Secure Audit Logging" in Trading Partner Management in Using WebLogic Integration Administration Console Help .
Trading Partner Integration engine prohibits more than one secure timestamp provider from being registered in WebLogic Integration. This restriction ensures that all timestamps created in WebLogic Integration are ordered chronologically.
| Note: | If you do not configure a secure timestamp service provider in WebLogic Integration, system time is used for timestamping system events and signatures if the default log provider is used. |
Trading Partner Integration includes a Service Provider Interface (SPI) so that you can incorporate a secure timestamp service from a trusted third-party provider.
If you incorporate a secure timestamp service from a trusted third-party provider, you need to create a Java class that implements the com.bea.wli.security.time.TimestampProvider interface. In the methods (for example, getTimestamp) of your class implementing the com.bea.wli.security.time.TimestampProvider interface, you call out to the third party timestamp provider.
Trading Partner Integration allows you to create a customized secure timestamp service by implementing the com.bea.wli.security.time.TimestampProvider interface. If you implement a timestamp using the SPI described in this section, you must configure this service later in the WebLogic Integration Administration Console so that the service is invoked properly during run time.
The com.bea.wli.security.time.TimestampProvider interface has the following methods, which a timestamp application must implement:
Your implementation of the timestamp interface must include a default public constructor with no arguments. Neither the constructor nor any methods in the class that implements the TimeStampProvider interface should throw any exceptions.
WebLogic Integration encrypts business messages for the business protocols that require it. In this WebLogic Integration release, message encryption is supported only for RosettaNet 2.0.
| Note: | To use message encryption, you must have a valid license for using the encryption service. |
The following figure shows how data encryption is performed using the public and private keys.
Data encryption works by using a combination of the sender's certificate, private key, and the recipient's certificate to encode a business message. The message can then be decrypted only by the recipient using the recipient's private key.
| Note: | WebLogic Integration encryption is controlled by licensing (Encryption/Domestic or Encryption/Export), but the decryption of a business message is not. If WebLogic Integration does not have a valid encryption license, Trading Partner Integration engine disables the encryption service. However, Trading Partner Integration engine can always decrypt business messages that are received. |
The WebLogic Integration message encryption service supports the following algorithms:
You use the WebLogic Integration Administration Console to enable or disable business messages encryption in the protocol bindings that define communications between trading partners. For more information, see "Defining Protocol Bindings" in Trading Partner Management in Using WebLogic Integration Administration Console Help .
This topic describes how to use proxy servers with trading partner integration. It includes the following sections:
If you are using WebLogic Integration in a security-sensitive environment, you may want to use WebLogic Integration behind a proxy server. A proxy server allows trading partners 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, network traffic is tunneled through, or delegated to, the proxy server and then to the external network. The following figure illustrates how a proxy server might be used in the WebLogic Integration environment.
To configure a proxy server in the WebLogic Integration Administration Console, see "Configuring a Proxy Host" in Trading Partner Management in Using WebLogic Integration Administration Console Help .
| Note: | If you configure a proxy server, you also 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";| Note: | In addition, you need to specify the following WebLogic Web Server system properties: |
| Note: | -http.proxyHost (if proxy server is configured for SSL tunneling)-https.proxyPort (if proxy server is configured for SSL tunneling) |
| Note: | The weblogic.common.ProxyAuthenticator interface is used to obtain authentication information to communicate with the proxy. For more information, see Interface ProxyAuthenticator available at http://download.oracle.com/docs/cd/E13222_01/wls/docs92/javadocs/weblogic/common/ProxyAuthenticator.html. |
You can configure WebLogic Integration with a Web server, such as an Apache server, that is programmed to service business messages from a remote trading partner. A Web server can provide the following services:
The Web server uses the WebLogic proxy plug-in, which you can configure to provide the following services:
The following figure shows the topology of an environment that uses a Web server, the WebLogic proxy plug-in, and WebLogic Integration.
When using the WebLogic Proxy Plug-In, note that:
To configure the Web server, see Configuring Web Server Functionality for WebLogic Server in BEA WebLogic Server Administration Guide at the following URL:
http://download.oracle.com/docs/cd/E13222_01/wls/docs92/adminguide/web_server.html
The following code example provides the segment of httpd.conf (for an Apache server) needed to configure the proxy plug-in:
# LoadModule foo_module libexec/mod_foo.so
LoadModule weblogic_module libexec/mod_wl_ssl.extension
<Location /weblogic>
SetHandler weblogic-handler
PathTrim /weblogic
WebLogicHost myhost
WebLogicPort 80
</Location>
Here, extension is the file extension used by your Unix installation.
For development and testing purposes, you use the default security configuration that is generated when you create a new WebLogic Integration domain using the WebLogic Platform Configuration Wizard. For more information, see Default Domain Security Configuration.
For a production environment, you need to configure security as part of your deployment. This topic provides a summary of the tasks that you need to complete. It contains the following sections:
You use the User Management module of the WebLogic Integration Administration Console to manage the users, groups, and roles defined in the default security realm. For instructions on configuring users, groups, and roles in the WebLogic Integration Administration Console, see User Management in Using WebLogic Integration Administration Console Help .
You need to configure the profiles for trading partners with whom you will exchange business messages. For an introduction to trading partner profiles, see Trading Partner Profiles. For instructions on configuring trading partner profiles in the WebLogic Integration Administration Console, see the following topics in Trading Partner Management in Using WebLogic Integration Administration Console Help :
You need to create and configure the identity and trust keystore for certificates and private keys. For an introduction to the keystore, see Keystore for Private Keys and Certificates. For instructions on creating and configuring the keystore, see the following topics:
You need to add digital certificates to trading partners. For an introduction to certificates, see Digital Certificates. For instructions on configuring certificates in the WebLogic Integration Administration Console, see the following topics in Trading Partner Management in Using WebLogic Integration Administration Console Help :
You need to configure SSL for transport-level security using the WebLogic Server Administration Console. For an introduction, see SSL Protocol. For configuration instructions, see Configuring SSL in Managing WebLogic Security at the following URL:
You need to decide the transport-level security and message-level security options that you want to use in your message exchanges, and then configure those options in the service profile for each trading partner. For example, you might use mutual authentication with one trading partner and basic authentication with another. Similarly, you might implement nonrepudiation with a customer or vendor, but not with a trading partner that is within your organization.
For instructions on how to managing service profiles in the WebLogic Integration Administration Console, see the following topics in Trading Partner Management in Using WebLogic Integration Administration Console Help .
The WebLogic Platform documentation set contains several additional security topics.
To keep you informed of the latest security advisories and to make sure you have access to security-related patches as soon as they become available, BEA maintains the BEA Advisories & Notifications page at:
http://dev2dev.bea.com/advisories
If you discover a possible security issue with WebLogic Platform 9.2 or any of its components, BEA recommends that you report it to secalert@bea.com.
The BEA dev2dev Web site includes a Web page that provides links to several security-specific resources, including:
For the list of security topics recommended on the dev2dev Web site, see:
http://dev2dev.bea.com/products/wlplatform81/security.jsp
The dev2dev site also hosts a Web page that provides answers to frequently asked questions (FAQ) about BEA WebLogic Platform and other BEA products. The site is updated monthly. To visit the dev2dev FAQ page, see:
http://dev2dev.bea.com/topitems/topsolutions/index.jsp
|