|
Problem(Abstract) |
Using single sign-on (SSO) across WebSphere cells, each
using their own user registry, results in "realm mismatch" error -- the
realm in the token does not match the current realm. |
|
|
|
Cause |
WebSphere Application Server derives the realm name from
the LDAP server hostname. This results in a realm mismatch when multiple
LDAP servers are used. |
|
|
Resolving the
problem |
The concept being documented here is that of using a
different LDAP server per node or a distributed LDAP (DLDAP). DLDAP would
be useful for load balancing and in scenarios where a system must contact
a specific LDAP server due to network topology constraints.
The basic idea is to use aliasing to cause WebSphere Application Server
treat the LDAP registries all the same, making the realm name the same.
Here is one possible set of steps to achieve this:
- Alias each local LDAP server as the single authentication and
authorization LDAP server per WebSphere Application Server (LDAP.IBM.COM)
through local settings in each Servers' "/etc/hosts" file.
- Configure the WebSphere Application Server Security/User
Registries/LDAP/Host field to point to the virtual "LDAP.IBM.COM" host
server. This is the realm name and it is case sensitive, even though the
TCP/IP host name is not case sensitive. All servers being configured for
SSO must use the same case in this name.
- Set the Security/User Registries/LDAP/Ignore Case field to true
(otherwise, authorization inevitably fails across enterprise WebSphere
Application Server SSO. This is already set if configured via
wpsconfig.bat.
- Set the Security/Authentication Mechanisms/LTPA/Single Signon/Domain
Name to "IBM.COM".
- Export the generated LTPA Key from the first WebSphere server and
import it into all WebSphere servers and the Domino Address Book Web SSO
configuration document, which is then replicated across the participating
Domino LDAP servers.
There are related concepts of a Highly Available LDAP (HALDAP) and Load
Balancing LDAP (LBLDAP). The LBLDAP can be achieved via an IP Sprayer or
any other technique that configures a single node to utilize multiple LDAP
servers for load balancing and to make sure that if one LDAP server is
unavailable, another can be used. The current LBLDAP registry setups
require that WebSphere Application Server not be configured to reuse the
LDAP connection. The HALDAP automatically failover all LDAP requests to
another available LDAP when current active LDAP fails.
Pending refinement of the customer configuration and documentation, we
have assessed the proposed Web SSO solution that leverages a Distributed
(Localized) LDAP Registry configuration. This configuration, while using
multiple LDAP registries, uses a single LDAP hostname.
As long as a single LDAP hostname (one virtual LDAP host) is used, we
will support the use of LDAP host virtualization techniques (such as
tcp/ip config, ip sprayer, and routers) in order to leverage multiple LDAP
servers. The LDAP servers participating in this virtualization must have
the same LDAP schema and/or replicas. This schema defines the LDAP
attribute structure, naming conventions, and the filters needed to query
LDAP. |
|
|
|
|
Cross Reference information |
Segment |
Product |
Component |
Platform |
Version |
Edition |
Application Servers |
Runtimes for Java Technology |
Java SDK |
|
|
|
|
|
|