With single sign-on (SSO) support, Web users can authenticate once
when accessing Web resources across multiple WebSphere Application Servers.
Form login mechanisms for Web applications require that SSO is enabled. Use
this topic to configure single sign-on for the first time.
Before you begin
SSO
is supported when Lightweight Third Party Authentication (LTPA) is the authentication
mechanism.
When SSO is enabled, a cookie is created containing the
LTPA token and inserted into the HTTP response. When the user accesses other
Web resources in any other WebSphere Application Server process in the same
domain name service (DNS) domain, the cookie is sent in the request. The LTPA
token is then extracted from the cookie and validated. If the request is between
different cells of WebSphere Application Servers, you must share the LTPA
keys and the user registry between the cells for SSO to work. The realm names
on each system in the SSO domain are case sensitive and must match identically.
For
the Lightweight Directory Access Protocol (LDAP) the realm name is the host:port
realm name of the LDAP server. The LTPA authentication mechanism requires
that you enable SSO if any of the Web applications have form login as the
authentication method.
Because single sign-on is a subset of LTPA, it
is recommended that you read Lightweight Third Party Authentication for more information.
When you enable security
attribute propagation, the following cookies are added to the response:
- LtpaToken
- LtpaToken is used for inter-operating with previous releases of WebSphere
Application Server. This token contains the authentication identity attribute
only.
- LtpaToken2
- LtpaToken2 contains stronger encryption and enables you to add multiple
attributes to the token. This token contains the authentication identity and
additional information such as the attributes that are used for contacting
the original login server and the unique cache key for looking up the Subject
when considering more than just the identity in determining uniqueness.
For more information, see
Security attribute propagation.
Note: LtpaToken
is generated for releases prior to WebSphere Application Server Version 5.1.0.2.
LtpaToken2 is generated for WebSphere Application Server Version 5.1.0.2 and
beyond.
Token type |
Purpose |
How to specify |
LtpaToken only |
This token type is used for the same SSO behavior existing
in WebSphere Application Server Version 5.1 and previous releases. Also, this
token type is interoperable with those previous releases. |
Disable the Web inbound security attribute propagation option,
which is located in the SSO configuration panel in the administrative console.
To access this panel, complete the following steps:
- Click Security > Global security.
- Under Authentication, click Authentication mechanisms > LTPA.
- Under Additional properties, click Single sign-on (SSO).
|
LtpaToken2 only |
This token type is used for Web inbound security attribute
propagation and uses the AES, CBC, PKCS5 padding encryption strength (128-bit
key size). However, this token type is not interoperable with releases prior
to WebSphere Application Server Version 5.1.1. The token type supports multiple
attributes that are specified in the token, mostly containing information
to contact the original login server. |
Enable the Web inbound security attribute propagation option
in the SSO configuration panel within the administrative console. Disable
the Interoperability mode option in the SSO configuration panel within
the administrative console. To access this panel, complete the following steps:
- Click Security > Global security.
- Under Authentication, click Authentication mechanisms > LTPA.
- Under Additional properties, click Single sign-on (SSO).
|
LtpaToken and LtpaToken2 |
These tokens together support both of the previous two
options. The token types are interoperable with releases prior to WebSphere
Application Server Version 5.1.1 because LtpaToken is present. The security
attribute propagation function is enabled because the LtpaToken2 is present. |
Enable the Web inbound security attribute propagation option
in the SSO configuration panel within the administrative console. Enable the Interoperability
mode option in the SSO configuration panel within the administrative console.
To access this panel, complete the following steps:
- Click Security > Global security.
- Under Authentication, click Authentication mechanisms > LTPA.
- Under Additional properties, click Single sign-on (SSO).
|
- Open the administrative console.
Type http://localhost:port_number/ibm/console to
access the administrative console in a Web browser.
Port 9060 is
the default port number for accessing the administrative console. During installation,
however, you might have specified a different port number. Use the appropriate
port number.
- Click Security > Global security .
- Under Authentication, click Authentication
mechanisms > LTPA.
- Under Additional properties, click Single
sign-on (SSO).
- Click the Enabled option if SSO is disabled. After
you click the Enabled option, make sure that you complete the remaining
steps to enable security.
- Click Requires SSL if all of the requests are expected to
use HTTPS.
- Enter the fully qualified domain names in the Domain name field
where SSO is effective. If you specify domain names, they must
be fully qualified. If the domain name is not fully qualified, WebSphere Application
Server does not set a domain name value for the LtpaToken cookie and SSO is
valid only for the server that created the cookie.
When you specify multiple
domains, you can use the following delimiters: a semicolon (;), a space
( ), a comma (,), or a pipe (|). WebSphere Application Server
searches the specified domains in order from left to right. Each domain is
compared with the host name of the HTTP request until the first match is located.
For example, if you specify ibm.com; austin.ibm.com and a match is
found in the ibm.com domain first, WebSphere Application server does not continue
to search for a match in the austin.ibm.com domain. However, if a match is
not found in either the ibm.com or austin.ibm.com domains, then WebSphere
Application Server does not set a domain for the LtpaToken cookie.
You
can configure the Domain name field using any of the following values:
Domain name value type |
Example |
Purpose |
Blank |
|
The domain is not set. This causes the browser to
set the domain to the request host name. The sign-on is valid on that single
host only. |
Single domain name |
austin.ibm.com |
If the request is to a host within the configured
domain, the sign-on is valid for all hosts within that domain. Otherwise,
it is valid on the request host name only. |
UseDomainFromURL |
UseDomainFromURL |
If the request is to a host within the configured
domain, the sign-on is valid for all hosts within that domain. Otherwise,
it is valid on the request host name only. |
Multiple domain names |
austin.ibm.com;raleigh.ibm.com |
The sign-on is valid for all hosts within the domain
of the request host name. |
Multiple domain names and UseDomainFromURL |
- austin.ibm.com;raleigh.ibm.com; UseDomainFromURL
|
The sign-on is valid for all hosts within the domain
of the request host name. |
If you specify the UseDomainFromURL, WebSphere Application Server
sets the SSO domain name value to the domain of the host that makes the request.
For example, if an HTTP request comes from server1.raleigh.ibm.com, WebSphere
Application Server sets the SSO domain name value to
raleigh.ibm.com .
Tip: The value, UseDomainFromURL, is case insensitive. You
can type usedomainfromurl to use this value.
For more
information, see Single sign-on settings.
- Optional: Enable the Interoperability mode option
if you want to support SSO connections in WebSphere Application Server version
5.1.1 or later to interoperate with previous versions of the application server.
This option sets the old-style LtpaToken token into the response so
it can be sent to other servers that work only with this token type. However,
this option applies only when the Web inbound security attribute propagation option
is enabled. In this case, both the LtpaToken and LtpaToken2 tokens are added
to the response. Otherwise, only the LtpaToken2 token is added to the response.
If the Web inbound security attribute propagation option is disabled,
then only the LtpaToken token is added to the response.
- Optional: Enable the Web inbound security attribute
propagation option if you want information added during the login at a
specific front-end server to propagate to other front-end servers. The
SSO token does not contain any sensitive attributes, but does understand where
the original login server exists in cases where it needs to contact that server
to retrieve serialized information. It
also contains the cache look-up value for finding the serialized information
in DynaCache, if both front-end servers are configured in the same DRS replication
domain. For more information, see Security attribute propagation.
Important: If
the following statements are true, it is recommended that you disable the
Web
inbound security attribute propagation option for performance reasons:
- You do not have any specific information added to the Subject during a
login that cannot be obtained at a different front-end server.
- You did not add custom attributes to the PropagationToken token using
WSSecurityHelper application programming interfaces (APIs).
If you find that you are missing custom information in the Subject, re-enable
the
Web inbound security attribute propagation option to see if the
information is propagated successfully to other front-end application servers.
If you disable SSO, but use a trust association interceptor instead, you might
still need to enable the
Web inbound security attribute propagation option
if you want to retrieve the same Subject generated at different front-end
servers.
WebSphere Application Server Version
6.0.2.17 contains APAR PK32086, which might improve performance with security
attribute propagation enabled.
- Click OK.
What to do next
For
the changes to take effect, save, stop, and restart all the product deployment
managers, nodes, and servers.