PeopleSoft-Only Single Signon Configuration Considerations

The following topics describe some items you might want to consider as you implement your single signon configuration.

Single Authentication Domain Limitation

Web servers must be assigned to the same authentication domain—the server name in the URLs used to access them must contain the same domain name. A browser sends a cookie back only to the same domain from which it received the cookie.

In PeopleSoft applications, an authentication domain is not the same thing as an internet protocol (IP) address. An authentication domain is a logical URL address that you specify during Pure Internet Architecture setup, and its purpose is to associate different web servers (even at different physical locations) so that they appear to be at the same location to the PeopleSoft applications that use those web servers.

Important:

Specifying authentication domains incorrectly for multiple Pure Internet Architecture installations can produce single signon errors.

If you want to keep two PeopleSoft applications from erroneously attempting to employ single signon, make sure that the authentication domain you specify for one application's web server is not a subset of the authentication domain you specify for the other. For example, if your CRM web server has an authentication domain of .crm.mycompany.com, your Financials web server authentication domain must not be .mycompany.com (the parent of the CRM server domain) or .fin.crm.mycompany.com (a child of the CRM server domain). It can, however, be .fin.mycompany.com (or any child of the mycompany.com domain).

If you do want two PeopleSoft applications to employ single signon, you must ensure that each application contains a definition of the other as a trusted node, and you must specify the same authentication domain for both applications' web servers during Pure Internet Architecture setup.

Furthermore, the web server that generates the cookie must have the domain that shares the PS_TOKEN cookie specified in the web profile of the local Pure Internet Architecture web site. For example, in the context of our HCM to Financials example, the web profile for the HCM web server must contain the value of .example.com in the Authentication Domain property.

Note:

You must specify the leading dot (.).

The single domain issues occur in the following situations:

  • You're using straight Pure Internet Architecture, as in you are deploying applications but not by way of the portal.

  • You're using the portal with frame-based templates. All PeopleSoft portal solutions products (Enterprise, Employee, Customer, Supplier portals) are built using frame-based templates.

Frame-based templates aren't proxied automatically. Proxying refers to when the system rewrites the URL to point to a location on the portal servlet, rather than the original location of the URL.

Single Signon Between Machines without DNS Entries

If you're setting up single signon between machines that don't have DNS entries, you need to modify the hosts file on the machine that's running the web browser. For example, let’s say that you are using machine a.example.com to signon to the web server a.example.com, and then access b.example.com using single signon. In this situation, you would need to update the hosts file on a.example.com as follows.

# Copyright (c) 1993-1999 Microsoft Corp.
#
# This is a sample HOSTS file used by Microsoft TCP/IP for Windows.
#
# This file contains the mappings of IP addresses to host names. Each
# entry should be kept on an individual line. The IP address should
# be placed in the first column followed by the corresponding host name.
# The IP address and the host name should be separated by at least one
# space.
#
# Additionally, comments (such as these) may be inserted on individual
# lines or following the machine name denoted by a '#' symbol.
#
# For example:
#
#      192.0.2.1     myserver.example.com          # source server
#       203.0.113.1     myclient.example.com              # x client host

192.0.2.8       localhost
203.0.113.4  a.example.com
198.51.100.5  b.example.com

Domain Names

You need to use a fully qualified domain name when addressing the web server in your browser.

  • This is an example of a correctly formatted URL: http://hcm.example.com/myapplication/signon.html

  • This is an example of an incorrectly formatted URL: http://hcm/myapplication/signon.html

When using the portal, the domain name that you specify in the Portal URI Text edit box on the Content Provider administration pages must match the fully qualified domain name you enter as the authentication domain. For example, you must specify myserver.example.com/servlets, not myserver/servlets.

Cross Domain Single Signon

The current PeopleSoft single signon solution deals mainly with systems where there is only one DNS domain. Many sites need to deploy the PeopleSoft Portal in multi-domain environments. For example, you might want to have the portal in one domain such as, www.myserver.com, and the HCM database in another domain, such as www.yourcompany.com.

You can configure your environment to support cross-domain single signon by completing the following configuration tasks.

  • Setup a third-party web security product that supports multi-domain single signon and supports LDAP user profiles.

    There are several industry-standard products on the market.

  • Configure the portal and content provider web servers to trust the web server for authentication.

    For PeopleSoft applications , this involves creating and enabling the public access user.

  • Set up the PeopleSoft applications to download the user profiles from the same LDAP server that the web security product uses.

    This means that the DN that comes from the subject field of the certificate has to be a valid DN for the directory that the LDAP_profilesynch function references. Because of this you need to build a user profile cache map that points to the same directory that generated the subject's DN.

Note:

This cross-domain limitation does not apply to the portal if the content from the provider in a different domain is wrapped in an HTML template. However, this limitation does apply for any content in the portal that is wrapped in a frame template. Because the Enterprise, Customer, Supplier, and Employee portals that ship with PeopleTools all include frame templates as defaults, you'll need to perform the extra configuration steps to support cross-domain single signon in multi-domain environments. This limitation also applies to Pure Internet Architecture-to-Pure Internet Architecture (iClient-to-iClient) single signon.