Concluding WebSphere security-related tips

We conclude this chapter by listing several tips that may come in handy as you continue your work with WAS ND7, specifically in the area of security. The tips included next are in no particular order.

Using wildcards in virtual hosts: never do it!

Many times, when creating virtual hosts, some administrators do not bother to fine-tune the default configuration for the hostname, focusing only on the port. When one clicks on the New button to create a new alias, one sees a page that contains the portion shown in the following screenshot:

Using wildcards in virtual hosts: never do it!

Never use the alias pair: host name "*"; port "80".

Ensuring best practice: set tracing from wide to specific search pattern

When turning on tracing in order to troubleshoot any type of problem in general and security in particular, one needs to keep in mind that WebSphere logging and tracing parses the trace string from left to right. This means that the trace string element at the left can be overridden by another element at its right. It is, therefore, best to place the more generic trace strings at the beginning and the most specific trace strings at the end.

For instance, if your WAS ND7 environment was using a custom J2C principal mapping module (cf. http://www14.software.ibm.com/webapp/wsbroker/redirect?version=compass&product=was-nd-dist&topic=rsec_pluginj2c) and you wanted to trace its activity to solve an issue, a possible helpful trace string would be similar to the one shown in the following screenshot.

Ensuring best practice: set tracing from wide to specific search pattern

Using a TAI such as SiteMinder: remove existing interceptors

WAS ND7 includes two trust association interceptors by default. If you are planning to use a different type such as the CA/Netegrity SiteMinder TAI it is highly recommended that you remove those configurations from the interceptors list. The following screenshot shows the default interceptors included.

Using a TAI such as SiteMinder: remove existing interceptors

One of the many reasons for removing the interceptors shown in the screenshot above is that when TAI is enabled and a different interceptor is configured and enabled, the SystemOut.log file would include exception messages thrown by these interceptor classes.

Once you have removed these class name definitions you can proceed to create a new definition for SiteMinder. An example of class name that could be used (for version 6.x) is com.netegrity.siteminder.websphere.auth.SmTrustAssociationInterceptor. Refer to Chapter 8, Secure Enterprise Infrastructure Architecture], under the section "Fine-tuning authorization at the WAS level", for configuration steps.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
18.216.183.63