Network Deployment (Distributed operating systems), v8.0 > Secure applications and their environment > Authenticate users


Implement single sign-on


Overview

With single sign-on, users need only authenticate once to access multiple systems. SSO leverages LTPA...

  1. A cookie containing the LTPA token is inserted into HTTP responses
  2. The LTPA keys are sent to hosts in the same DNS domain
  3. The LTPA token is extracted from the cookie and validated.

Cells all share the same user registry. Realm names must be exact matches, including case. For Windows Local OS, realm name is domain name. If domains not used, realm name is machine name. The realm name is the same as the host name. For LDAP the realm name is the LDAP host:port.

If you leverage form login with web applications, LTPA requires SSO to be enabled.

By default, security attribute propagation is enabled and LtpaToken2 cookies are added to responses. LtpaToken2 contains identity and other attributes, including...

LtpaToken contains authentication identity attribute only.


Configure single sign-on

  1. Enable administrative security

  2. Enable SSO. From the admin console go to...

      Security | Global security | Web security | Single sign-on (SSO)

    ...and click Enabled.

  3. For https support, click: Requires SSL

  4. Set FQ domain names. For example...

      foo.com;amsterdam.foo.com

    If match not found, WAS does not set a domain for the cookie. The browser will set domain to requesting host, with sign-on valid for that host only. If we specify UseDomainFromURL, WAS sets domain name to the requesting host. For example, if HTTP request comes from...

      server1.haarlem.foo.com

    ...WAS sets domain to...

      haarlem.foo.com

  5. To support SSO connections with previous versions enable Interoperability. This will set old-style LtpaToken tokens into the response for use by servers that work only with this token type. Enabling is a performance hit, so must to avoid if possible.

  6. To add information to the SSO token during front-end server login, enable...

    Tokens will contain the...

    • Location of original login server
    • DynaCache look-up value for hosts in the same replication domain

    To improve performance, disable if the following are true...

    • No information is added to the Subject during a login that is not already available to other hosts.
    • Custom attributes were not added to the PropagationToken token using WSSecurityHelper.

    If, after disabling, information in the Subject seems to be missing, re-enable Web inbound security attribute propagation.

    If enabled, to improve performance...

      com.ibm.CSI.propagateFirstCallerOnly Only the first caller in the propagation token is logged. Default is true. When false, all of the caller switches are logged.
      com.ibm.CSI.disablePropagationCallerList When true, ability to add callers or host lists to the propagated token is disabled. Set to true if caller or host list in the propagation token is not needed in the environment.

  7. Click OK.

  8. Save, stop, and restart all the product dmgrs, nodes, and servers.

Related

LTPA
LTPA mechanism
Security attribute propagation
SSO troubleshooting
Authenticate users
Enable security
Web component security
SSO with TAM or WebSEAL
SSO for HTTP requests using SPNEGO I
SSO for HTTP requests using SPNEGO II
SSO for HTTP requests using the SPNEGO TAI
Security resources

+

Search Tips   |   Advanced Search