Implementing PeopleSoft-Only Single Signon (2024)

This section providesan overview of PeopleSoft-only single signon and discusses:

Defining nodes for singlesignon.
Working with the SingleSignon page.
Defining authorized sitesfor single signon.
Setting up certificateauthorization.
Single signon transactionexample.
PeopleSoft-only singlesignon configuration considerations.
PeopleSoft-only singlesignon configuration examples.
Securing the PeopleSoftsingle signon token.
Using the single signonAPI.
Configuring single signoff.

Note: In this configuration,you must create PeopleSoft node definitions for each of the participatingapplications. You can run any of the participating applications onOracle WebLogic. You can use passwords or digital certificates forsingle signon authentication.

PeopleSoft applicationssupports single signon among other PeopleSoft applications. Withinthe context of your PeopleSoft system, single signon means that aftera user has been authenticated by one PeopleSoft application server,then that user can access other PeopleSoft application servers withoutentering an ID or a password. Although the user is actually accessingdifferent applications and databases—recall that each suite of PeopleSoftapplications, such as HCM or CRM, resides in its own database—theuser navigates seamlessly through the system.

Note: The PeopleSoft-onlysingle signon solution applies only to PeopleSoft applications. Singlesignon requires that user profiles exist in all databases involvedin single signon.

The user profiles toutilize single signon must be defined on all participating databases.For example, for user Marcia Brady to be able to use single signonto access DatabaseA, Database B, and Database C, her user profile must be defined in each of the three databases.

Single signon is criticalfor PeopleSoft portal implementations because the portal integratescontent from various data sources and application servers and presentsthem in a unified interface. When the users sign in through the portal,they always take advantage of single signon. Users need to signononce and be able to navigate freely without encountering numeroussignon screens. Because single signon is so integral to the portal,you always need to configure it before deploying a live portal solution.

Authentication Token(PS_TOKEN)

After the first applicationserver/node authenticates a user, the system delivers a web browsercookie containing an authentication token (PS_TOKEN). PeopleSoftuses web browser cookies to store a unique access token for each userafter they are authenticated initially. When the user connects toanother PeopleSoft application server/node, the second applicationserver uses the token in the browser cookie (as long as the tokenis valid) to re-authenticate users automatically so they don’t haveto sign in repeatedly.

Note: The browser cookie isan in-memory cookie and is never written to disk. The cookie is alsoencrypted to prevent snooping and digitally signed to prevent tampering.

Check Token IDs

A check token ID verifiesthat the PS Token is still valid at the originator site or at thelast site visited.

Each PeopleSoft databaseparticipating in single signon must define a check token ID on thedefault local node definition on the local database, as well as definethe check token ID of their single signon participants on the remotenode definitions of each.

You can create a system-generatedcheck token ID by using the Create CheckTokenID button on the Nodes - Node Definitions page. When you click thebutton, the system generates a random 184 byte/248 character valueand populates the value in the Check TokenID field. Note that the Create CheckTokenID button appears only on the Nodes - Node Definitions page for thelocal default node. As an alternative you can create your own customcheck token ID. Custom check token IDs have a 254-character limit.Be sure to copy the ID before saving the component. You must providethis value to your single-signon participants, as they must definethis value on their local database on the remote node definition thatrepresents your database. Once you save the component, a mask appearsin the field.

See the section “DefiningNodes for Single Signon” later in this section for more information.

The following tablelist steps for setting up single signon among PeopleSoft systems.Note that additional configuration may be required based on your businessand security requirements.

Step	Page/Navigation	Description
1. Configure the defaultlocal node definition.	Nodes - Node Definitionspage. PeopleTools > Portal > Node Definitions. Select the default local node and click the Nodes Definitiontab.	Define the AuthenticationOption. The validoptions for single signon are `Password` or `Certificate.` You must define thesame value on the remote PeopleSoft nodes participating in singlesignon. Generate and define a checktoken ID. Click theCheckTokenID button to create a system-generated ID. The system automaticallypopulates the value in the Check TokenID field on the Node Definitionpage. As an alternative, create a custom ID, or create a custom IDof up to 256 characters. Make a note of the IDbefore saving the page. You must provide a copy of the ID to yoursingle signon participants, who must in turn define that value ontheir databases on the the Nodes – Node Definitions page for the remotenode definition that represents your database.
	Nodes - Portal page. PeopleTools > Portal > Node Definitions. Select the default local node and click the Portaltab.	Define the PeopleToolsrelease. In the ToolsRelease field enter the PeopleTools release running on the local database.For example, `8.56.00` Define the Content URI. In the Content URI Textfield enter the uniform resource identifier (URI) of the pscontentservlet (psc) for the local default node. Define the Portal URI. In the Portal URI Textfield enter the URI of the the portal servlet (psp) for the localdefault node
2. Configure remotePeopleSoft node for each node participating in single signon.	Nodes - Node Definitionspage. PeopleTools > Portal > Node Definitions. Select the remote PeopleSoft node and click the NodesDefinition tab.	Define the AuthenticationOption. The validoptions for single signon are `Password` or `Certificate.` You must define thesame value as defined on the local default node of the single signonparticipant. Define the check tokenID. Enter the checktoken ID as provided by the single signon participant.
	Nodes – Portal page. PeopleTools > Portal > Node Definitions. Select the remote PeopleSoft node and click the Portaltab.	Define the PeopleToolsrelease. In the ToolsRelease field enter the PeopleTools release running on the singlesignon partner database. For example, `8.56.00` Define the Content URI. In the Content URI Textfield enter the URI of the pscontent servlet (psc) for the singlesignon participant’s default local node. Define the Portal URI. In the Portal URI Textfield enter the URI of the the portal servlet (psp) for the singlesignon participant’s default local node.
3. Add nodes/databasesparticipating in single signon to the Single Signon page.	Single Signon page. PeopleTools > Security > Security Objects > Single Signon	Add nodes participatingin single signon to the Trust Authentication Tokens Issued by TheseNodes grid. Click the Lookup button to search for and select nodesto participate in single signon. The default local nodeappears in the grid by default.
4. Add sites participatingin single signon to the Authorized Sites page.	Authorized Sites page. PeopleTools > Web Profile > Authorized Sites.	You can add sites twoways: Allow Domain Compare. In the CheckToken sectionof the page, select the Allow Domain Compare box. Selecting this optionallows access for all sites within a defined authentication domain,including their sub-domains. For example, an authenticationdomain of `example.com` will include `myserver1.example.com,` `myserver2.example.com` and so on. Whitelist sites to participatein single signon. In the Authorized Sites grid, add a row for each site and selectthe CheckToken box to enable single signon for the site.

Defining GeneralNode Properties for PeopleSoft-Only Single Signon

Access the Node Definitionspage (PeopleTools > Portal > Node Definitions).

Implementing PeopleSoft-Only Single Signon (1)

The following exampleshows the Nodes - Node Definitions page for a remote PeopleSoft nodeparticipating in single signon as defined on the local database:

Important! The node name that youdefine for a remote PeopleSoft node to participate in single signonmust be the same name as the default local node name on the participant’slocal database.

Implementing PeopleSoft-Only Single Signon (2)

The fields and controlsrequired for single signon are described in the following table. Notethat your business and system requirements may warrant additionalconfiguration of this page.

Field or Control	Definition
Description	Enter a descriptionfor the node.
Node Type	Select `PIA` from thedrop-down list. The Node Type for localand remote PeopleSoft nodes participating in single signon must be `PIA.`
Authentication Option	Determines how nodesin a single signon configuration authenticate other nodes in the sameconfiguration. The valid options for single signon are: `Password:` Indicatesthat each node in the single signon configuration authenticates othernodes by way of knowing the password for each node. For example,if there are three nodes (A, B, and C), the password for node A needsto be specified in its node definition on nodes A, B, and C. `Certificate:` Indicates that a digital certificate authenticates each node inthe single signon configuration. For certificate authentication,you need to have the following in the key store in the database foreach node: Certificate for each node. Note: For SSO, avoid usingcertificate key size 4096 due to browser limitation. Root certificate for theCA that issued the certificate. Important! For single signon, thealias for the certificate of a node needs to be the `same` as thenode name. Also, you must request and set up your digital certificatesbefore you set the authentication option to certificate authentication. While the option `None,` whichsignifies no authentication between nodes, is included in the drop-downlist, it is not a valid option for single signon nodes. .
Default Local Node	When defining the defaultlocal node on the local database, select the Default Local Node option. Indicates that the currentnode represents the database you’re signed in to. The default localnode is used specifically for setting up single signon. The optionsyou set for single signon should be made on the default local node.
Node Password	Default local node definition. Enter a password forthe node. The value you enter is limited to 88 characters. Remote PeopleSoft nodedefinitions. Enterthe password for the single signon participant’s default local node,as provided by the participant. Note: You must reboot theapplication server and the web server after you define or change thisvalue.
Default User ID	Default local node definition. Enter or select a defaultuser ID to associate with the node. Remote PeopleSoft nodedefinitions. Enteror select the default user ID defined for the single signon participant’sdefault local node, as provided by the participant.
Create CheckTokenID	The Create CheckTokenID button appears only: On the definition for thedefault local node. when the Authentication Option type is `Password` or `Certificate.` Click the button tocreate a system-generated check tokenID for use in conjunction withsingle signon among PeopleSoft systems. When you click the button,the system populates the Check TokenID field with the generated value.
Check TokenID	Default local node definition: This field displaysthe check token ID value generated after clicking the Create CheckTokenID button. This ID is used in conjunction with single signon amongPeopleSoft systems. Alternatively, you cancreate a custom ID up to 256 characters. Copy the value in thefield before saving the page. You must provide this value to otherPeopleSoft partners/nodes participating in single-sigon, as they mustdefine this value on their database on the remote node definitionthat represents your database. Remote PeopleSoft nodedefinitions. On definitionsfor remote PeopleSoft nodes participating in single signon, enterthe value provided by your single signon partner. After you save the pagethe field becomes masked, regardless of whether a value is definedin the field or not. Note: You must reboot theapplication server and the web server after you define or change thisvalue.

Defining PortalNode Properties for PeopleSoft-Only Single Signon

Access the Nodes - Portalpage (PeopleTools > Portal > Node Definitions and click the Portal tab).

The following exampleshows the Nodes - Portal page for the local default node.

Implementing PeopleSoft-Only Single Signon (3)

The fields and controlsrequired for single signon are described in the following table. Notethat your business and system requirements may warrant additionalconfiguration of this page.

Note: References to “remotePeopleSoft nodes” in the descriptions refer to remote node definitionsthat you must define for each PeopleSoft system participating in singlesignon.

Field or Control	Definition
Tools Release	Default local node definition. When defining propertiesfor the default local node, enter the Tools release version installedon the local database. On most browsers, you can press CTRL + J tolocate the PeopleTools release installed on the database. Remote PeopleSoft nodedefinitions. Whendefining properties for remote PeopleSoft nodes, enter the Tools releaseversion installed on the single signon participant’s database.
Content URI Text	Default local node definition. When defining propertiesfor the default local node, enter the URI of the pscontent servletfor the local database. Remote PeopleSoft nodedefinitions. Whendefining properties for remote PeopleSoft nodes, enter the URI ofthe pscontent servlet (psc) for the single signon participant’s defaultlocal node.
Portal URI Text	Default local node definition. When defining propertiesfor the default local node, enter the URI of the portal servlet (psp)for the local database. Remote PeopleSoft nodedefinitions. Whendefining properties for remote PeopleSoft nodes, enter the URI ofthe portal servlet (psp) for the single signon participant’s defaultlocal node.

Related Links

Understanding Nodes

Implementing Nonrepudiation

Access the Single Signonpage (select PeopleTools > Security > Security Objects > Single Signon).

Implementing PeopleSoft-Only Single Signon (4)

Field or Control	Definition
Expiration time in minutes	You need to set an expirationtime for tokens this system accepts for authentication. Otherwise,once the user is authenticated, the user could be authenticated andsigned on to the system with the token for as long as it stays upand running. You can set the authentication interval to be minutes,hours, or days depending on your signon strategy. The value is in minutes. For example, 480 minutes is 8 hours. This is global setting forall users of your PeopleSoft system that get issued the cookie. Ashort expiration period is more secure, but less convenient becauseusers need to enter their passwords more frequently. The system acceptingthe token controls the expiration time, not the issuing system. Forexample, Node HCM_WEST, which has an expiration time of 100 minutes,issues a token to a user. The user attempts to use that token tosign in to Node FIN_EAST, which has an expiration time set to 60 minutes. If a period greater than 60 minutes has transpired, Node FIN_EASTrejects the token. When a node rejects a single signon token, thesystem prompts the user to enter a user ID and password on the standardsignon screen. Note: This expiration timeis separate from the timeouts you specify in the Permission Listsand the web server configuration files.
Message Node name	Shows the name of theMessage Node. In order to share authentication tokens between nodes,the nodes need to trust each other. By adding a node to this grid,you indicate that a particular node is known to the system and trusted. When a node is trusted, the local node accepts tokens issued by it. By default, no nodesappear in the trusted nodes list. If you want to implement singlesignon, you need to explicitly configure your system to support itby adding trusted nodes. First, you need to addthe local node to the grid as a node must be able to trust its owntokens. When you sign in to the portal, the system authenticatesusers with a single signon token issued by the local system. Theportal won't be able to sign in unless the local node is trusted. Then you add the names of other nodes in the system that should betrusted. Note: You define nodes inPortal, Node Definitions.
Tools Release	Displays the PeopleToolsrelease of the node, as defined on the Nodes - Portal page.
Description	Displays the node namedescription, as defined on the Nodes - Node Definitions page.

Note: After you update thelist of trusted nodes, the system automatically recognizes the newlist. Rebooting the application server is not required.

You can authorize thesites that users can access using single signon. The sites must belocated on nodes/databases defined on the Single Signon page (PeopleTools,Security, Security Objects, Single Signon).

There are two ways toauthorize sites for single signon:

Allow access to all sitesconfigured on the domains of nodes defined on the Single Signon page.
Create a white list ofsites of the domains defined on the Single Signon page..

Use the Authorized Sitespage to define sites authorized for single signon. To access the pageselect PeopleTools > Web Profile > Authorized Sites.

Implementing PeopleSoft-Only Single Signon (5)

Authorizing SingleSignon Sites Across All Defined Single Signon Domains

To authorize sites touse single signon across all of the domains listed on the Single Sigonpage, in the CheckToken section of the Authorized Sites page, selectAllow Domain Compare, as shown in the following example:

Implementing PeopleSoft-Only Single Signon (6)

When you select theAllow Domain Compare option, the system allows single signon acrossall authentication domains and sub-domains of the nodes that you havelisted on the Single Signon page.

Note: You must reboot theapplication server and the web server after you enable or disablethis option.

Creating a WhiteList of Sites Authorized for Single Signon

To create a white listof sites authorized for single signon, define the sites in the AuthorizedSites grid on the Authorized Sites page. The Authorized Sites gridis shown in the following example:

Implementing PeopleSoft-Only Single Signon (7)

To define a white listof sites authorized for single signon, in the Authorized Sites gridat the top of the page:

From the Protocol drop-downlist, select the protocol used on the site. The options are:
See Also
How PeopleSoft Single Signon Works? | PeopleSoft Tutorial miniOrange Identity and Access Management Evaluating a PeopleSoft Single Sign-On (SSO) Solution: 6 Questions to Ask your Vendor PeopleSoft SSO – Single Sign On Implementation
- http.
- https.
In the Host field,enter the domain of the site.
In the Port Number field, enter the port number of the domain.
Select the Check Token box.
Repeat steps 1 to 5 todefine additional sites.
Click the Save button.
Reboot the applicationserver and the web server.

Note: It’s important thatyou remember to select the Check Token option in the Authorized Sites grid for each site you want to whitelist for single signon. The Authorized Sites grid can contain siteinformation for other PeopleTools functionality. Selecting the Check Token option enables the white list functionality for the site to be usedduring token validation.

Note: You must reboot theapplication server and the web server after you add or remove a sitefrom the list.

This section providesadditional details and steps to assist the configuration of certificateauthentication used in a single signon implementation.

In the following scenario,you are configuring single signon between these two PeopleSoft systems.

Database	Node Name	Local Node	Remote Node
PeopleSoft Portal (master)	PSPORTAL	PSPORTAL	PSHCM
PeopleSoft HCM (content)	PSHCM	PSHCM	PSPORTAL

Perform these steps:

Set certificate authenticationoption in master database.
Define the portal nodeand establish trust in content database.
Create the private keyand install the digital certificate for the local node in master database.
Install the digital certificatefor the remote node in the content-side database.

Setting CertificateAuthentication Option in Master Database

To set certificate authenticationoption in master database:

Sign in to the Portal database.
Select PeopleTools > Portal > Node Definitions.
Select PSPORTAL from thelist of nodes.
Verify that it is the localnode.
Select Certificate from the AuthenticationOption drop-down list box.
Save the page.
Click the Return to Search button.
Verify that PSHCM existsas a remote node.

Defining PortalNode and Establishing Trust in Content Database

To define the portalnode and establish trust in content database:

Sign in to the HCM database.
Select PeopleTools > Portal > Node Definition.
Click the Add a New Value link.
Enter PSPORTAL andclick the Add button.
Select Certificate from the AuthenticationOption drop-down list box.
Save the page.
Select PeopleTools > Security > Security Objects > Single Signonand add the PSPORTAL message node to the list of trustednodes in the Trust Authentication Tokens issued by these Nodes groupbox.
Save the page.

Creating the PrivateKey and Installing the Digital Certificate for Local Node

To create the privatekey and install the digital certificate for the local node:

Sign in to the Portal database.
Select PeopleTools > Security > Security Objects > Digital Certificates.
Note: Make sure that RootCA with Issuer Alias of PeopleTools is available.
Click the Add a new rowbutton (+).
Select Local Node asthe Type.
Enter PSPORTAL inthe Alias field.
Select PeopleTools as the IssuerAlias.
Click the Request link.
Fill in the form
Note: For UNIX applicationservers, use 512 as the Key Size and PSPORTAL as the common name.
Click the OK button.
Select all of the text,copy the request, and click the OK button.
Request a certificatefrom your certificate provider.
Request the certificateusing a base-64-encoded CMC or PKCS #10 file, or submit a renewalrequest by using a base-64-encoded PKCS #7 file.”
When you receive the certificate,download and save it to C:\temp as newcert.cer.
Open the certificate witha text editor.
Select all of the textand copy the certificate.
Sign in to the Portal database.
Select PeopleTools > Security > Security Objects > Digital Certificates.
Click the Import linkfor the PSPORTAL alias.
Paste the certificate intothe text box.
Note: Make sure that thereis no space after END CERTIFICATE, otherwise, you are not allowedto save.
Click the OK button.

Installing DigitalCertificate for the Remote Node in the Content-Side Database.

To install the digitalcertificate for the remote node in the content-side database:

Sign in to the HCM database.
Navigate to PeopleTools > Security > Security Objects > Digital Certificates.
Click the Add a new row button (+).
Select Remote Node as the Type.
Enter PSPORTAL inthe Alias field.
Select PeopleTools as the IssuerAlias.
Click the Import link.
Open the certificate thatyou downloaded to C:\temp\newcert.cer with a text editor.
Copy the text and pastethe digital certificate into the empty edit box.
Click the OK button.

Now that you have ageneral understanding of why a single signon implementation is useful,and some of the details involved with PeopleSoft-only single signon,this section presents an example of how the PeopleSoft-only singlesignon scheme works.

In this scenario thereare two databases, or nodes: an HCM database and Financials database. Recall that the terms database and node are synonymous. Each databasehas one application server and one web server. The following stepsdescribe the “back-end” events that occur when a user signs in tothe HCM database, completes a transaction, and then clicks a linkthat targets a page in the Financials database.

Step 1: User SignsIn to an HCM Application

The following occurs:

Step 2: ApplicationServer Authenticates User

The following occurs:

The web server relays signin request to the HCM application server.
The HCM application serverauthenticates the user.

Step 3: ApplicationServer Generates Single Signon Token

The following occurs:

If the user is authenticatedby the application server, then it generates a single signon token.
The application serverencrypts and encodes the token (base 64).
The application serversends the token to the web server, along with a return code indicatingthat the system authenticated the user.

Step 4: Web ServerCreates Cookie in User's Browser

When the web serverreceives the single signon token from the application server, it createsa cookie and inserts the cookie in the user's browser.

If the browser is configuredto show the Security Alert dialog, then the user sees a message similarto the following example. In most cases, you don't configure browsersto show this dialog; this dialog box is just an example of the datathat the browser receives.

Implementing PeopleSoft-Only Single Signon (8)

The cookie that theweb server distributes for PeopleSoft single signon is named PS_TOKEN. In this case the domain mydomain.example.com set the cookie.

Notice that the cookieexpires at the end of session. This indicates that the system neverwrites the cookie to disk, the cookie exists in browser memory forthe duration of the session only.

The web server insertsthe single signon token within the Data field of the cookie. So thatthe system can send the binary data across the HTTP protocol, thetoken data is encrypted and base 64 encoded.

Step 5: User Needsto Access Financial Application

After the user completesa few transactions in the HCM system, suppose they arrive at a pagecontaining a link to the Financial system. The user clicks the link,and because they've already entered their credentials for the HCMsystem they don't need to sign in again.

The browser sends thePS_TOKEN cookie to the Financials web server.

Step 6: FinancialsWeb Server Receives PS_TOKEN Cookie

The Financials web server does detectthat the user hasn't been authenticated by the Financials system yet.However, because the web server received the signon cookie it doesnot display the sign in page.

To retrieve the pagethe user requested (by way of the link in the HCM application), theFinancials web server attempts to connect to the Financials applicationserver. It passes only the Data field from the PS_TOKEN cookie becausethe application server needs only the information in the Data portion.

Step 7: FinancialsApplication Server Authenticates PS_TOKEN

Before allowing theuser to connect, the Financials application server evaluates the PS_TOKENData field in the following flow:

Is the forwarding nodetrusted?
The application server checks to see that the message node name listedas the Issuing System is a trusted node. The list of trusted nodesfor the Financials system resides in the PSTRUSTNODES table. Youconfigure the list using PeopleTools, Security Objects, Single Signon. The Single Signon page enables the administrator of the Financialssystem to "trust" authentication tokens generated from HCM as wellas any other nodes deemed trusted.
Has the token expired?
The applicationserver checks that the authentication token hasn't expired. Usingthe Issued Date and Time field within the token, the Financials applicationserver makes sure that the token was issued within the interval betweenthe timeout minutes value and the current time. You configure a token'sexpiration time on the Single Signon page.
Note: It is important to notethat the expiration parameter specified in the Financials system isthe relevant value, not the expiration value specified in HCM. Thisenables the Financials administrator to control the maximum age ofan acceptable token. It's also important to consider that all timesare in Greenwich Mean Time (GMT), so it doesn't matter what time zonesthe systems are in.
Has the signature beentampered with?
The application serverchecks that the signature is valid. The Financials application servertakes all the fields in the token and the Node password for the issuingnode and generates a hash. The token is valid only if the signaturewithin the token exactly matches the one generated by the Financials applicationserver. Because an exact match is the only acceptable situation,Financials can be sure that HCM generated the token, and that it hasn'tbeen tampered with since it was generated. If a hacker interceptedthe token in transit and changed the User ID, Language, and so on,the signatures wouldn't match and as a result the Financials applicationserver would reject the token.
Note: You should use digitalcertificate authentication when implementing single signon.

The following topicsdescribe some items you might want to consider as you implement yoursingle signon configuration.

Single AuthenticationDomain Limitation

Web servers must beassigned to the same authentication domain—the server name in theURLs used to access them must contain the same domain name. A browsersends a cookie back only to the same domain from which it receivedthe 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 thatyou specify during Pure Internet Architecture setup, and its purposeis to associate different web servers (even at different physicallocations) so that they appear to be at the same location to the PeopleSoftapplications that use those web servers.

Important! Specifying authenticationdomains incorrectly for multiple Pure Internet Architecture installationscan produce single signon errors.

If you want to keeptwo PeopleSoft applications from erroneously attempting to employsingle signon, make sure that the authentication domain you specifyfor one application's web server is not a subset of the authenticationdomain you specify for the other. For example, if your CRM web serverhas 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 twoPeopleSoft applications to employ single signon, you must ensure thateach 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 webserver that generates the cookie must have the domain that sharesthe PS_TOKEN cookie specified in the web profile of the local PureInternet Architecture web site. For example, in the context of ourHCM to Financials example, the web profile for the HCM web servermust contain the value of .example.com in the AuthenticationDomain property.

Note: You must specify theleading dot (.).

The single domain issuesoccur in the following situations:

You're using straight PureInternet Architecture, as in you are deploying applications but notby way of the portal.
You're using the portalwith frame-based templates. All PeopleSoft portal solutions products(Enterprise, Employee, Customer, Supplier portals) are built usingframe-based templates.

Frame-based templatesaren't proxied automatically. Proxying refers to when the system rewritesthe URL to point to a location on the portal servlet, rather thanthe original location of the URL.

Single Signon BetweenMachines without DNS Entries

If you're setting upsingle signon between machines that don't have DNS entries, you needto 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 tosignon to the web server a.example.com, and then access b.example.comusing single signon. In this situation, you would need to update thehosts 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 host192.0.2.8 localhost203.0.113.4 a.example.com198.51.100.5 b.example.com

Domain Names

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

This is an example of a correctly formattedURL: http://hcm.example.com/myapplication/signon.html
This is an example of a incorrectly formattedURL: 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 matchthe fully qualified domain name you enter as the authentication domain.For example, you must specify myserver.example.com/servlets, not myserver/servlets.

Cross Domain SingleSignon

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

You can configure yourenvironment to support cross-domain single signon by completing thefollowing configuration tasks.

Setup a third-party websecurity product that supports multi-domain single signon and supportsLDAP user profiles.
There are several industry-standard products on the market.
Configure the portal andcontent provider web servers to trust the web server for authentication.
For PeopleSoftapplications , this involves creating and enabling the public accessuser.
Set up the PeopleSoft applicationsto download the user profiles from the same LDAP server that the websecurity product uses.
This means that the DNthat comes from the subject field of the certificate has to be a validDN for the directory that the LDAP_profilesynch function references. Because of this you need to build a user profile cache map that pointsto the same directory that generated the subject's DN.

Note: This cross-domain limitationdoes not apply to the portal if the content from the provider in adifferent domain is wrapped in an HTML template. However, this limitationdoes apply for any content in the portal that is wrapped in a frametemplate. Because the Enterprise, Customer, Supplier, and Employeeportals that ship with PeopleTools all include frame templates asdefaults, you'll need to perform the extra configuration steps tosupport cross-domain single signon in multi-domain environments. This limitation also applies to Pure Internet Architecture-to-PureInternet Architecture (iClient-to-iClient) single signon.

The following topicsdescribe examples of single signon configurations and the steps requiredto implement them.

One Database andTwo Web Servers

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

To set up single signonwith one database and multiple web servers:

Select PeopleTools > Portal > Node Definitions and make sure that at least one node is defined asthe Default Local Node.
In the results on the search page, you can determine this by lookingfor a Y in the DefaultLocal Node column.
Select PeopleTools > Security > Security Objects > Single Signon and set the following:
- Make sure the Default LocalNode appears in the list under Trust Authentication Tokensissued by these Nodes.
- Set the timeout minutesto an appropriate value (the default is 720).
Access the web profilefor each web server and modify the Authentication Domain property.
Because single signonis implemented using browser cookies, it must be configured so thatthe user's browser sends the single signon cookie to each web servermachine involved. By default, the browser only sends cookies backto the machine that set the cookie. So if web server a.example.comsets a cookie after the user is authenticated, the browser (by default)only sends the cookie to a.example.com. By default, the browser wouldnot send the cookie to b.example.com. To make the browser send thesingle signon cookie to all servers at in a domain (example.com),access the Web Profile Configuration - General page and set a valueof .example.com for the Authentication Domain property.
Note: You need the leadingperiod (.) before the domain. It should appear as “.example.com,” not “example.com.”
If you use only oneweb server, you don’t need to modify the Authentication Domain property. A web server is designed to accept the cookies it distributes.

Two Databases andTwo Web Servers

To set up single signonwith multiple databases and multiple web servers:

Select PeopleTools > Portal > Node Definitions.
For each node that you want to involve in the single signon configurationand check the following:
- Make sure that at leastone node definition is defined as the Default Local Node for eachdatabase.
  In theresults on the search page, you can determine this by looking fora Y in the Default Local Node column.
- Make sure that each databasecontains a node definition for the other nodes in the single signonconfiguration.
- Make sure that the Authentication Option is set correctly.
  For example, if you are using password authentication make sure thatthe node password for node ‘X’ is the same in each node definitionfor node ‘X’ in each database.
  If you use digital certificateauthentication, make sure the certificates are properly installedin the PeopleSoft Keystore before setting the node’s AuthenticationOption to Certificate.
Select PeopleTools > Security > Security Objects > Single Signon and set the following:
- Make sure the Default LocalNode appears in the list under Trust Authentication Tokensissued by these Nodes.
- Set the timeout minutesto an appropriate value (the default is 720).
Access the web profileon your web server and modify the Authentication Domain property.
Becausesingle signon is implemented using browser cookies, it must be configuredso that the user's browser sends the single signon cookie to eachweb server machine involved. By default, the browser only sends cookiesback to the machine that set the cookie. So if web server a.example.comsets a cookie after the user is authenticated, the browser (by default)only sends the cookie to a.example.com. By default, the browser wouldnot send the cookie to b.example.com. To make the browser send thesingle 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 withThird Party Authentication

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

This discussion assumesthat you have enabled public user access in the web profile for theappropriate site.

See Creating a Public Access User.

Note: While this example doesnot cover authentication, it assumes that you have set up your third-partyauthentication correctly. Third-party authentication is out of thescope for PeopleSoft support and documentation.

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

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

The following examplesaddress steps 3, 4, and 6.

The following HTML appliesto step 3 above. You can change the JavaScript function to set thecookie name and value that you want. Also, change the location topoint 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 ExampleIn this example, security is non-existent. In a productionsystem, the UserId could come from your site's single signontool. Other information could also be included. For thisexample, only the UserId is saved into cookie. This cookie thengets sent to the PIA Web Servlet which passes it on to thePeopleSoft Application Server. A piece of Signon PeopleCode isneeded to extract the UserId from the cookie and callSetAuthorizationResult 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 SignonPeopleCode example applies to steps 4 and 6 above. The Signon PeopleCodeneeds to retrieve &UserID from where the third-party portal putit 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-IfEnd-Function;

After you write theprogram, you need to enable the program using the Signon PeopleCodepage (PeopleTools > Security > Security Objects > Signon PeopleCode).

PeopleSoft single signonfunctionality also applies at the web server level. For example,let's say that you have two web servers: server X and server Y. Assumethat web server X is an SSL/TLS site, and assume that web server Yis not. In these situations, many organizations want server Y totrust the authentication token, PS_TOKEN, issued by server X. Thisrequires that the PS_TOKEN be set to be secure.

If the PS_TOKEN is notmarked as secure, then when a user signs in through server Y, thebrowser sends PS_TOKEN to server Y over the unencrypted, non-SSL/TLSlink. This is typical behavior for browsers when dealing with non-securecookies. Potentially, in this situation a hacker could identify thistoken from the clear network and use it to signon to the SSL/TLS-secureserver X.

Another important useof this feature relates specifically to the PeopleSoft InteractionHub. When the portal proxies content with an HTML template, it shouldforward PS_TOKEN cookies that are marked secure only over SSL/TLSconnections.

To resolve this potentialsecurity issue, select the Secure Cookie with SSL check box on the Web Profile Configuration - Security page. Youuse this property to control the secure attribute of the single signoncookie. If you enable the property, and the scheme of the currentrequest is HTTPS (an SSL/TLS server), the system sets the secure attributeof the single signon cookie (PS_TOKEN) to true. This prevents thesingle signon token from travelling over an insecure network.

Note: If you enable this property,you are effectively disabling single signon to any non-SSL/TLS servers.

If, at your site, youwant users to sign in to an HTTPS server, and then want to do singlesignon with HTTP servers, set this property to false, which allowssingle signon between HTTPS and HTTP servers.

Note: If you can toleratethe security risk, and want single signon between secure and non-securelinks, you can set this flag to false. However, before doing thismake sure you are aware of all the security implications, such asthe security of the HTTPS server may be compromised.

PeopleSoft providesa component interface named PRTL_SS_CI that enables external applicationsto seamlessly integrate a single signon solution with the PeopleSoftportal applications. This ensures that users who have already signedin to the portal don't have to sign in again for every system youreference in your portal.

To take advantage ofthe Single Signon API, you need to create a custom API, which includesbuilding the dynamic link libraries, classes, and registry settingsnecessary to enable an external application to communicate with PeopleSoftsoftware.

Note: Due to constraints imposedby the PeopleCode SwitchUser built-in function, PRTL_SS_CI does not work properly when calledfrom PeopleCode. Only external applications, such as Java, VisualBasic, and C/C++ programs, can access PRTL_SS_CI.

The files of your customAPI need to reside on the client machine; that is, the web serverfor ASP, and the machine running the Java program for Java. The registryfile may also need to be executed to update the registry with thenew libraries.

Understanding theSignon Process with the API

The PRTL_SS_CI ComponentInterface contains two user-defined methods:

Authenticate
Your externalauthentication program distributes an authentication token that canbe retrieved from a cookie in the browser. The Authenticate functiondetermines if an authentication token is valid.
GetUserID
If the token isvalid, you use the GetUserID function to retrieve the User ID associatedwith the authentication token.

Before we describe thedevelopment requirements of your API, PeopleSoft recommends that youtake a moment to examine the steps that occur internally when youuse the API in conjunction with the delivered PRTL_SS_CI.

Step	Description
1	The user enters theUser ID and password into the PeopleSoft portal sign in page.
2	If the login on portalapplication server is successful, the server generates a single signontoken. The web server receives the single signon token from the applicationserver, and issues a cookie to the browser.
3	The user navigates inthe portal and encounters a link to the external system. The userclicks the link.
4	The browser passes thePS_TOKEN cookie to your external web server.
5	The external web serverchecks for the PS_TOKEN cookie before displaying a sign in page.
6	Once it is determinedthat the user is accessing your application through the PeopleSoftportal, you retrieve the authentication token and send it to the PRTL_SS_CIcomponent interface to verify authentication.
7	After the system authenticatesthe token, the system can then make calls to the PRTL_SS_CI.Get_UserIDfunction to return the appropriate User ID.

Developing yourExternal Application to Support Single Signon

Developers of the externalapplications need to alter the signon process to conform to the followingrequirements.

Check for the PS_TOKENcookie.
If thecookie doesn’t exist, continue with your normal signon process. Otherwise,bypass the sign in page.
Retrieve the authenticationtoken from the PS_TOKEN cookie.
Make a connection to thePeopleSoft system through the PRTL_SS_CI API.
Pass the authenticationtoken to the Authenticate() function of the API.
If the function returnsTrue, you then the Get_UserID() function retrieves the user ID associated withthe authentication token.

Note: The component interfaceis not mapped to data because the key field for the data would bethe authentication token. This token is dynamically assigned whenthe user signs in to the portal, and it is not stored anywhere inthe system as data. Therefore, there are no key fields and the tokenis passed directly to the user defined functions.

In addition to singlesignon, the PeopleSoft system also signs the user off of content providerswhen the user signs off. However, there are some exceptions to thesign-off functionality.

The portal only signsout content providers that meet the following criteria:

Content providers are accessedonly through HTML templates.
Content providers are allPeopleSoft 8.x or higher applications.

This means that forcontent providers accessed through frame templates, single sign offis not automatically enabled when you configure single signon. Thissection describes the steps you need to complete to configure singlesign-off for content providers being accessed through frame templates,which includes all of the PeopleSoft Portal solutions (Employee, Customer,and so on).

The following procedurecovers inserting an HTML image tag <img> containing a logout commandinto a set of files on the web server. When the user signs off, thebrowser attempts to download the images using an "HTTP get," whichcauses the system to send the logout command to each specified contentprovider.

This procedure is notappropriate for content that is never accessedusing a frame, as in it is accessed from the content source usingan iScript and a business interlink, such as Lotus Notes integration.

To configure singlesign-off for frame content:

On your web server, locateand open signin.html.
Open signon.html, selectSave As, and enter the name signout.html.
Open signout.html, expire.html,and exception.html.
Add the following imagetags to these files.
You need to add one image tag to each of these files for each contentprovider that requires single signoff.
Add the tags just beforethe closing body tag, as shown:
```
<! add tags here></body>
```
If you have three contentproviders that require single signoff, such as HCM, FIN, and HTMLAccess, you need to add three image tags to each file.
For example:
```
<IMG src="http://hcm.myserver.com/servlets/psp/ps/hrdb/?cmd=logout"height=0 width=0 border=0><IMG src="http://fin.myserver.com/servlets/psp/ps/hrdb/?cmd=logout"height=0 width=0 border=0><IMG src="http://htmlaccess.example.com/html_access/system/init_asp/logout.asp?cmd=dummy"height=0 width=0 border=0>
```
The previous code isan example. To determine the exact URL you need to add for your implementation,right-click the logout link of each content provider. You can usuallyview the logout link when accessing the application outside of theportal. Examine the properties of this link, and add the specifiedURL to the image tag.
Note: The string "cmd=dummy"is required in the image tag for HTML Access to make sure that thebrowser doesn't attempt to cache the image, which would prevent itfrom issuing the logout command.
Select PeopleTools > Web Profile > Web ProfileConfiguration > Look and Feel on your web server.
In the Signon/Logout Pages group box, change the value of the Logout Page field to signout.html.