©Copyright International Business Machines Corporation 2008.
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.
This fix pack corrects problems in IBM Tivoli Federated Identity
Manager (Federated Identity Manager), Version 6.2.0. It requires that
Federated
Identity Manager, Version 6.2.0, be installed. After installing
this fix pack, your Federated
Identity Manager installation will be at level 6.2.0.2.
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
that are listed
in the
Hardware
and software requirements topic
for Federated Identity Manager Version 6.2.0.
ATTENTION: In April 2009, FP0002 added support for z/OS Release 1
Version 10.
ATTENTION: In April 2009, FP0002 added support for WebSphere
Application Server Release 7.0 Fix Pack 3 (release date March 27, 2009)
Federated Identity Manager consists of the following components that
can be installed separately:
If this is the first time you are applying the fix pack to Federated
Identity Manager, you must download and install the enablement fix for
Tivoli Federated
Identity Manager.
NOTE: Before installing this fix pack, ensure that you
have reviewed the prerequisites in Before
installing
the fix pack.
If security is enabled on the WebSphere Application Server
where Federated Identity Manager is installed, you must set
the appropriate password values in the fim.appservers.properties
file before you can
apply the fix pack.
If security is not enabled, you can skip this step.
After you install the fix pack, you need to redeploy the Tivoli
Federated
Identity Manager runtime. This task is identical to the deployment task
you completed after the
initial installation of the management service and runtime components.
In a WebSphere
cluster environment, you must ensure that the new runtime component is
deployed to each WebSphere node.
Use the following procedure to deploy the updated Federated Identity
Manager runtime:
After you install the fix pack and redeploy the Tivoli Federated
Identity Manager runtime you must re-publish the plug-ins to the
runtime and reload the configuration.
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.
Attempts to pass identifier_select as the claimed identifier to the
TFIM OpenID IDP fail. Despite the fact that TFIM doesn't support XRDS
publication directly, it should handle the processing of OP identifier
authentications. To maintain the consistency
behavior, this APAR adds the support for OP-identifier authentication
with a configuration option to enable or disable it. By default it's
disabled. To enable this fix, a manual change must be made to the <was_config_root>/itfim/<tfim_domain>/etc/feds.xml
on the identity provider to add this parameter:
If OPENID.IPSupportOPIdentifier is true, then this
additional parameter MUST also be included:
The value should be a string template which contains the
@ID@ pattern which will be replaced with the user's
username. Note this is very similar to the existing
Identity Pattern parameter that is used to verify
regular claimed identifier logins (not OP-identifier
logins), EXCEPT that the OPENID.IPGeneratedClaimedIDPattern
parameter is NOT a regular expression it is just a
template which must include the replacement macro @ID@.
The closing macro delimiter, @OPTIONAL_ATTRIBUTE@, is missing from
the consent.html template causing the label field for the optional
attributes not to render correctly. To work around this problem, go to
the page template <fim_install_root>/pages/<lang>/openid/consent.html
and make the following change:
After making the change, use the console to "Publish Pages", and
"Reload Configurations" for the change to take effect.
There is a 4x performance hit on single sign-on in scenarios where
a relying-party white lists an OpenID identity provider that should be
avoided. This APAR provides two configuration parameters to control the
performance issues, and they are disabled by default.
The first parameter, "OPENID.DiscoveredInformationExpirationSeconds",
has a value which is the number of seconds for which discovered
information for any OpenID user-supplied identifier should be cached.
If this value is less than or equal to zero, the data is not cached at
all (default). controls a cache for discovered information, and should
only be used when the same OP identifier login is frequently being used
by a majority of the end-users of the system (such as might be done in
an intranet deployment).
The second parameter, "OPENID.SkipClaimedIdDiscovery", has a true/false
value with the default being false. It controls whether or not
verification will be done on claimed identifiers when an OP-identifier
login is performed. This should ONLY ever be set to true in an
environment where the OP's that may be used with the relying party are
trusted, otherwise a security exposure exists. Again, this is typical
in an intranet environment.
A good reference for the location to add them is to search for the
existing parameter "OPENID.AuthenticationMode" and add them adjacent to
that.
For the SubjectConfirmationMethod (SCM) to be issued correctly the
client when sending the RequestSecurityToken (RST) will need to sign
the RST request and include a KeyInfo that can be used for the SCM. To
exploit the holder-of-key capability, the XSLT mapping rules must be
updated.
The STSUU attribute in the example below is not new but is included for
completeness. The example below is for SAML 1.0 and 1.1 Assertions.
Another way to exploit the holder-of-key capability is to pass it as a
claim in the RST.
The example below is for SAML 1.x:
In TFIM service provider(SP) deployments of SAML 1.x when signatures
are not used in assertions, it is often required to definitively
identify to an application from which identity provider (IdP) source a
credential has come. To satisfy this requirement, this fix inserts new
attirbutes into the Claims element for SAML 1.x service provider
federations that use browser artifact profile. The new attributes are
called ArtifactSourceID and ArtifactResolutionServiceEndpoint. The new
Claims element attributes will be included in the RequestSecurityToken
message that is sent to the SP trust service during single sign-on.
Mapping rules on the SP can use these values to map to an expected
Issuer URL and perform that check in the mapping rule and throw an
exception if a bad Issuer is detected.
To check for the new attributes ArtifactSourceID and
ArtifactResolutionServiceEndpoint of the new SAML claims, you can do
the following:
The TFIM 6.1.1 documentation lists the supported user
registries in the "User Registry support" section of the
"Hardware
and Software Requirements" document.
This document lists support for Novell eDirectory 8.6.x
and Novell eDirectory 8.7.x. This section does not list
Novell eDirectory 8.8.x, because eDirectory 8.8 was not
available at the time and the TAM Base product did not claim
support for this level yet. However, TAM claimed support
for Novell eDirectory 8.8 in the TAM
Base 6.0.0 FP0009 README.
Based upon this information, it would seem that TFIM would
support eDirectory 8.8.x as a user registry. Support for
eDirectory 8.8.x was verified, but in the process it was
found that additional configuration steps for eDirectory
were required in order to be used by TFIM successfully. These
configuration steps are not in the current documentation,
so a Tech Note has been written and published that documents
the required actions to configure the Novell eDirectory to
be a supported TFIM user registry.
This TechNote MUST be consulted and followed before
attempting to use the Novell eDirectory as a TFIM user
registry.
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".
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
- Import the echoapplication.ear into Rational Application
Developer or WebSphere Application Server Toolkit. Then modify:
-
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).
Here's the text from a "WhoAmI" on the browser :
The web service JAAS subject contains:
Principals:
Principal: dp-autotest.dp.gc.au.ibm.com:389/wssm-testuser
Public Credentials:
Public credential type:
com.ibm.ws.security.auth.WSCredentialImpl
Public credential value:
com.ibm.ws.security.auth.WSCredentialImpl@577c577c
Private Credentials:
Private credential type:
com.tivoli.am.fim.wssm.credentials.WSSMCredential
Private credential value:
BAKs3DCCAooMADCCAoQwggKAAgIGADBgMC8wHgIEI7pnEAIDANjWAgIR2wICAK8CAUUEBgAMKV90
NQwNd3NzbS10ZXN0dXNlcjAtMCswHgIEI4/bfAIDANlIAgIR2wICAK8CAUYEBgAMKV90NQwJRWNo
b1VzZXJzAgEBMIICEzCCAg8wLAwSQVpOX0NSRURfQVVUSFpOX0lEMBYwFAIBBAwNd3NzbS10ZXN0
dXNlcgQAMCUMD0FaTl9DUkVEX0dST1VQUzASMBACAQQMCUVjaG9Vc2VycwQAMDkMG0FaTl9DUkVE
X0dST1VQX1JFR0lTVFJZX0lEUzAaMBgCAQQMEWNuPUVjaG9Vc2VycyxjPXVzBAAwRQwUQVpOX0NS
RURfR1JPVVBfVVVJRFMwLTArAgEEDCQyMzhmZGI3Yy1kOTQ4LTExZGItYWY0Ni0wMDBjMjk1Zjc0
MzUEADApDBBBWk5fQ1JFRF9NRUNIX0lEMBUwEwIBBAwMSVZfTERBUF9WMy4wBAAwLQwZQVpOX0NS
RURfUFJJTkNJUEFMX0RPTUFJTjAQMA4CAQQMB0RlZmF1bHQEADAxDBdBWk5fQ1JFRF9QUklOQ0lQ
QUxfTkFNRTAWMBQCAQQMDXdzc20tdGVzdHVzZXIEADBIDBdBWk5fQ1JFRF9QUklOQ0lQQUxfVVVJ
RDAtMCsCAQQMJDIzYmE2NzEwLWQ4ZDYtMTFkYi1hZjQ1LTAwMGMyOTVmNzQzNQQAMDYMFEFaTl9D
UkVEX1JFR0lTVFJZX0lEMB4wHAIBBAwVY249d3NzbS10ZXN0dXNlcixjPXVzBAAwJwwQQVpOX0NS
RURfVkVSU0lPTjATMBECAQQMCjB4MDAwMDA2MDAEAA==
Private credential type:
com.tivoli.am.fim.wssm.securitytokens.TAMSecurityToken
Private credential value:
com.tivoli.am.fim.wssm.securitytokens.TAMSecurityToken@34c034c
Private credential type:
com.ibm.ws.security.token.SingleSignonTokenImpl
Private credential value:
com.ibm.ws.security.token.SingleSignonTokenImpl@432e432e
Private credential type:
com.ibm.ws.security.token.AuthenticationTokenImpl
Private credential value:
com.ibm.ws.security.token.AuthenticationTokenImpl@56165616
Private credential type:
com.ibm.ws.security.token.AuthorizationTokenImpl
Private credential value:
com.ibm.ws.security.token.AuthorizationTokenImpl@42264226
TFIM Runtime
Deployment on z/OS can Hang and Fail (IZ34559)
A limitation of the z/OS platform can cause TFIM actions to
hang and fail. This has been observed with the deployment
of the TFIM runtime, and can be diagnosed by examining the
WAS log file and looking for a WARNING message such as the
following:
Trace: 2008/02/20 15:30:48.909 01 t=9BE748 c=UNK key=P8 (13007002)
ThreadId: 00000044
FunctionName: com.ibm.ws.runtime.component.ThreadMonitorImpl
SourceId: com.ibm.ws.runtime.component.ThreadMonitorImpl
Category: WARNING
ExtendedMessage: BBOO0221W: WSVR0605W: Thread "WebSphere:ORB.thread.pool t=009c22b8"
(00000022) has been active for 181010 milliseconds and may be hung.
There is/are 1 thread(s) in total in the server that may be hung.
To resolve this problem, a WAS environment variable must be
defined that increases an essential thread pool size.
To define the environment variable for a standalone application
server from the WebSphere administration console, browse to:
"Servers" -> "Application servers" -> server_name ->
"Server Infrastructure" -> "Administration" -> "Custom
properties".
Add the property private_bboo_internal_work_thread_pool_size
with the value of 5.
To define the environment variable for a network deployment
configuration from the WebSphere administration console,
browse to:
"System Administration" -> "Deployment manager" ->
"Administration services" -> "Custom properties".
As in the standalone environment, add the property
private_bboo_internal_work_thread_pool_size
with the value of 5.
Restart the WAS server that has had the environment changed.
To verify that the new value has taken effect, when the server
starts look for this message in the output of the server:
BBOM0001I private_bboo_internal_work_thread_pool_size: 5.
These failures have currently only been reported on the
deployment of the TFIM runtime, and the value of 5 has
resolved the issue. However, if similar error messages are
seen performing other TFIM activities, the pool size
environment variable should be increased to resolve the
problem.
Console
installation can fail if wsadmin.properties files are out of sync
(IZ34562)
Because this failure is caused by a WAS administration error, it cannot
be fixed in a
fix pack.
Consequently it is a permanent restriction in TFIM 6.1.1. The same code
is
used by the fix pack installer so the same restriction applies to
fix pack installations.
Tech
Note #1315672
discusses the work-around for this permanent restriction in more
detail.
The FIM Installer
fails if a '$' is used in a WAS JKS or P12 file's password (IZ34565)
Because this is a defect in the Installer, it cannot be fixed in a fix
pack.
Consequently it is a permanent restriction in TFIM 6.1.1. The same code
is
used by the fix pack installer so the same restriction applies to
fix pack installations.
TechNote #1307656 entitled
"A $ symbol in a truststore or key store password prevents installation"
documents work-arounds for this restriction and is publicly available
on the TFIM
support site.
The default secure protocol for HTTPS connections created by Tivoli
Federated
Identity Manager is SSL_TLS. To change (override) the default protocol,
specify the
following runtime custom property in the fim.appservers.properties
file:
com.tivoli.am.fim.soap.client.ssl.protocol= PROTOCOL
where the value of PROTOCOL can be any of the following
values: SSL_TLS, SSL, SSLv2, SSLv3, TLS or TLSv1
A timestamp is embedded within a passticket,
but the time value interval is only granular to a full second. If two
passtickets are generated
for the same object (user, target app, secret-key) within one second,
then the two passtickets will
be identical, that is, the passtickets will look to the validator like
a "replay attack."
To manage this problem, RACF allows "disable replay detection," and
this APAR enables
Federated Identity Manager to support this functionality.
To disable replay, you can set either or both of the following
custom runtime properties:
passticket.disable.replay.check.[chainid_uuid]=true
passticket.disable.replay.check=true
where chainid_uuid is the value of the chain UUID. For
example:
passticket.disable.replay.check.[uuideb42e428-011b-1ebc-a0cb-9e6c4b35c1c7]=true
To determine the value of Chain UUID, in the
administration console select Trust Service Chains-> Select
Action, then
select Show Chain ID in column in table. This action selection
causes a new
column to appear in the table that displays the unique Chain ID.
WebSphere Application Server versions 6.0.2 and 6.1 do not distinguish
between LTPA v1 and LTPA v2
tokens in Web Services. Only one BinarySecurityToken ValueType is
supported
for LTPA tokens, and the QName of the value type is:
http://www.ibm.com/websphere/appserver/tokentype/5.0.2#LTPA
When the Federated Identity Manager STS issues an LTPA v2 token,
the token is
created with the following QName. This QName is correct, but it is not
supported
by WebSphere Application Server versions 6.0.2 and 6.1:
http://www.ibm.com/websphere/appserver/tokentype#LTPAv2
This APAR provides custom Federated Identity Manager runtime
properties that
force compatible QName generation if needed. To enable compatibility
mode, set either
or both of the following custom runtime properties:
ltpa.enable.compat.mode.[chainid_uuid]=true
ltpa.enable.compat.mode=true
where chainid_uuid is the value of the Chain UUID. For
example:
ltpa.enable.compat.mode.[uuideb42e428-011b-1ebc-a0cb-9e6c4b35c1c7]=true
To determine the value of Chain UUID, in the
administration console select Trust Service Chains-> Select
Action, then
select Show Chain ID in column in table. This action selection
causes a new column
to appear in the table that displays the unique Chain ID.
When authoring XSLT rules for identity mapping, there is no mechanism
to log or trace
statements for debugging purposes. This APAR adds an extension that
enables you to generate
debugging statements to XSLT rules.
To invoke debug statements for identity mapping, add entries in
the XSLT rules using the
following syntax:
<xsl:variable name="variablename" select="mapping-ext:traceString('debug string')">
This APAR fixes an XSLT identity mapping failure that occurred when
using the alias
server with JDBC. An XSLT identity mapping that links accounts from a
JDBC configure-alias
service would fail with the following exception:
com.tivoli.am.fim.identity.service.jdbc.IdServiceJdbc
init javax.naming.NoInitialContextException: Need to specify class name
in environment or system property,
or as an applet parameter, or in an application resource file:
java.naming.factory.initial
at
javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:657)
at
javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:259)
at
javax.naming.InitialContext.getURLOrDefaultInitCtx(InitialContext.java:296)
at javax.naming.InitialContext.lookup(InitialContext.java:363)
at com.tivoli.am.fim.identity.service.jdbc.IdServiceJdbc.(IdServiceJdbc.java:54)
at com.tivoli.am.fim.identity.service.client.jdbc.IdServiceJdbcClient.(IdServiceJdbcClient.java:66)
at java.lang.Class.newInstanceImpl(Native Method)
at java.lang.Class.newInstance(Class.java:1301)
at
org.eclipse.core.internal.registry.osgi.RegistryStrategyOSGI.createExecutableExtension(RegistryStrategyOSGI.java:170)
Creating a
Federated Identity Manager domain might require a WebSphere Application
Server restart (IZ33723)
When creating a Federated Identity Manager domain (or a connection to a
domain),
if you specify inaccurate information in the security settings panel,
WebSphere Application Server might have to be restarted.
If you enter correct data and the Federated Identity Manager console
successfully connects
to the management service (use Test Connection to test the
connection), you do not
need to reconnect to WebSphere Application Server. If the Federated
Identity Manager
console cannot connect to the Management Service, even if correct
security information is supplied,
then you need to restart WebSphere Application Server.
Profiles using POST
artifacts for single sign-on might not work when using WebSphere
Application Server 6.1.0.17 or 6.1.0.19 (IZ36892)
See Tech
Note #1326460,
"TFIM 6.1.1 and 6.2 POST profile SSO can fail with a SRVE0216E error".
for a description of how to address this problem.
Use of the
Federated Identity Manager configuration tool tfimcfg.jar (IZ34546)
Run the command (java -jar tfimcfg.jar) to view a list of options
associated with the tool.
A white paper has been added to the Federated Identity Manager support
site that explains the use of the tfimcfg.jar tool. The tfimcfg.jar
tool is used to configure Tivoli Access Manager WebSEAL as a contact
point for a federation. This white paper supplements the information in
Configuration
of a single sign-on federation in the Installation and
Configuration Guide.
The tfimcfg.jar white paper is listed as "TFIM Configuration Tool
V1.pdf" in the
Tivoli
support Web site.
Management of keys
and keystores by the Federated Identity Manager key service (IZ34554)
The Federated Identity Manager 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 Federated Identity Manager key service actually
manages the keys and certificates.
When the WebSphere Application Server instance where the Federated
Identity Manager runtime is installed
is started, the Federated Identity Manager runtime will read in all
keystore data as part of the
initialization of the Federated Identity Manager key service. When a
new key/certificate for DN X
is added using the Federated Identity Manager console, it is stored in
the specified keystore on the disk.
The Federated Identity Manager runtime configuration needs to be
reloaded to read these keystores and build
its maps of DNs and their keys/certs, making them available for use by
the Federated Identity Manager key service.
To reload the Federated Identity Manager runtime configuration so that
configuration changes are recognized:
- Log in to the console and click Tivoli Federated Identity
Manager-> Domain Management-> Runtime Node Management. The
Runtime Node Management window is displayed.
- Click the Reload Configurations button.
When initializing the Federated Identity Manager 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:
- If there is already a different key/cert stored for DN X,
then the new key/cert is added to the list of X's keys/certs in
order of expiration date.
- If there is already an identical key/cert stored for DN X
then the new key/cert is discarded.
- If the new cert's signing key is already stored, then the cert
is discarded.
- If the new key is a signing key for an already stored cert for X,
then the cert is discarded, the key is added to the map, and X's
key/cert mapping is changed to point to this new key.
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 example:
keystore1(Signing/EncryptionKeys)keyA1DN:CN=A,O=Comp,C=USexpires:Dec31,2010serial=1234keyB1DN:CN=B,O=Comp,
C=USexpires:Dec31,2010serial=2345certstore1(CACertificates)certA1DN:CN=A,O=Comp,
C=USexpires:Dec31,2010serial=1234certC1DN:CN=C,O=Comp,C=USexpires:May31,2007serial=4567certC2DN:CN=C,O=Comp,
C=USexpires:Dec31,2007serial=5678keystore2(Signing/EncryptionKeys)keyB2DN:CN=B,O=Comp,
C=USexpires:Dec31,2010serial=2345certstore2(CACertificates)certC3DN:CN=C,O=Comp,C=US
expires:Dec 31,2007 serial=5678
Keystores are processed in the order (first to last):
certstore1
keystore1
certstore2
keystore2
After the Federated Identity Manager key service processes all of the
keystores, the reference for
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 WebSphere Application
Server version 6.0.2.x.
Referring to the example scenario above, this would
occur if the specification for a CA certificate was keystore1_key1
OR
certstore1_certA1, because 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 communications 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
occurring
when the Federated Identity Manager 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 Federated Identity Manager 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 Federated Identity
Manager
administration console by selecting Domain Management-> Runtime
Node Management->
Runtime Custom Properties. Create a property with
a name of "com.tivoli.am.fim.soap.client.jsse.provider"
and a value of "IBMJSSE2" then restart WebSphere
Application Server.
The Federated Identity Manager runtime will use the IBMJSSE2 provider
as the default.
The runtime custom property com.tivoli.am.fim.soap.client.jsse.provider
can be used to specify IBMJSSE as the provider if desired.
Querying the
Federated Identity Manager runtime status (IZ34555)
It is not possible to query the status of the Federated Identity
Manager runtime
from the eWAS console. The following wsadmin commands
show how to query the Federated Identity Manager runtime's
status as well as how to start and stop the Federated Identity Manager
runtime from the
command line.
These commands assume the WebSphere Application Server instance is
named "server1."
- Determine whether Federated Identity Manager runtime is
installed ("ITFIMRuntime" appears if it is):
wsadmin>$AdminApp list
- Check whether the Federated Identity Manager runtime is
running (if no output is returned the runtime is not running):
wsadmin>$AdminControlqueryNamestype=Application,process=server1,name=ITFIMRuntime,*
- Stop the Federated Identity Manager runtime:
wsadmin>setappManager[$AdminControlqueryNamestype=ApplicationManager,process=server1,*]
wsadmin>$AdminControl invoke $appManager
stopApplication ITFIMRuntime
- Start the Federated Identity Manager runtime:
wsadmin>setappManager[$AdminControlqueryNamestype=ApplicationManager,process=server1,*]
wsadmin>$AdminControl invoke $appManager
startApplication ITFIMRuntime
Fix pack
installation script fails due to SOAP port mismatch (IZ37076)
The fix pack installation of the Federated Identity Manager runtime
must connect to a WebSphere
Application Server SOAP port in order to deploy
the runtime. The fix pack installer acquires its SOAP port value from
the following line
in the /<-installation-directory>/etc/fim.appservers.properties
file
of the Federated Identity Manager instance being patched:
was.soap.port=8880
OR
ewas.soap.port=8880
This value is set in the file when the Federated Identity Manager
instance is installed.
For the connection to be successful, the WebSphere Application
Server instance to which it
is being deployed must still be using that SOAP port.
If it is not, then the Federated Identity Manager fix pack installation
fails in the WebSphere Application Server
UPDI and the error is reported as:
Prerequisite checking has failed. Click Back to select a different
package, or click Cancel to exit.
Associated failure messages are:
The WebSphere server does not seem to be listening in host localhost
port 8881 as specified
in /opt/IBM/FIM/etc/fim.appservers.properties. Make sure the server is
running and that the specified
port and host are correct.
If the specified port is different than the actual SOAP port used, then
change the value in the
fim.appservers.properties file to agree with the port
being used by WebSphere Application Server and
reapply the fix pack.
Documentation for
using the Tivoli Access Manager Login Module in an STS module chain
(IZ34558)
Configuring the Tivoli Access Manager Login Module
The following steps should be performed in order to use
the Tivoli Access Manager Login Module, shipped with the Federated
Identity Manager product, with
the test application shipped with Federated Identity Manager, the
echoapplication
program.
- In the WebSphere Application Server instance with the
echoapplication installed and running, create a JAAS configuration. In
the WebSphere Application Server 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
- Import the echoapplication.ear into Rational
Application Developer or WebSphere Application Server Toolkit. Then
modify:
- 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
WebSphere Application Server.
- 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
Federated Identity Manager 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 Tivoli Access Manager login module.
- In the Federated Identity Manager trust service, set the
application trust chain to issue Tivoli Access Manager credentials
using the Tivoli Access Manager 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 Tivoli Access Manager credentials rather than SAML 2.0
credentials, for example by editing the application chain and changing
the last module from SAML 2.0 to Tivoli Access Manager credential
module.
- Install the new version of the application into WebSphere
Application Server and restart WebSphere Application Server.
- Using the echoclientapplication, select UsernameToken,
and press
"WhoAmI". You should see that the JAAS subject
has a private WSSMCredential containing the BinarySecurityToken
representing the Tivoli Access Manager credential. It is a simple
matter to read this in and create a Tivoli Access Manager PDPrincipal
from that (for more information, see the DeveloperWorks
tutorial).
Here's the text from a "WhoAmI" on the browser:
The web service JAAS subject contains:
Principals:
Principal: dp-autotest.dp.gc.au.ibm.com:389/wssm-testuser
Public Credentials:
Public credential type:
com.ibm.ws.security.auth.WSCredentialImpl
Public credential value:
com.ibm.ws.security.auth.WSCredentialImpl@577c577c
Private Credentials:
Private credential type:
com.tivoli.am.fim.wssm.credentials.WSSMCredential
Private credential value: <wss:binarysecuritytoken
wsu:id="uuiddd1a9699-0113-1259-beb9-e017c8c721d4" valuetype=
"http://ibm.com/2004/01/itfim/ivcred"
encodingtype="http://ibm.com/2004/01/itfim/base64encode"
xmlns:wss= "http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd"
xmlns:wsu= "http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"
xmlns:itam="urn:ibm:names:ITFIM:5.1:accessmanager">
BAKs3DCCAooMADCCAoQwggKAAgIGADBgMC8wHgIEI7pnEAIDANjWAgIR2wICAK8CAUUEBgAMKV90
NQwNd3NzbS10ZXN0dXNlcjAtMCswHgIEI4/bfAIDANlIAgIR2wICAK8CAUYEBgAMKV90NQwJRWNo
b1VzZXJzAgEBMIICEzCCAg8wLAwSQVpOX0NSRURfQVVUSFpOX0lEMBYwFAIBBAwNd3NzbS10ZXN0
dXNlcgQAMCUMD0FaTl9DUkVEX0dST1VQUzASMBACAQQMCUVjaG9Vc2VycwQAMDkMG0FaTl9DUkVE
X0dST1VQX1JFR0lTVFJZX0lEUzAaMBgCAQQMEWNuPUVjaG9Vc2VycyxjPXVzBAAwRQwUQVpOX0NS
RURfR1JPVVBfVVVJRFMwLTArAgEEDCQyMzhmZGI3Yy1kOTQ4LTExZGItYWY0Ni0wMDBjMjk1Zjc0
MzUEADApDBBBWk5fQ1JFRF9NRUNIX0lEMBUwEwIBBAwMSVZfTERBUF9WMy4wBAAwLQwZQVpOX0NS
RURfUFJJTkNJUEFMX0RPTUFJTjAQMA4CAQQMB0RlZmF1bHQEADAxDBdBWk5fQ1JFRF9QUklOQ0lQ
QUxfTkFNRTAWMBQCAQQMDXdzc20tdGVzdHVzZXIEADBIDBdBWk5fQ1JFRF9QUklOQ0lQQUxfVVVJ
RDAtMCsCAQQMJDIzYmE2NzEwLWQ4ZDYtMTFkYi1hZjQ1LTAwMGMyOTVmNzQzNQQAMDYMFEFaTl9D
UkVEX1JFR0lTVFJZX0lEMB4wHAIBBAwVY249d3NzbS10ZXN0dXNlcixjPXVzBAAwJwwQQVpOX0NS
RURfVkVSU0lPTjATMBECAQQMCjB4MDAwMDA2MDAEAA==
</wss:binarysecuritytoken>
Private credential type:
com.tivoli.am.fim.wssm.securitytokens.TAMSecurityToken
Private credential value:
com.tivoli.am.fim.wssm.securitytokens.TAMSecurityToken@34c034c
Private credential type:
com.ibm.ws.security.token.SingleSignonTokenImpl
Private credential value:
com.ibm.ws.security.token.SingleSignonTokenImpl@432e432e
Private credential type:
com.ibm.ws.security.token.AuthenticationTokenImpl
Private credential value:
com.ibm.ws.security.token.AuthenticationTokenImpl@56165616
Private credential type:
com.ibm.ws.security.token.AuthorizationTokenImpl
Private credential value:
com.ibm.ws.security.token.AuthorizationTokenImpl@42264226
Federated Identity
Manager runtime deployment on z/OS can hang and fail (IZ34559)
A limitation of the z/OS platform can cause Federated Identity Manager
actions to
hang and fail. This has been observed with the deployment
of the Federated Identity Manager runtime, and can be diagnosed by
examining the
WebSphere Application Server log file and looking for a WARNING message
such as the
following:
Trace: 2008/02/20 15:30:48.909 01 t=9BE748 c=UNK key=P8 (13007002)
ThreadId: 00000044
FunctionName: com.ibm.ws.runtime.component.ThreadMonitorImpl
SourceId: com.ibm.ws.runtime.component.ThreadMonitorImpl
Category: WARNING
ExtendedMessage: BBOO0221W: WSVR0605W: Thread "WebSphere:ORB.thread.pool t=009c22b8"
(00000022) has been active for 181010 milliseconds and may be hung.
There is/are 1 thread(s) in total in the server that may be hung.
To resolve this problem, a WebSphere Application Server
environment variable must be
defined that increases an essential thread pool size.
To define the environment variable for a standalone application
server from the WebSphere administration console, browse to:
Servers-> Application servers-> server_name->
Server Infrastructure-> Administration-> Custom
properties.
Add the property private_bboo_internal_work_thread_pool_size
with the value of 5.
To define the environment variable for a network deployment
configuration from the WebSphere administration console,
browse to:
System Administration-> Deployment manager->
Administration services-> Custom properties.
As in the standalone environment, add the property
private_bboo_internal_work_thread_pool_size
with the value of 5.
Restart the WebSphere Application Server instance that has had the
environment changed.
To verify that the new value has taken effect, when the server
starts look for this message in the output of the server:
BBOM0001I private_bboo_internal_work_thread_pool_size: 5.
These failures have currently only been reported on the
deployment of the Federated Identity Manager runtime, and the value of
5 has
resolved the issue. However, if similar error messages are
seen performing other Federated Identity Manager activities, the pool
size
environment variable should be increased to resolve the
problem.
With the capability to perform OP-identifier based login, the
RP needs to be able to differentiate this use case so that an
appropriate login identifier can be displayed on the screen to
end users. It doesn't make sense to display the user-supplied
identifier (which is the "normal" choice) if an OP-identifier like
yahoo.com was used for login.
The fix for this defect introduces a new OpenID claims attribute to the
call
between the TFIM SPS and the STS. The claims attribute has been added
to both
IDP and RP implementations, though at the time of writing the IDP
doesn't
support OP-Identifier login, so should always be false. For the RP
(which does
support entering OP Identifiers like yahoo.com), the value will be true
if
OpenID 2 login is being used and the login occurred using the claimed
identifier
of http://specs.openid.net/auth/2.0/identifier_select.
An example of the claims when an OP Identifier is used at the RP is as
follows:
<wst:Claims xmlns:wst="http://schemas.xmlsoap.org/ws/2005/02/trust" Dialect="urn:ibm:names:ITFIM:openid">
<fimopenid:OpenIDClaims xmlns:fimopenid="urn:ibm:names:ITFIM:openid"
ClaimedId="https://sbweeden.myopenid.com/"
IdentityURL="https://www.myopenid.com"
IsOPIdentifierLogin="true"
NormalizedIdentityURL="https://sbweeden.myopenid.com/"
OPLocalId="https://sbweeden.myopenid.com/"
OpenIDServerURL="https://www.myopenid.com/server"
ReturnTo="https://ibmaus27.lnk.telstra.net/FIM/sps/openidfedsp/openid/loginreturn?nonce=uuid8cf114bc-011c-1594-a9ec-b42cb8676ee1"
Signed="openid.assoc_handle,openid.claimed_id,openid.identity,openid.mode,openid.ns,openid.ns.sreg,openid.op_endpoint,openid.response_nonce,openid.return_to,openid.signed,openid.sreg.email,openid.sreg.fullname,openid.sreg.nickname"
Target="https://ibmaus27.lnk.telstra.net:443/FIM/demo/protected/sp/textlanding.jsp"
Version="http://specs.openid.net/auth/2.0" />
</wst:Claims>
You can see in this case that the IdentityURL contains the
user-supplied identifier
https://www.myopenid.com, and the IsOPIdentifierLogin is
set to true.
None.
None.
This information was developed for products and services offered in the
U.S.A.
IBM may not offer the products, services, or features discussed in this
document in other countries. Consult your local IBM representative for
information on the products and services currently available in your
area. Any
reference to an IBM product, program, or service is not intended to
state or
imply that only that IBM product, program, or service may be used. Any
functionally equivalent product, program, or service that does not
infringe
any IBM intellectual property right may be used instead. However, it is
the
user's responsibility to evaluate and verify the operation of any
non-IBM
product, program, or service. IBM may have patents or pending patent
applications covering subject matter described in this document. The
furnishing of this document does not give you any license to these
patents.
You can send license inquiries, in writing, to:
IBM Director of Licensing
IBM Corporation
North Castle Drive
Armonk, NY 10504-1785
U.S.A.
For license inquiries regarding double-byte (DBCS) information,
contact the
IBM Intellectual Property Department in your country or send inquiries,
in
writing, to:
IBM World Trade Asia Corporation
Licensing
2-31 Roppongi 3-chome, Minato-ku
Tokyo 106, Japan
The following paragraph does not apply to the United Kingdom or
any other
country where such provisions are inconsistent with local law:
INTERNATIONAL
BUSINESS MACHINES CORPORATION PROVIDES THIS PUBLICATION "AS IS" WITHOUT
WARRANTY OF ANY KIND, EITHER EXPRESS OR IMPLIED, INCLUDING, BUT NOT
LIMITED
TO, THE IMPLIED WARRANTIES OF NON-INFRINGEMENT, MERCHANTABILITY OR
FITNESS FOR
A PARTICULAR PURPOSE. Some states do not allow disclaimer of express or
implied warranties in certain transactions; therefore, this statement
may not
apply to you.
This information could include technical inaccuracies or
typographical errors.
Changes are periodically made to the information herein; these changes
will be
incorporated in new editions of the publication. IBM may make
improvements
and/or changes in the product(s) and/or the program(s) described in
this
publication at any time without notice.
Any references in this information to non-IBM Web sites are
provided for
convenience only and do not in any manner serve as an endorsement of
those Web
sites. The materials at those Web sites are not part of the materials
for this
IBM product and use of those Web sites is at your own risk.
IBM may use or distribute any of the information you supply in any
way it
believes appropriate without incurring any obligation to you.
Licensees of this program who wish to have information about it
for the
purpose of enabling: (i) the exchange of information between
independently
created programs and other programs (including this one) and (ii) the
mutual
use of the information that has been exchanged, should contact:
IBM Corporation
2Z4A/101
11400 Burnet Road
Austin, TX 78758
U.S.A.
Such information may be available, subject to appropriate terms
and
conditions, including in some cases, payment of a fee.
The licensed program described in this document and all licensed
material
available for it are provided by IBM under terms of the IBM Customer
Agreement, IBM International Program License Agreement or any
equivalent
agreement between us.
Any performance data contained herein was determined in a
controlled
environment. Therefore, the results obtained in other operating
environments
may vary significantly. Some measurements may have been made on
development-level systems and there is no guarantee that these
measurements
will be the same on generally available systems. Furthermore, some
measurement
may have been estimated through extrapolation. Actual results may vary.
Users
of this document should verify the applicable data for their specific
environment.
Information concerning non-IBM products was obtained from the
suppliers of
those products, their published announcements or other publicly
available
sources. IBM has not tested those products and cannot confirm the
accuracy of
performance, compatibility or any other claims related to non-IBM
products.
Questions on the capabilities of non-IBM products should be addressed
to the
suppliers of those products.
All statements regarding IBM's future direction or intent are
subject to
change or withdrawal without notice, and represent goals and objectives
only.
This information contains examples of data and reports used in
daily business
operations. To illustrate them as completely as possible, the examples
include
the names of individuals, companies, brands, and products. All of these
names
are fictitious and any similarity to the names and addresses used by an
actual
business enterprise is entirely coincidental.
The following terms are trademarks or registered trademarks of
International
Business Machines Corporation in the United States, other countries, or
both:
AIX
IBM
IBM logo
iSeries
pSeries
S/390
Tivoli
Tivoli logo
xSeries
zSeries
Adobe, Acrobat, Portable Document Format (PDF), and PostScript are
either
registered trademarks or trademarks of Adobe Systems Incorporated in
the
United States, other countries, or both.
Java and all Java-based trademarks and logos are trademarks of
Sun Microsystems, Inc. in the United States, other countries, or both.
Microsoft, Windows, Windows NT, and the Windows logo are
trademarks of
Microsoft Corporation in the United States, other countries, or both.
UNIX is a registered trademark of The Open Group in the United
States and
other countries.
Other company, product, and service names may be trademarks or
service marks
of others.