PeopleSoft-Only Single Signon Configuration Examples

One Database and Two Web Servers

In this scenario there is one database and two or more web servers. While single signon is configured at the database level (that is, you specify timeout minutes and trusted nodes for the entire database), it’s actually used any time two different PeopleSoft servlets connect to the same database.

To set up single signon with one database and multiple web servers:

Select PeopleTools, and then Portal, and then Portal Node Definitions and make sure that at least one node is defined as the Default Local Node.

In the results on the search page, you can determine this by looking for a Y in the Default Local Node column.
Select PeopleTools, and then Security, and then Security Objects, and then PeopleSoft Single Signon and set the following:
- Make sure the Default Local Node appears in the list under Trust Authentication Tokens issued by these Nodes.
- Set the timeout minutes to an appropriate value (the default is 720).
Access the web profile for each web server and modify the Authentication Domain property.

Because single signon is implemented using browser cookies, it must be configured so that the user's browser sends the single signon cookie to each web server machine involved. By default, the browser only sends cookies back to the machine that set the cookie. So if web server a.example.com sets a cookie after the user is authenticated, the browser (by default) only sends the cookie to a.example.com. By default, the browser would not send the cookie to b.example.com. To make the browser send the single signon cookie to all servers at in a domain (example.com), access the Web Profile Configuration - General page and set a value of .example.com for the Authentication Domain property.

Note:

You need the leading period (.) before the domain. It should appear as “.example.com,” not “example.com.”

If you use only one web server, you don’t need to modify the Authentication Domain property. A web server is designed to accept the cookies it distributes.

Two Databases and Two Web Servers

To set up single signon with multiple databases and multiple web servers:

Select PeopleTools, and then Portal, and then Portal Node Definitions.

For each node that you want to involve in the single signon configuration and check the following:
- Make sure that at least one node definition is defined as the Default Local Node for each database.
  
  In the results on the search page, you can determine this by looking for a Y in the Default Local Node column.
- Make sure that each database contains a node definition for the other nodes in the single signon configuration.
- Make sure that the Authentication Option is set correctly.
  
  For example, if you are using password authentication make sure that the node password for node ‘X’ is the same in each node definition for node ‘X’ in each database.
  
  If you use digital certificate authentication, make sure the certificates are properly installed in the PeopleSoft Keystore before setting the node’s Authentication Option to Certificate.
Select PeopleTools, and then Security, and then Security Objects, and then PeopleSoft Single Signon and set the following:
- Make sure the Default Local Node appears in the list under Trust Authentication Tokens issued by these Nodes.
- Set the timeout minutes to an appropriate value (the default is 720).
Access the web profile on your web server and modify the Authentication Domain property.

Because single signon is implemented using browser cookies, it must be configured so that the user's browser sends the single signon cookie to each web server machine involved. By default, the browser only sends cookies back to the machine that set the cookie. So if web server a.example.com sets a cookie after the user is authenticated, the browser (by default) only sends the cookie to a.example.com. By default, the browser would not send the cookie to b.example.com. To make the browser send the single signon cookie to all servers at in a domain (example.com), modify the authentication domain as follows.

See Understanding SSL/TLS and Digital Certificates, Understanding the PeopleSoft LDAP Solution.

Single Signon with Third Party Authentication

This section presents a simple example of how to implement single signon when you have implemented a third-party authentication system at the web server level. This applies to both portal and intranet web servers.

This discussion assumes that you have enabled public user access in the web profile for the appropriate site.

See Creating a Public Access User.

Note:

While this example does not cover authentication, it assumes that you have set up your third-party authentication correctly. Third-party authentication is out of the scope for PeopleSoft support and documentation.

For PeopleSoft application single signon, the PeopleSoft system needs to know the user ID to be used for the web session. If implementing this configuration, you are required to address the following steps:

Authenticate the web user.
Determine which PeopleSoft user ID to use for this web user.
Send the user ID to the PeopleSoft application server.
Write Signon PeopleCode to retrieve the user ID from the location, as indicated in step 3.
Reauthenticate the user ID during Signon PeopleCode.
Indicate to the PeopleSoft application server to use the user ID for all subsequent service requests.

The following examples address steps 3, 4, and 6.

The following HTML applies to step 3 above. You can change the JavaScript function to set the cookie name and value that you want. Also, change the location to point to the PeopleSoft page to which you want to redirect users, for example:

<html>
<head>
<title>PeopleSoft 8 Single Signon Example</title>
</head>

<!--
PeopleSoft 8 Single Signon Example

In this example, security is non-existent.  In a production
system, the UserId could come from your site's single signon
tool.  Other information could also be included.  For this
example, only the UserId is saved into cookie.  This cookie then
gets sent to the PIA Web Servlet which passes it on to the
PeopleSoft Application Server.  A piece of Signon PeopleCode is
needed to extract the UserId from the cookie and call
SetAuthorizationResult to "sign on" the user.

- Change the domain value of the cookie to your domain.
- Change the location ref to the target URL within your PeopleSoft site.
//-->

<body>
<script language=JavaScript>
var cookie = "ThirdPartyUserId=PS; Domain=.example.com; path=/; MaxAge=1";
document.cookie = cookie;
location="https://hcm.mycompany.com/psp/hcmprod/EMPLOYEE/HCM/c/ROLE_⇒
EMPLOYEE.TIME_OFF.GBL?FolderPath=PORTAL_ROOT_OBJECT.EE_SELF_SERVE.EE_TIMEOFF_⇒
GBL&IsFolder=false&IgnoreParamTempl=FolderPath%2cIsFolder"</script>
</body>

</html>

The following Signon PeopleCode example applies to steps 4 and 6 above. The Signon PeopleCode needs to retrieve &UserID from where the third-party portal put it in the HTTP Request. For example,

Function SSO_EXAMPLE()
/*This is step 4*/
   &TPUserId = %Request.GetCookieValue("ThirdPartyUserId");
   /*This is step 6*/
   If &TPUserId <> "" Then
      SetAuthenticationResult( True, &TPUserId, "", False);
   End-If
End-Function;

After you write the program, you need to enable the program using the Signon PeopleCode page (PeopleTools, and then Security, and then Security Objects, and then Signon PeopleCode).