Understanding Single Signon

This section discusses:

  • Single signon options.

  • The PS_TOKEN cookie.

Single signon refers to the ability of users to navigate freely within a system of multiple applications after only being authenticated once. There are three different ways to configure single signon, depending on the participating applications that you have installed. The following table displays the single signon options.

Single Signon Option

Description

PeopleSoft-only

This option enables single signon only between multiple PeopleSoft applications, such as PeopleSoft Human Capital Management and PeopleSoft Customer Relationship Management. After a user is authenticated by one PeopleSoft application, an in-memory value gets set in the browser (PS_TOKEN cookie) that the next PeopleSoft application uses for a user credential.

If you have only PeopleSoft applications, use this option.

Note: This option is the same single signon feature offered in previous PeopleSoft releases.

See Implementing PeopleSoft-Only Single Signon.

PeopleSoft and Oracle applications

If you have Oracle applications and PeopleSoft applications being used in your organization, users who have been authenticated by the Oracle system can freely access PeopleSoft applications without having to be re-authenticated.

This option is tailored for sites running their PeopleSoft applications on Oracle WebLogic .

This option applies to all previous PeopleTools 8.x versions. For example, if you intend to incorporate applications running on Enterprise PeopleTools 8.53, you can implement this option.

See Implementing Oracle Access Manager as the PeopleSoft Single Signon Solution.

Note: You must ensure that before users attempt to use the single signon functionality, a valid user profile is defined for each user in each participating application database. You can accomplish this in a variety of ways, such as automatically generating user profiles based on users' LDAP information, replicating user profiles through Integration Broker at initial sign in, or manually defining user profiles for the authorized users before going live.

Note: Many single signon solutions require that you create a generic user profile with minimal permissions and set up this user as the default or public access user. You find information for creating the public access user profile in this documentation. You find information for specifying the identity of the public access user in the product documentation for PeopleTools 8.55: Portal Technology.

When the system authenticates a user, it distributes the PS_TOKEN cookie to the browser. The PS_TOKEN cookie holds user authentication information in the browser that a PeopleSoft system uses to verify user access. Having the token in the browser memory allows the user to navigate freely within the system without having to provide user credentials repeatedly.

The key security features of the PS_TOKEN cookie authentication are:

  • The cookie exists in memory; it is not written to disk.

  • There is no password stored in the cookie.

  • You can set the expiration of the cookie to be a matter of minutes or hours; so if a cookie is intercepted it will only be usable for the duration you specify.

The following table presents the fields that appear in the PeopleSoft authentication token:

Field

Description

UserID

The user ID of the user to which the server issued the token. When the browser submits this token for single signon, this is the user that the application server logs on to the system.

Language Code

Specifies the language code of the user. When the system uses his token for single signon, it sets the language code for the session based on this value.

Date and Time Issued

Specifies the date and time the token was first issued. The system uses this field to enforce a time out interval for the single signon token. Any application server that accepts tokens for signon has a timeout minutes parameter configured at the system level. A system administrator sets this parameter using the PeopleTools Security, Single Signon page. The value is in Greenwich Mean Time (GMT) so it does not matter which time zone the application server is in.

Issuing System

Shows the name of the system that issued the token. When it creates the token, the application server retrieves this value from the database. Specifically, it retrieves the defined Local Node. You configure a node only to trust single signon tokens from specific nodes. Consequently, an application server needs the name of the issuing system so that it can check against its list of trusted nodes to see if it trusts the issued token.

Note: Single signon is not related to Integration Broker, except for the fact that single signon functionality leverages the use of nodes and local nodes.

Signature

This field contains a digital signature that enables the application server using a token for single signon to ensure that the token hasn't been tampered with since it was originally issued. The system issuing the token generates the signature by concatenating the contents of the token (all the fields that appear in this table) with the node definition password for the local node. Then the system hashes the resulting string using the SHA1 hash algorithm. For example ("+" indicates concatenation), 

signature =  SHA1_Hash ( UserID + Lang + Date 
Time issued + Issuing System + Local Node Pswd )

There is only one way to derive the 160 bits of data that make up the signature, and this is by hashing exactly the same User ID, Language, Date Time, Issuing System, and node password.

Note: If you are using digital certificate authentication, the signature of the digital certificate occupies this space. The above description applies to using password authentication only.

Note: Single signon does not depend on Lightweight Directory Access Protocol (LDAP) directory authentication. You can implement single signon and not LDAP, you can implement LDAP and not single signon, or you can implement both LDAP and single signon.