Administer > Manage WebSphere Commerce features > WebSphere Commerce integration with WebSphere Portal
WebSphere Commerce Portal Integration site architecture
The WebSphere Commerce Portal Integration sample site architecture includes relationships between the Internet, Internet DMZ, Production DMZ, and Intranet.
The following diagram depicts a sample architecture deploying WebSphere Portal and WebSphere Commerce in a multi-tier demilitarized zone (DMZ) configuration with high availability. This sample configuration can be used for an Internet or extranet WebSphere Portal solution. In this configuration, an optional authentication proxy, such as Tivoli Access Manager WebSEAL, can be used to shield the Web server from unauthorized requests for external facing users. This approach is desirable when the Web server or the application server contains sensitive data, such as WebSphere Commerce order related information, where direct access to it is not desirable. Alternatively, if WebSphere Application Server is used to perform authentication, which is the default WebSphere Portal configuration, it makes use of a directory server, such as an LDAP server to verify the user's credentials:
The security model for WebSphere Commerce Portal Integration assumes the network connection between the WebSphere Portal tier and the backend WebSphere Commerce tier are either behind a firewall or secured. It is up to the WebSphere Portal administrator to decide which networking model to employ because the decision should be weighted between the benefit and the cost of using secured connections.
Configure WebSphere Portal to use SSL adds security so that all traffic between the WebSphere Portal server and the back-end WebSphere Commerce services is encrypted. This added security prevents any eavesdropping on the information that is exchanged over the network. However, depending on the amount and nature of the information being transferred, the cost of encryption can sometimes have a sufficient impact on the overall application performance.
There are primarily two kinds of end-users of this sample configuration: shoppers and business users. The access route of online shoppers is very different from how internal business users access the WebSphere Commerce system. Internal business users typically have special credentials to access the trusted backend network, where they can use native WebSphere Commerce user interfaces to configure the online store and product information. Shoppers, however, require a higher level of defense security when accessing the site content, to prevent unauthorized requests and other potential security exposures.
The following diagram represents the recommended sample deployment and network configuration for WebSphere Commerce and WebSphere Portal integration:
In this sample, the single cell network configuration is necessary for implementing the cache invalidation function between WebSphere Commerce and WebSphere Portal. It creates a secured domain as a WebSphere Application Server cell with two separate clusters, each consisting of a set of WebSphere Commerce nodes and WebSphere Portal nodes. A replication service is used to broadcast only cache invalidation events between the two clusters, which are part of the same replication domain and core group.
The following is a list of key considerations when setting up this sample deployment configuration:
- All WebSphere Commerce nodes must belong to the same node group.
- All WebSphere Portal nodes must belong to the same node group. This node group can be different from the WebSphere Commerce node group.
- All WebSphere Commerce nodes must be assigned to the same cluster. This cluster must not contain any WebSphere Portal nodes.
- All WebSphere Portal nodes must be assigned to the same cluster. This cluster must not contain any WebSphere Commerce nodes.
- All nodes, both WebSphere Commerce and WebSphere Portal, must be part of the same core group.
- Both the WebSphere Commerce cluster and WebSphere Portal cluster must be deployed to the same cell.
- For each WebSphere Portal application server, enable the Web container servlet cache, while leaving the Portlet container portlet cache disabled.
- All application servers, both WebSphere Commerce and WebSphere Portal, must have DynaCache replication enabled against the same replication domain, using the Not Shared replication type to broadcast invalidation events only.
- Each cluster must have a cache instance that can be used for cache replication.
- Cell-level global security should be enabled with federated LDAP repositories in order for LTPA single sign on to work.
- Security domains are used to allow WebSphere Portal and WebSphere Commerce to use different security configurations. WebSphere Portal requires both administrative security and application security in the Portal cluster, while WebSphere Commerce cluster members can only have administrative security enabled.
- Web servers can be used with cluster members are recommended, but not required.
Uncontrolled zone
The uncontrolled zone contains:
- Users who attempt to access the WebSphere Portal application or the WebSphere Commerce application directly.
Controlled zone
The controlled zone contains:
- A firewall.
- An authentication proxy such as Tivoli Access Manager. This authentication proxy is placed behind a firewall and manages the authentication process.
Restricted zone
The restricted zone contains:
- A firewall.
- A Web server that serves the WebSphere Portal application.
- A WebSphere Portal machine that contains the WebSphere Commerce portlets. The portlets can access the WebSphere Commerce application over a secure SSL connection and through an additional firewall.
- A LDAP server such as Tivoli Directory Server, provides access to the user registry and user repository. This repository can be accessed by the WebSphere Portal machine over a secure SSL connection.
Trusted zone
The trusted zone contains:
- A firewall.
- An optional Web server that serves the WebSphere Commerce application directly.
- The WebSphere Commerce application. This application can communicate with the WebSphere Commerce portlets over a secure HTTPS connection.
- The WebSphere Commerce application can communicate with the LDAP server over an SSL connection and through a firewall.
For additional information about using SSL and defining repertoires in WebSphere Portal, see Set up SSL.
Related concepts
Maintain the WebSphere Commerce portlet application
WebSphere Commerce integration with WebSphere Portal
Single sign-on (SSO) and WebSphere Commerce Portal
Maintain the WebSphere Commerce portlet application
Related tasks
Configure WebSphere Portal with WebSphere Commerce
Configure WebSphere Portal with WebSphere Commerce using basic authentication
Configure WebSphere Portal with WebSphere Commerce using simulated single sign-on