Securing the WebSphere Commerce Search server

It is recommended that you secure WebSphere Commerce Search by enabling WebSphere Application Server Administrative Security. You can further secure your search server by optionally enabling WebSphere Application Server Application Security. Enabling Application Security results in securing Solr Administrative services so that only authenticated users can run these services. For example, updating, deleting, and building a search index. However, performance degradation might be associated with enabling Application Security.

Before you begin

Ensure that Solr is behind a firewall, so that only configured clients can connect to the Solr server.
If you are using WebSphere Commerce Developer, start at Step 6.

Procedure

Open the WebSphere Application Server Administrative Console:
1. Go to the following directory:
  - WAS_installdir/profiles/Solr_profiledir/bin
  - WAS_installdir\profiles\Solr_profiledir\bin
  Where Solr_profiledir is the directory that is created for the WebSphere Application Server profile that is used by a WebSphere Commerce Search instance.
2. Start the solrServer instance:
  - ./startServer.sh solrServer
  - startServer.bat solrServer
3. Open the WebSphere Application Server Administrative Console.
  For instance:
  - http://host_name:port/admin
  Note: For more information about locating your port number, see WebSphere Application Server Technote #21385225
Configure federated repositories:
1. In the WebSphere Application Server Administration Console, expand Security and click Global Security.
2. In the Available realm definitions section, select Federated repositories and click Configure.
3. Enter a user name in the Primary administrative user name field. It represents the name of the administrator that is used to log on to the WebSphere Application Server Administration Console. Click OK.
4. Enter a password for the administrative user and click OK.
5. Go back to the Federated repositories configuration page and click Save. A file-based repository is used to store the user ID and password.
Enable administrative security and optionally application security:
1. Select Enable administrative security. It automatically selects Enable application security.
  If your business requirements require application security, keep it enabled. However, performance degradation might be associated with enabling Application Security.
2. Clear Java 2 security.
3. Select Federated Repositories and click Set as current.
4. Click Apply and then click Save.
Enable application security:
1. Administrative security is enabled by default during feature enablement, with the same user ID and password as the WebSphere Commerce server.
2. Select Enable application security. However, performance degradation might be associated with enabling Application Security.
Restart the solrServer instance by stopping then starting the server:
1. Stop the solrServer instance:
  - ./stopServer.sh solrServer
  - stopServer.bat solrServer
2. Start the solrServer instance:
  - ./startServer.sh solrServer
  - startServer.bat solrServer

Complete the following steps if you selected Enable application security:

Go to Applications > Application Types > WebSphere enterprise applications > Search.
1. Click Security role to user/group mapping.
2. Select SearchAdministrator, click Map Users..., then click Search.
3. Add the user admin_user_id to the selected bucket and click OK, where admin_user_id is the user name that is specified in the Primary administrative user name field in Step 5.
4. Click OK.
Complete the following steps:
1. Open WebSphere Commerce Developer.
2. Open the META-INF\ibm-application-bnd.xml file in the WebSphere Commerce Search EAR project. Click the Design view.
3. Expand and select Security Role (SearchAdministrator).
4. Click Add, select User and click OK.
5. Under the Details heading, enter uid=configadmin,o=defaultWIMFileBasedRealm.
6. Save your changes.

Set the following namespace bindings in WebSphere Application Server for the appropriate WebSphere Commerce or Search machine. Where to set the bindings depends on whether the machine is an Authoring server, Production server or Repeater, as explained below:

When configuring the WebSphere Commerce server's WebSphere Application Server administrative console, navigate to Environments > Naming > Name space bindings > scope:Node=WC_demo_node,Server=server1. Alternatively, when configuring the Search server's WebSphere Application Server administrative console, navigate to Environments > Naming > Name space bindings > scope:Node=demo_search_node,Server=solrServer.

Add the following name-value pairs:

Name space bindings name-value pairs
Name	Value
`com.ibm.commerce.foundation.server.services.search.application.security.username`	The WebSphere Commerce Search server application security user name.
`com.ibm.commerce.foundation.server.services.search.application.security.password`	The encrypted application security password by the wcs_encrypt utility without specifying the merchant key. For more information, see Generate encrypted data (wcs_encrypt).

Where passwords are needed for the following locations and scenarios:

Authoring machine

For the WebSphere Commerce server, the namespace binding requires the password of its Authoring search server for delta indexing (UpdateSearchIndex scheduled job) and storefront searches.

Note:

The replication.csv file contains the encrypted password of the repeater or subordinate for index propagation from authoring to the repeater or subordinate using the indexprop utility.
The di-buildindex utility specifies its search server password in the command line to run a full index build.

For the WebSphere Commerce Search server (Master of repeater), no password is needed.

Production machine

For the WebSphere Commerce server, the namespace binding requires the password of its subordinate search server for storefront searches. This password must match the password that is used for the repeater search server, if one exists.

In addition, the namespace binding requires the password of its repeater search server for delta indexing (UpdateSearchIndex scheduled job) for Quick Publish, if used. This password must match the password that is used for the subordinate search server.

For the WebSphere Commerce Search server (subordinate of repeater), the password of the repeater is needed to pull index replication.

Repeater machine (Master of production, subordinate of Authoring)

The WebSphere Commerce Search server (subordinate of repeater) requires the password of the Authoring search server to pull index replication.

Save your changes.

Update the following values in the WC_installdir\instances\instance_name\search\commerce\properties\searchServer.properties file:
- wasAdminUser=admin_user_id
- wasAdminUserPwd=encrypted_admin_password
  Where the encrypted_admin_password value is the encrypted password by the wcs_encrypt utility without specifying the merchant key. For more information, see Generate encrypted data (wcs_encrypt).
Restart the solrServer and WebSphere Commerce server for the changes to take effect. After you enable the security, you must use the user ID and password that is specified in Step 2 of this task login to the solrServer WebSphere Application Server Administration Console.

Optional: If you have migrated WebSphere Commerce Search from a BOD-based search deployment, the password-related fields in the following files can be removed. They are replaced by the namespace bindings:

Files that can be removed
File path	Field path
All copies of solrconfig.xml under `WC_installdir`/instances/`instance_name`/search/solr/home	/config/requestHandler/lst/str[@name='httpBasicAuthPassword'] /config/requestHandler/lst/str[@name='httpBasicAuthUser']
`WC_eardir`/xml/config/com.ibm.commerce.catalog-ext/wc-search.xml	/common-http/@adminUserPassword
`WC_eardir`/xml/config/com.ibm.commerce.catalog-fep/wc-search.xml	/common-http/@adminUserPassword

What to do next

After securing the WebSphere Commerce Search server, complete the steps in Setting up the search index.