|
Problem |
If you enable trust association between WebSphere®
Application Server V4.0 and a proxy server other than Tivoli® WebSEAL, for
which a trust association interceptor class is provided, you must
implement your own custom interceptor class. When using a configuration
file for a custom interceptor class,
WebSphereBaseTrustAssociationInterceptor must be extended. |
|
Solution |
Section 5.6.3 of the WebSphere
Application Server V4.0 information center documents how to do this.
It should be noted, however, that if you add a line in the
trustedservers.properties to use a custom configuration file for the
interceptor, you MUST extend the abstract class
WebSphereBaseTrustAssociationInterceptor in addition to
implementing the TrustAssociationInterceptor interface.
For example, your trustedservers.properties file might look something
like this:
com.ibm.websphere.security.trustassociation.enabled=true
com.ibm.websphere.security.trustassociation.types=myproxy
com.ibm.websphere.security.trustassociation.myproxy.interceptor=myinterceptor
com.ibm.websphere.security.trustassociation.myproxy.config=myproxyconfig
The last line specifies a configuration file for the interceptor class.
When the abstract class is not implemented, the WebSphere code that
initializes the trust association interceptor issues an exception, then
DISABLES trust association. The tracefile says that the interceptor class
was successfully loaded, but gives no indication that trust association is
disabled. You notice only that trust association does not work properly.
For instance, WebSphere might try to authenticate users for a secured
resource, which should be done by the proxy server.
To fix this, you must implement the abstract class indicated above. The
tracing for trust association initialization is improved in WebSphere
Application Server V4.0.3 and subsequent releases to help you better debug
this if you encounter this problem. |
|
|
|
|
|
|
|