©Copyright International Business Machines Corporation 2007. All rights reserved. U.S. Government Users Restricted Rights -- Use, duplication or disclosure restricted by GSA ADP Schedule Contract with IBM Corp.
NOTE: Before using this information and the product it supports, read the general information under Notices in this document.
Date: Wednesday, 25 June 2008
This fix pack corrects problems in IBM Tivoli Federated Identity Manager, Version 6.1.1. It requires that IBM Tivoli Federated Identity Manager, Version 6.1.1, be installed. After installing this fix pack, your Tivoli Federated Identity Manager installation will be at level 6.1.1.7.
This fix pack package contains:
This fix pack is distributed as an electronic download from the IBM Support Web Site.
This fix pack package supports the same operating system releases as the Tivoli Federated Identity Manager 6.1.1 release that are listed in the Hardware and software requirements document.
ATTENTION: In March 2007, the following versions of HP-UX Integrity on Itanium® were added to the list of supported operating systems:
If you installed Tivoli Federated Identity Manager on either of these versions, the administration console will display the version number "6.1.1.1." However, TFIMUI and a real fix pack must be installed to create the DE database, register TFIM 6.1.1 in the DE database as a deployed application, and register the fix pack as the installed level. Fix pack 1 bundles TFIMUI with it. If starting with a subsequent fix pack then TFIMUI must be downloaded from its download page and installed separately.
ATTENTION: In June, 2008, FP0007 added support for AIX 6.1, including WPARs, and Windows 2008 Server. The Windows 2008 Server certification did not include eWAS as eWAS was not supported there at that time.
6.1.1-TIV-TFIM-FP0001
6.1.1-TIV-TFIM-FP0003
6.1.1-TIV-TFIM-FP0005
Tivoli Federated Identity Manager consists of three components that can be installed separately:
All components must be at the same level. Therefore, if you install a fix pack for one of the components, you must install that fix pack for the rest of the components. Components at one release level are not guaranteed to interoperate with components at a different release or fix pack level.
The following problems are corrected by this fix pack. For more information about the APARs listed here, refer to the Tivoli Federated Identity Manager support site.
Be aware of the following considerations before installing this fix pack:
NOTE: Before installing this fix pack, be sure that you have reviewed the prerequisites in Before installing the fix pack.
After you have downloaded the fix pack, you need to perform a few steps before you can run the installation program.
jar
-xvf to unzip the file or download an unzip utility from the
HPUX Connect site.chmod +x *.sh
in the /script directory.
variables file
If security is enabled on the WebSphere Application Server
where Tivoli Federated Identity Manager is installed, you must provide
the appropriate passwords in the fix pack variables
file.
If security is not enabled, you can skip this step.
If the TFIM runtime is installed on the system, then the three TFIMRuntime passwords must be specified. If the TFIM console is installed on this system then the three TFIMConsole passwords must be specified. If both the runtime and the console are anywhere on this system then both sets of passwords must be given.
The variables file contains the following
passwords:
TFIMRuntimeWASPassword=TFIMRuntimeTrustedJksPassword=TFIMRuntimeJksPassword=TFIMConsoleWASPassword=TFIMConsoleTrustedJksPassword=TFIMConsoleJksPassword=To provide the appropriate passwords:
variables in the
fix pack /script directory. ATTENTION: If you added passwords to the variables
file, as described here, the passwords are in plain text in this file.
Be sure to remove the passwords from this file to prevent a security
breach.
Note that begining with patch 6.1.1-TIV-TFIM-LA0004 these instructions apply to each TFIM 6.1.1 instance on a system. The addition of the DE discriminant argument to the install script's execution (describe below under step 6) makes the work-around described under APAR IY98408 no longer necessary.
acsi service is running, as
follows:
ps -ef|grep acsi/usr/ibm/common/acsi/bin/acsisrv.sh
-start. Then ensure the service is running./script subdirectory of the directory
where you unzipped the fix pack zip file.install.bat on Windows systems./install.sh for AIX, Solaris, Linux, or HP-UXThis command has a single optional argument, the discriminant
under which the TFIM 6.1.1 instance being patched is registered in the
DE database. This argument defaults to /opt/IBM/FIM, the
discriminant used by TFIMUI 1.3 to register any TFIM 6.1.1 instance. So
for the simple case of patching a single TFIM 6.1.1 instance registered
by TFIMUI 1.3 no argument need be provided. For the more complex case,
where more than one TFIM 6.1.1 instance was registered using TFIMUI 1.3
with the procedure described under APAR
IY98408, contact support.
TFIMUI 1.3.0.1 uses a TFIM 6.1.1 instance's installation path as the discriminant when registering an instance, so use the installation path as the install command's argument in this case. If the installation path contains a space then it must be enclosed in double quotes.
ATTENTION: If you added passwords to the variables
file, as described in Preparing the variables
file, the passwords are in plain text in this file. Be sure to
remove the passwords from this file to prevent a security breach.
After you have successfully installed the fix pack, you will need to redeploy the Tivoli Federated Identity Manager runtime.
This task is identical to the deployment task you completed after initial installation of the management service and runtime component. For example, in a WebSphere cluster environment you must ensure that the new runtime component is deployed to each WebSphere node.
See the Runtime node management chapter of the Tivoli Federated Identity Manager Configuration Guide. Complete the topic "Deploying the runtime as a WebSphere Application Server application."
NOTES
Runtime Information
----------------------------------------------
Current deployed version 6.1.1.7 [070406a]
Note: The number within the brackets [070406a]
might be different from this example.
If you want to return your installation to the state it was in prior to installing the fix pack, you can uninstall the fix pack.
ATTENTION -- When you remove the management service and runtime component fix pack, you will lose any configuration (domains, federations, and so on) that you added after the fix pack was installed.
acsi is running, as
follows:
ps -ef|grep acsi/usr/ibm/common/acsi/bin/acsisrv.sh
-start. Then ensure the service is running. variables
file that was used when the fix pack was installed, edit the
file and add the appropriate passwords. Then save and close the file./script directory and the type the
uninstall command:
uninstall.bat on Windows systems./uninstall.sh for AIX, Solaris, Linux, or HP-UXThis command has a single optional argument, the discriminant
under which the TFIM 6.1.1 instance being patched is registered in the
DE database. This argument defaults to /opt/IBM/FIM, the
discriminant used by TFIMUI 1.3 to register any TFIM 6.1.1 instance. So
for the simple case of patching a single TFIM 6.1.1 instance registered
by TFIMUI 1.3 no argument need be provided. For the more complex case,
where more than one TFIM 6.1.1 instance was registered using TFIMUI 1.3
with the procedure described under APAR
IY98408, first execute /usr/ibm/common/acsi/bin/de_lsapp.sh.
This will list all application instances registered with DE and their
discriminants.
TFIMUI 1.3.0.1 uses a TFIM 6.1.1 instance's installation path as the discriminant when registering an instance, so use the installation path as the uninstall command's argument in this case. If the installation path contains a space then it must be enclosed in double quotes.
The uninstall process will remove the fix pack and revert to the previous versions of files that were changed by the fix pack.
For example, if you had installed fix pack 7 onto a Tivoli Federated Identity Manager 6.1.1.0 system, then after uninstalling fix pack 7 you would see the following:
Suite Name Version
----------------------------------------------------------
Tivoli Federated Identity Manager 6.1.1.0 [050428a]
Note: If you uninstalled the fix pack on an Itanium Tivoli Federated Identity Manager 6.1.1.0 system, the version number displayed will be 6.1.1.1 even after you uninstall the fix pack.
Runtime Information
----------------------------------------------
Current deployed version 6.1.1.0 [061110a]
Note: The number within the brackets [061110a]
might be different from this example.
Note: If you uninstalled the fix pack on an Itanium Tivoli Federated Identity Manager 6.1.1.0 system, the version number displayed will be 6.1.1.1 even after you uninstall the fix pack.
The product documentation for Tivoli Federated Identity Manager, Version 6.1.1, can be found on the information center for IBM Tivoli Federated Identity Manager .
Updates to the documentation follow:
To locate the white paper:
The TFIM Key Service manages keystores (for Signing/Encryption keys and for CA Certificates) and the keys and certificates in these keystores. However, the logical organization of the keys and certificates in keystores and the specification of keys and certificates using KeystoreName_AliasName as part of partner/federation configuration does not accurately represent how the TFIM Key Service actually manages the keys and certificates.
When the WebSphere Application Server (WAS) where the TFIM Runtime is installed is started, the TFIM Runtime will read in all keystore data as part of the initialization of the TFIM Key Service. When a new key/certificate for DN X is added via TFIM's console it is stored in the specified keystore on the disk. A WAS restart is needed for TFIM to read these keystores and build its maps of DNs and their keys/certs, making them available for use by TFIM's Key Service. The restart requirement is indicated by the message displayed, stating that a restart of the application server is necessary for the configuration changes to take effect.
When initializing the TFIM Key Service, each of the managed keystores is processed (in an unspecified order), reading in each key/cert in the keystore. Each new key/cert for a DN X is added to the DN-to-key/cert map as follows:
The keys/certificates are managed in this fashion to allow for "key rollover", which is the process that allows both a soon-to-expire key/cert and a new key/cert to reside in the keystores. Communications can occur using both keys/certificates while the new certificate is being disseminated to services that must use the certificate.
Consider the following scenario:
keystore1 (Signing/Encryption Keys)Keystores are processed in the order (first to last):
keyA1 DN:CN=A,O=Comp,C=US expires:Dec 31,2010 serial=1234
keyB1 DN:CN=B,O=Comp,C=US expires:Dec 31,2010 serial=2345
certstore1 (CA Certificates)
certA1 DN:CN=A,O=Comp,C=US expires:Dec 31,2010 serial=1234
certC1 DN:CN=C,O=Comp,C=US expires:May 31,2007 serial=4567
certC2 DN:CN=C,O=Comp,C=US expires:Dec 31,2007 serial=5678
keystore 2 (Signing/Encryption Keys)
keyB2 DN:CN=B,O=Comp,C=US expires:Dec 31,2010 serial=2345
certstore2 (CA Certificates)
certC3 DN:CN=C,O=Comp,C=US expires:Dec 31,2007 serial=5678
certstore1
keystore1
certstore2
keystore2
After the TFIM Key service processes all of the keystores, the reference for the the DN's in the example will be:
CN=A,O=Comp,C=US will map to the keystore1_keyA1
key alias, since the private/public key pair takes precedence over the
public certificate of certstore1_certA1.CN=B,O=Comp,C=US will map to the keystore1_keyB1
key alias since it was the first key found, and duplicate keystore2_keyB2
is discarded/ignored.CN=C,0=Comp,C=US will map to a chain with the certs certstore1_certC1
and certstore1_certC2. The duplicate cert certstore2_certC3
is discarded/ ignored.There are limitations with certain versions of the javax.net.ssl
shipped
with Java Secure Socket Extension (JSSE) that do not allow the
specification of a CA certificate stored
as a public/private key pair in a keystore that is for
Signing/Encryption
keys. In other words, a certificate that is to be used for validation
of a
server for an SSL connection cannot be stored as part of a
public/private
key pair in a keystore.
NOTE: This issue will only occur with the WAS 6.0.2.x version.
Referring to the example scenario above, this would
occur if the specification for a CA certificate was keystore1_key1
OR
certstore1_certA1, since the keystore1_key1
key would take precedence. (This
could be considered an improper configuration since a public
certificate should
only be stored as a public signer certificate in a trusted keystore
with CA
certificates, and secure communciations should not have a server,
signing with
a key, and a client, validating with a certificate, using the same DN.)
This limitation will result in an "unknown certificate" exception occuring when the TFIM runtime attempts to establish an SSL connection as part of an SSO protocol operation. The exception would be similar to the following:
[4/19/07 16:26:42:233 GMT] 00000048 HttpClientImp I com.tivoli.am.fim.soap.client.HttpClientImpl doRequest javax.net.ssl.SSLHandshakeException: unknown certificate
at com.ibm.jsse.bv.a(bv.java:67)
at com.ibm.jsse.bv.startHandshake(bv.java:163)
at com.ibm.net.ssl.www2.protocol.https.b.o(b.java:136)
at com.ibm.net.ssl.www2.protocol.https.i.connect(i.java:28)
at com.ibm.net.ssl.www2.protocol.http.bc.getOutputStream(bc.java:44)
at com.ibm.net.ssl.www2.protocol.https.l.getOutputStream(l.java:23)
at com.tivoli.am.fim.soap.client.HttpClientImpl.sendRequest(Unknown Source)
at com.tivoli.am.fim.soap.client.HttpClientImpl.doRequest(Unknown Source)
at com.tivoli.am.fim.soap.client.SOAPClientImpl.send(Unknown Source)
at com.tivoli.am.fim.saml.protocol.soap.SAMLSOAPClient.send(Unknown Source)
at com.tivoli.am.fim.saml.protocol.soap.SAMLSOAPClient.send(Unknown Source)
at com.tivoli.am.fim.saml20.types.SAML20HTTPSOAPResponseWriterImpl.sendSoapRequestMessage(Unknown Source)
at com.tivoli.am.fim.saml20.types.SAML20HTTPSOAPResponseWriterImpl.writeResponse(Unknown Source)
at com.tivoli.am.fim.saml20.protocol.actions.SAML20SendMessageAction.runProtocol(Unknown Source)
at com.tivoli.am.fim.fedmgr2.protocol.ProtocolActionChainImpl.runProtocol(Unknown Source)
at com.tivoli.am.fim.fedmgr2.proper.FederationManager.doChainAndResponseOnDelegate(Unknown Source)
at com.tivoli.am.fim.fedmgr2.proper.FederationManager.finishProcessingWithDelegateId(Unknown Source)
at com.tivoli.am.fim.fedmgr2.proper.FederationManager.processRequest(Unknown Source)
at com.tivoli.am.fim.fedmgr2.servlet.SSOPSServletBase.doRequest(Unknown Source)
at com.tivoli.am.fim.fedmgr2.servlet.SSOPSServlet.doGet(Unknown Source)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:743)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:856)
at com.ibm.ws.webcontainer.servlet.ServletWrapper.service(ServletWrapper.java:1282)
at com.ibm.ws.webcontainer.servlet.ServletWrapper.handleRequest(ServletWrapper.java:673)
at com.ibm.ws.webcontainer.webapp.WebApp.handleRequest(WebApp.java:2965)
at com.ibm.ws.webcontainer.webapp.WebGroup.handleRequest(WebGroup.java:221)
at com.ibm.ws.webcontainer.VirtualHost.handleRequest(VirtualHost.java:210)
at com.ibm.ws.webcontainer.WebContainer.handleRequest(WebContainer.java:1931)
at com.ibm.ws.webcontainer.channel.WCChannelLink.ready(WCChannelLink.java:84)
at com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.handleDiscrimination(HttpInboundLink.java:472)
at com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.handleNewInformation(HttpInboundLink.java:411)
at com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.ready(HttpInboundLink.java:288)
at com.ibm.ws.tcp.channel.impl.NewConnectionInitialReadCallback.sendToDiscriminaters(NewConnectionInitialReadCallback.java:207)
at com.ibm.ws.tcp.channel.impl.NewConnectionInitialReadCallback.complete(NewConnectionInitialReadCallback.java:109)
at com.ibm.ws.tcp.channel.impl.WorkQueueManager.requestComplete(WorkQueueManager.java:566)
at com.ibm.ws.tcp.channel.impl.WorkQueueManager.attemptIO(WorkQueueManager.java:619)
at com.ibm.ws.tcp.channel.impl.WorkQueueManager.workerRun(WorkQueueManager.java:952)
at com.ibm.ws.tcp.channel.impl.WorkQueueManager$Worker.run(WorkQueueManager.java:1039)
at com.ibm.ws.util.ThreadPool$Worker.run(ThreadPool.java:1470)
To eliminate this problem, the TFIM runtime should be configured to
use IBMJSSE2
which will support the extraction of a public certificate from a
private/
public key pair. A runtime custom property value can be set for the
runtime
node that experiences the error. This is done in the TFIM
administration
console by selecting "Domain Management"->"Runtime Node Management",
selecting the "Runtime Custom Properties" button, creating a property
with
a name of "com.tivoli.am.fim.soap.client.jsse.provider"
and a value of
"IBMJSSE2", and restarting the WAS server.
As of Patch 2, the TFIM runtime will use the IBMJSSE2 provider as
the default.
The runtime custome property com.tivoli.am.fim.soap.client.jsse.provider
can be used to specify IBMJSSE as the provider if desired.
The documentation for the TFIM staging tools that ship with the TFIM 6.1 and later releases has limited information about the valid properties that can be specified in the properties files that are passed as parameters to the staging utilitites. To address this issue, the TFIM Staging Utilities Reference white paper has been written to document the valid properties that can be specified in a properties file used with the TFIM staging utilitites. It can also be found under White Papers on the Tivoli Federated Identity Manager support site,
It is not possible to query the status of the FIM runtime
from the eWAS console. The following wsadmin commands
show how
to query the FIM runtime's
status as well as how to start and stop the FIM runtime from the
command line.
These commands assume the WAS server instance is named "server1".
wsadmin>$AdminApp listwsadmin>$AdminControl queryNames
type=Application,process=server1,name=ITFIMRuntime,*wsadmin>set appManager [$AdminControl queryNames
type=ApplicationManager,process=server1,*]wsadmin>$AdminControl invoke $appManager
stopApplication ITFIMRuntimewsadmin>set appManager [$AdminControl queryNames
type=ApplicationManager,process=server1,*]wsadmin>$AdminControl invoke $appManager
startApplication ITFIMRuntimelppchk -v
error on AIX (IY99366)The ISMP version used for fix pack 1 has a defect that can cause
AIX's
lppchk -v command to report the following kind of error:
# lppchk -v
lppchk: The following filesets need to be installed or corrected to bring
the system to a consistent state:
FIMLic 6.1.1.1 (COMMITTED)
This error reports an inconsistent update of the ODM database by ISMP. It does not affect the functioning of TFIM at all. A new version of the ISMP is being used as of patch 2 that will no longer make this error. However the error made by earlier installs will still remain.
The following script will eliminate the lppchk -v
error
by removing the offending fileset from the ODM database. It takes a
single
argument, the fileset name the lppchk -v complained
about,
e.g., FIMLic in the example above.
#!/bin/ksh
#echo "Removing LPP $1: Are you sure?" 1>&2
#read foo
#
#case "$foo" in
#yes|y)
# ;;
#*)
# exit 1
#esac
#
LPPID=`ODMDIR=/usr/lib/objrepos odmget -q "name = $1" lpp | grep lpp_id | awk '{print $3}'`
echo "
Removing files of LPP $1..."
lslpp -fcq $1 | awk '(FS = ":") {print "rm -f",$3}' | sh -x 2>&1
echo "
Removing $1 from ODM (inventory,product,history,lpp,vendor)"
ODMDIR=/usr/lib/objrepos odmdelete -o inventory -q "lpp_id = $LPPID"
ODMDIR=/usr/lib/objrepos odmdelete -o product -q "lpp_name = $1"
ODMDIR=/usr/lib/objrepos odmdelete -o history -q "lpp_id = $LPPID"
ODMDIR=/usr/lib/objrepos odmdelete -o lpp -q "name = $1"
ODMDIR=/usr/lib/objrepos odmdelete -o vendor -q "lpp_id = $LPPID"
ODMDIR=/etc/objrepos odmdelete -o inventory -q "lpp_id = $LPPID"
ODMDIR=/etc/objrepos odmdelete -o product -q "lpp_name = $1"
ODMDIR=/etc/objrepos odmdelete -o history -q "lpp_id = $LPPID"
ODMDIR=/etc/objrepos odmdelete -o lpp -q "name = $1"
ODMDIR=/etc/objrepos odmdelete -o vendor -q "lpp_id = $LPPID"
ODMDIR=/usr/share/lib/objrepos odmdelete -o inventory -q "lpp_id = $LPPID"
ODMDIR=/usr/share/lib/objrepos odmdelete -o product -q "lpp_name = $1"
ODMDIR=/usr/share/lib/objrepos odmdelete -o history -q "lpp_id = $LPPID"
ODMDIR=/usr/share/lib/objrepos odmdelete -o lpp -q "name = $1"
ODMDIR=/usr/share/lib/objrepos odmdelete -o vendor -q "lpp_id = $LPPID"
The behavior demonstrated when a session has timed out
during an SSO operation has been modified. Previously,
a blank page was returned when the session had expired.
Changes made under the APAR IY97194 have changed this
behavior so that an error page, generated from the HTML
template page protocol_error.html, will be returned that
will display an exception indicating that a session
timeout has occured.
The default error page returned would display like shown here:
An error occurred fulfulling the current request to
http://www.myidp.com:9080/sps/saml20Fed/saml20/auth.
This error was caused by an internal/unexpected error on the invoked
protocol module leading to the exception displayed below.
com.tivoli.am.fim.fedmgr2.exception.DelegateRuntimeExceptionWrapperException: +SessionTimeoutException
com.tivoli.am.fim.fedmgr2.exception.FMProcessingException: com.tivoli.am.fim.fedmgr2.exception.DelegateRuntimeExceptionWrapperException: +SessionTimeoutException
at com.tivoli.am.fim.fedmgr2.proper.FederationManager.finishProcessingWithDelegateId(FederationManager.java:353)
at com.tivoli.am.fim.fedmgr2.proper.FederationManager.processRequest(FederationManager.java:265)
at com.tivoli.am.fim.fedmgr2.servlet.SSOPSServletBase.doRequest(SSOPSServletBase.java:111)
at com.tivoli.am.fim.fedmgr2.servlet.SSOPSServlet.doGet(SSOPSServlet.java:130)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:743)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:856)
at com.ibm.ws.webcontainer.servlet.ServletWrapper.service(ServletWrapper.java:989)
at com.ibm.ws.webcontainer.servlet.ServletWrapper.handleRequest(ServletWrapper.java:501)
at com.ibm.ws.wswebcontainer.servlet.ServletWrapper.handleRequest(ServletWrapper.java:464)
at com.ibm.ws.webcontainer.webapp.WebApp.handleRequest(WebApp.java:3168)
at com.ibm.ws.webcontainer.webapp.WebGroup.handleRequest(WebGroup.java:254)
at com.ibm.ws.webcontainer.WebContainer.handleRequest(WebContainer.java:811)
at com.ibm.ws.wswebcontainer.WebContainer.handleRequest(WebContainer.java:1433)
at com.ibm.ws.webcontainer.channel.WCChannelLink.ready(WCChannelLink.java:96)
at com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.handleDiscrimination(HttpInboundLink.java:465)
at com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.handleNewInformation(HttpInboundLink.java:394)
at com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.ready(HttpInboundLink.java:274)
at com.ibm.ws.tcp.channel.impl.NewConnectionInitialReadCallback.sendToDiscriminators(NewConnectionInitialReadCallback.java:214)
at com.ibm.ws.tcp.channel.impl.NewConnectionInitialReadCallback.complete(NewConnectionInitialReadCallback.java:113)
at com.ibm.ws.tcp.channel.impl.AioReadCompletionListener.futureCompleted(AioReadCompletionListener.java:152)
at com.ibm.io.async.AbstractAsyncFuture.invokeCallback(AbstractAsyncFuture.java:213)
at com.ibm.io.async.AbstractAsyncFuture.fireCompletionActions(AbstractAsyncFuture.java:195)
at com.ibm.io.async.AsyncFuture.completed(AsyncFuture.java:136)
at com.ibm.io.async.ResultHandler.complete(ResultHandler.java:194)
at com.ibm.io.async.ResultHandler.runEventProcessingLoop(ResultHandler.java:741)
at com.ibm.io.async.ResultHandler$2.run(ResultHandler.java:863)
at com.ibm.ws.util.ThreadPool$Worker.run(ThreadPool.java:1469)
Caused by: com.tivoli.am.fim.fedmgr2.exception.DelegateRuntimeExceptionWrapperException: +SessionTimeoutException
at com.tivoli.am.fim.fedmgr2.proper.FederationManager.finishProcessingWithDelegateId(FederationManager.java:351)
... 26 more
Caused by: java.lang.RuntimeException: SessionTimeoutException
at com.tivoli.am.fim.fedmgr2.proper.FederationManager.finishProcessingWithDelegateId(FederationManager.java:338)
... 26 more
The SAML claims should be part of the STS Universal User so that
they can be referenced from the XSLT mapping modules but are not. The
fix to this defect corrects this oversight. The claims are made
available by defining the TFIM custom runtime property sts.add.saml.claims.
This is done in the TFIM administration console by selecting "Domain
Management"->"Runtime Node Management", selecting the "Runtime
Custom Properties" button, creating a property with a name of "sts.add.saml.claims"
and a value of "true", and restarting the WAS server.
NOTE: This work-around has ben superseded by the new
registerTFIMInstall.sh(.bat) script
introduced in TFIMUI 1.3.0.1 and the new
patch install command introduced
with patch 6.1.1-TIV-TFIM-LA0004. See the TFIMUI 1.3.0.1 documentation
on the
Tivoli Federated Identity Manager support site
and the new running the update
installer instructions
above.
Due to interactions between assumptions made by the fix pack installer and the operation of the Deployment Engine component embedded in it, the standard instructions for applying a fix pack do not work when patching the 2nd-Nth TFIM 6.1.0, TFIM 6.1.1, or TFIMBG 6.1.1 instance on a system. To simplify the wording, the following work-around describes patching just the 2nd instance of TFIM 6.1.1, but the instructions apply equally well to patching the 2nd-Nth instances of either TFIM 6.1.0, TFIM 6.1.1, or TTFIMBG 6.1.1. Also, the following two italicized words are used below as abbreviations for the following two directory paths:
TFIMUI-dir2nd-TFIM-dirThe following steps
must be executed in order to apply a fix pack or LA patch to the 2nd
TFIM 6.1.1 instance on a system.
Steps (7) and (12) apply to a Unix/Linux installation where the 2nd
TFIM instance's
WAS application server did not use localhost but
used a separate,
unique IP address instead.
Note that if the WAS application server of the first TFIM instance
to be patched
did not use localhost but used a separate,
unique IP address instead then the manipulation of localhost
described by
step (7) must be performed before
running the update installer
and
step (12) must be performed after
running the update installer.
On Windows, replace the .sh file extension in these
steps with .bat.
Find the file TFIMUI-dir/DE/test/selectedfeatures.
Add/remove selectedFeature lines in this file
until there's one for each feature in the 2nd TFIM. Check the 2nd-TFIM-dir/etc/version.properties
file for a definitive list of the 2nd TFIM's features.
Each feature line in the 2nd-TFIM-dir/etc/version.properties
file is of the form
itfim.build.version.featurename=6.1.1.n
where featurename is one of the choices in the first column of the table below and n is the installed fix pack number.
Each feature line in the TFIMUI-dir/DE/test/selectedfeatures
file is of the form
selectedFeature\#RootIUTypeID[cc05dc31804627bba6e6661c48bf1a81,6.1.1.0]1\featurename=true
where featurename is one of the choices in the second column of the table below.
The mappings from the 2nd-TFIM-dir/etc/version.properties
feature names to the TFIMUI-dir/DE/test/selectedfeature
feature names are as follows:
2nd-TFIM-dir/etc/version.propertiesfeature name |
TFIMUI-dir/DE/test/selectedfeaturesfeature name |
|---|---|
| ewas | #FIMEwasFeat |
| fimpi | #FIMIISPlugFeat |
| mgmtcon | #FIMConsoleFeat |
| rte-mgmtsvcs | #RunTimeAndManagementFeat |
| wsprov | #WSProvisioningFeat |
| wssm | #FIMWssmFeat |
Fixup the last line in the TFIMUI-dir/DE/test/selectedfeatures
file. This line looks like
Variable\#RootIUTypeID[cc05dc31804627bba6e6661c48bf1a81,6.1.1.0]\#InstallLocation=some-TFIM-dir
Replace the existing some-TFIM-dir with the
installation directory path of the 2nd TFIM instance.
Change the -r option in the last line of the TFIMUI-dir/DE/test/install.sh
file from whatever TFIM installation directory is there (/opt/IBM/FIM
initially) to the installation directory path of the 2nd TFIM instance.
On Unix/Linux, execute the following command: chmod a+x TFIMUI-dir/DE/test/*.sh.
Execute TFIMUI-dir/DE/test/install.sh to
register the 2nd TFIM in the DE database.
If the WebSphere application server hosting the TFIM component
is not listening on localhost, then
/etc/hosts file, moving localhost
to the line that defines the IP address used by the 2nd TFIM's WAS
application server (or create such a line).acsi service.Go to the unzipped fix pack's files, find the script/
directory.
Change the -r option in the last line of the script/install.sh
file from whatever TFIM installation directory is there (/opt/IBM/FIM
initially) to the installation directory path of the 2nd TFIM instance.
Fixup the passwords in the script/variables file
to be those of the 2nd TFIM.
Execute the script/install.sh file to apply the
fix pack to the 2nd TFIM.
If the WebSphere application server hosting the TFIM component
is not listening on localhost, then
/etc/hosts file made in
step (7).acsi service.
The installer sets the wrong com.tivoli.am.fim.was.home
value when the product
is installed on Windows. Here is an example of an incorrect entry in
the
software.properties file (the file is installed in the
directory
/<TFIM-installation-directory>/pkg):
com.tivoli.am.fim.was.home=C:\Program FilesIBMWebSphereAppServer
The value should be:
com.tivoli.am.fim.was.home=C:/Program Files/IBM/WebSphere/AppServer
The TFIM runtime can be successfully deployed, but users are never
able to select the
runtime to configure it from the runtime node management panel of the
TFIM administration
console. The software.properties file must be manually
edited to fix the
incorrect entry so that it has the correct slashes ('/') in the path
value.
NameID
NameQualifier for SAML 2.0 SSO (IZ00738) The SAML 2.0 account linkage uses the value of the NameID
NameQualifier field, if available, to store the alias provided
by the federation partner in the alias service. (If the assertion does
not have a NameID NameQualifier, the Issuer
value
is used). When later looking up the account as part of a SAML 2.0
Single
Sign On (SSO) operation, the Issuer is used. The SAML 2.0
core
specification indicates that the Issuer and NameID
NameQualifier should be identical unless the assertion has been
re-issued (from 8.3.7 of the
saml-core-2.0-os.pdf
document:
The element'sNameQualifierattribute, if present, MUST contain the unique identifier of the identity provider that generated the identifier (see Section 8.3.6). It MAY be omitted if the value can be derived from the context of the message containing the element, such as the issuer of a protocol message or an assertion containing the identifier in its subject. Note that a different system entity might later issue its own protocol message or assertion containing the identifier; theNameQualifierattribute does not change in this case, but MUST continue to identify the entity that originally created the identifier (and MUST NOT be omitted in such a case).
It therefore appears that under unusual circumstances the Issuer
and
NameID NameQualifier values could be different. In this
case, the
SSO operation will fail to retrieve the alias that was set at the
account linkage step.
To support this scenario, the TFIM product behavior has been
changed to use the NameID NameQualifier value (if one
is present in the assertion) instead of the Issuer to
retrieve the alias. If a customer wishes to have the previous TFIM
behavior, a new TFIM custom property, sts.use.issuer.saml20.sso,
has been added. The new property can be defined to true
in order
to have the alias lookup, performed when doing an SSO operation, use
the
Issuer value instead of the NameID NameQualifier
value.
The custom property can be set in the TFIM administration console by
selecting "Domain Management"->"Runtime Node Management", selecting
the "Runtime Custom Properties" button, creating a property with a
name of "sts.use.issuer.saml20.sso" and a value of
"true", and restarting the WAS server.
If the new custom property is set, or a NameID NameQualifer
element is
not present in the assertion, then the Issuer value is
used as before
when retrieving the alias when performing the SSO operation.
ACUINI0012I Deployment Engine Installation Failed!
Causes:
com.ibm.ac.si.install.InstallFailedException:;com.ibm.ac.si.install.UnrecognizedOSException:
ACUINI0045E The current OS is unrecognized by this application: Name =
Linux ; Architecture = ppc ; Version = 2.6.5-7.244-pseries64
linux_ppc_install.bin and getting
this error, perform the following steps.
/opt/IBM/FIMUI/DE/si_inst.sh using a
64-bit JVM. This script, which installs the DE and the acsi
code, uses the java on $PATH, and the java
on $PATH is normally the 64-bit JVM that came with SLES9
for PPC64 unless $PATH or the soft-link at /usr/lib/java
has been changed. It is possible to change the JVM used through the
script's -javeHome path-to-JVM option.
To determine whether a particular java is
32-bit or 64-bit, first cd into the directory containing
the java executable to be used, then execute
# file java
The output will clearly state whether it is a 32-bit or a 64-bit executable.
/opt/IBM/FIMUI/DE/test/install.sh to
register TFIM 6.1.1 with the DE's database./scripts/install.sh
to install the fix pack. Be aware of this script's need for Java 1.5
described below under APAR IZ06004.As of patch LA0004 the complex work-around for this defect, documented under APAR IY98408, is no longer necessary. Together, the fix pack installer of LA0004 and the new TFIMUI 1.3.0.1 implement a fix for this defect that makes patching the 2nd-Nth TFIM instance on a system much simpler
The essence of the defect was that TFIMUI 1.3 always registered a
TFIM 6.1.1
instance in the Deployment Engine (DE) database using the same key,
making it impossible
to discriminate between multiple instances on the same system. The
Deployment Engine
uses a two-part key when registering an application instance in its
database. The
first part is an application-specific GUID. The second part is an
instance-specific
discriminant, an arbitrary string that should be unique for each
instance on a system.
Unfortunately, TFIMUI 1.3 always used /opt/IBM/FIM as the
discriminant.
The fix to this defect was to have TFIMUI 1.3.0.1 use the installation path of the TFIM 6.1.1 instance being registered as the discriminant. On Windows the 8.3-form of the installation path is used with a lower-case drive letter. This simple change, while not changing the installation of TFIMUI at all, has several implications.
DE/test directory, registerTFIMInstall.bat(.sh).
Instead of reinstalling TFIMUI for each of the 2nd-NTH instances, this
script must be executed. It, too, has the same single argument as the
"install" scripts./opt/IBM/FIM, the fix
pack install scripts' argument is optional, defaulting to /opt/IBM/FIM.
This default will leave the patching of most existing TFIM 6.1.1
installations unchanged.acsi
script de_lsapp -verbose. This .bat(.sh)
script is found in /usr/ibm/common/acsi/bin on a Unix
system or in c:\Program Files\IBM\Common\acsi\bin on a
Windows sytem. It lists all registered applications and their
discriminants. Note that if multiple WAS instances on a single system are differentiated through the use of a different IP address for each instance, then steps (7) and (12) of the work-around described under APAR IY98408 are still required. The /etc/hosts file must be edited before and after applying a fix pack as the steps describe.
Caused by: java.lang.RuntimeException:
com.ibm.websphere.management.exception.ConnectorException: ADMC0053E:
The system cannot create a SOAP connector to connect to host localhost
at port 18881 with SOAP connector security enabled.
followed by (a bit farther down)
Caused by: com.ibm.websphere.management.exception.ConnectorNotAvailableException: [SOAPException: faultCode=SOAP-ENV:Client; msg=Error opening socket: javax.net.ssl.SSLHandshakeException: com.ibm.jsse2.util.h: No trusted certificate found; targetException=java.lang.IllegalArgumentException: Error opening socket: javax.net.ssl.SSLHandshakeException: com.ibm.jsse2.util.h: No trusted certificate found]
script.jacl:
set security_item [$AdminConfig list Security]
set argv0 [lindex $argv 0]
set value null
if {[regexp $argv0 enable]} { set value true }
if {[regexp $argv0 disable]} { set value false }
if {[regexp $value null]} {
puts "Wrong parameter, use enable / disable"
return
}
$AdminConfig modify $security_item [list [list enabled $value]]
$AdminConfig save
then executing it from the wsadmin of the
console's WAS/eWAS as follows:
wsadmin -username was-adminname -password was-password -f script.jacl [enable | disable]
wsadmin -username was-adminname -password was-password -f script.jacl [enable | disable]
Caused by: java.lang.UnsupportedClassVersionError:
javax/management/NotificationListener (Unsupported major.minor version
49.0)
/scripts/install.sh
to install a fix pack. This script runs the TFIM fix pack installer
which requires Java 1.5.SI_JAVA_HOME
on line 44 of /var/ibm/common/acsi/setenv.sh. The normal
installation of TFIMUI points this at a Java 1.5 JVM so there is
usually no problem. The work-around for IZ01850 can leave this variable
pointing at a Java 1.4.2 JVM. The TFIM fix pack installer requires Java
1.5.The current TFIM FSSO documentation does not sufficiently document the limitations of the TFIM alias service.
An alias is created when a user agrees to federate their
service provider account with an associated account on an
identity provider. At the end of the federate action an
LDAP alias service on the identity provider will include a
secselfalias and an LDAP alias service on the service
provider
will have a secpartneralias.
Note that only 1 account on a service provider should be
federated to any given identity provider account. Multiple
accounts on different service providers can be federated to
the same account on the identity provider, but only one
account on any given service provider should be federated
with any given account on the identity provider. The
secselfalias generated for a partner, as described in the
product
documentation (Tivoli Federated Identity Manager
Single Sign-on Guide, Chapter 8. Alias Service) contains
as part of the value the ProviderId value of the partner
(service provider) that it is associated with. The rest of
the value of the secselfalias is the randomly generated
alias, so if there are multiple aliases for the same
ProviderId, there is no mechanism for determining which
alias should be provided in an assertion generated for
consumption by that partner.
For example, a user John Smith has accounts jsmith and
jsmith1 on Service Provider 1, johns on
Service Provider 2,
and JohnSmith on the Identity Provider. Both jsmith
and
johns can be federated with the JohnSmith
account, but only
jsmith or jsmith1 should be federated with
the JohnSmith
account. Otherwise, the principal specified in the
generated assertion by the identity provider is indeterminate,
since there are multiple accounts from the same service
provider that are federated with the same identity provider
account. Once John Smith has authenticated to Identity
Provider, and wishes to access resources on Service Provider
1, the alias that is stored in the alias service associated
with the account JohnSmith for Service Provider 1 is
provided
in the assertion sent to Service Provider 1. If there are
multiple aliases for Service Provider 1, it is undefined
which alias will be provided by Identity Provider in the
generated assertion.
The alias values can be updated by performing a NameID update.
The update will change the secselfalias of the identity
provider
and secpartneralias of the service provider. This action
can be
initiated at either the identity provider or the service provider.
The secselfalias generated for a partner, as described
in the
product
documentation (Tivoli Federated Identity Manager
Single Sign-on Guide, Chapter 8. Alias Service), contains as
part of the value
the ProviderId value
of the partner that it is associated with. The rest of the value
of the secselfalias is the randomly generated alias, so
if there are
multiple aliases for the same ProviderId, there is no
mechanism for
determining which alias should be provided in an assertion generated
for consumption by that partner.
Intermittent failures validating messages received can occur in a TFIM environment if the JVM does not have the fix for IY93387.
Errors in the trace file indicate a falure to validate the received XML:
[9/7/07 17:05:27:807 EST] 0000002d KessServiceJk 3
com.tivoli.am.fim.kess.service.jks.worker.impl.KessServiceJksWorkerImpl
validateXML The certificate retrieved for xml signature validation was:
[
[
Version: V3
Subject: CN=Certificate Name :7100000475, O=Company, C=US
Signature Algorithm: SHA1withRSA, OID = 1.2.840.113549.1.1.5
Key: IBMJCE RSA Public Key:
modulus:
<...modulus value removed...>
public exponent:
65537
Validity: [From: Wed Nov 01 14:28:26 EST 2006,
To: Sun Mar 30 11:46:30 EST 2008]
Issuer: CN=TEST Cert, O=TestCert Company, C=US
SerialNumber: [1162351707]
<...cert information removed for brevity ...>
[9/7/07 17:05:27:813 EST] 0000002d KessServiceJk 3
com.tivoli.am.fim.kess.service.jks.worker.impl.KessServiceJksWorkerImpl
validateXML
Signature was NOT valid on the XML document.
Core Validity: false
SignedInfo: false
Msg: SignatureValue mismatched.
...
This problem is resolved by the APAR IY93387 and is fixed in the JVM 1.4.2 SR9 and JVM 5.0 SR4.
The Java SDK 1.4.2 SR9 fix level can be downloaded from its download page.
The Java SDK 1.5 SR5 fix level can be downloaded from download page.
Sometimes the fix pack installation script install.sh
fails with the following
lines in its output
[ManageIUInstaller has received a ActionErrorEvent: javaCustomCheckWasConnection ]
[ManageIUInstaller has received a change Event: RequestState[7] ]
[Total Ops: 4, Total Completed: 1, Total Errors: 1]
There are several possible reasons for this ActionErrorEvent.
By cd-ing
into the acsi log directory and grepping the de_trace.log
file
for the words "Caused by" the precise
reason for the failure can be determined. The failure of interest here
shows lines like the following:
local:/data # cd /usr/ibm/common/acsi/logs/root/
local:/usr/ibm/common/acsi/logs/root # grep 'Caused by' *
de_trace.log:Caused by: com.ibm.ac.si.ap.action.ActionException:
ACUASI0217E Error accessing directory /opt/IBM/FIMsp/etc/fpactions
de_trace.log:Caused by: java.io.FileNotFoundException:
../FILES/customactions/actions.zip
(No such file or directory)
This error is a result of executing the script install.sh
from a directory
other than the one where the script resides. This script usually
resides in the
<fix-pack-directory>/script directory. You
must cd
into this directory before executing install.sh.
This restriction is removed in patch LA0004.
The fix pack installation of the TFIM runtime must connect to a
WAS's SOAP port in order to deploy
the runtime. The fix pack installer acquires its SOAP port value from
the following line
in the
/<TFIM-installation-directory>/pkg/software.properties
file
of the TFIM instance being patched:
was.soap.port=8880
This value was placed there when the TFIM instance was installed.
For the connection to be successful the WAS being deployed to must
still be using that SOAP port.
If it is not then the TFIM fix pack installation fails with lines like
the following
in the de_trace.log file:
Caused by:
com.ibm.websphere.management.exception.ConnectorNotAvailableException:
[SOAPException:
faultCode=SOAP-ENV:Client; msg=Error parsing HTTP status line
"...":
java.util.NoSuchElementException;
targetException=java.lang.IllegalArgumentException:
Error parsing HTTP status line "...": java.util.NoSuchElementException]
where the "..." are binary bytes from the bad status
line.
The SOAP port being used by the WAS is reported at startup in the SystemOut.log
file as follows:
ADMC0013I: The SOAP connector is available at port 8886
If the two SOAP port values differ, then change the value in TFIM's
software.properties file to agree with the port being used
by WAS and
reapply the fix pack.
Configuring the TAM Login Module
The following steps should be performed in order to use the TAM Login Module, shipped with the TFIM product, with the test application shipped with TFIM, the echoapplication program.
In the WebSphere Application Server (WAS) with the echoapplication installed and running, create a JAAS configuration. In the WAS administration console, browse to "Security" -> "Secure administration, applications and infrastructure".
Under the "Authentication" section on the right side of the panel expand the "Java Authentication and Authorization" section, and select the "System logins" link.
Add a new entry for itfim.wssm.tam, then select the new module and specify the "JAAS login modules" with the "Module class name":
com.tivoli.am.fim.wssm.loginmodules.TAMLoginModule
Extension
For EchoServiceUsername port component binding, edit the caller part and set:
URI: <nothing> Local name: http://ibm.com/2004/01/itfim/ivcred Binding
In the EchoServiceUsername port component binding, change
the "Token consumer" jaas.config name to:
system.itfim.wssm.tam
Save the new application for later installation into WAS.
In <wssm_install_root>/wssm.properties, add :
pdjrte.configuration=<path-to-TAM-config-file>
For example, this can be the same file as used for the TFIM runtime configuration, i.e.:
/opt/IBM/WebSphere/AppServer/profiles/AppSrv01/config/itfim/dp-autotest-server1/nodes/dp-autotestNode01Cell/dp-autotestNode01/server1/amconfig.conf
This setting is used by the TAM login module.
In the TFIM trust service, set the application trust chain to issue TAM credentials using the TAM credential module. If an application trust chain was previously created, for example a chain was already created issuing SAML 2.0 credentials, then change the application trust chain to issue TAM credentials rather than SAML 2.0 credentials, for example by editing the application chain and changing the last module from SAML 2.0 to TAM credential module.
Install the new version of the application into WAS and restart WAS.
Using the echoclientapplication, select UsernameToken,
and press "WhoAmI". You should see that the JAAS subject
has a private WSSMCredential containing the BinarySecurityToken
representing the TAM credential. It is a simple matter to read this in
and create a TAM PDPrincipal from that (for more information, see the DeveloperWorks
tutorial).
"WhoAmI" on the browser :