(From the Enterprise PeopleTools 8.46 PeopleBook: Security Administration)
PeopleSoft software supports single signon within PeopleSoft applications. Within the context of your PeopleSoft system, single signon means that after a user has been authenticated by one PeopleSoft application server, that user can access a second PeopleSoft application server without entering an ID or a password. Although the user is actually accessing different applications and databases, the user navigates seamlessly through the system. Recall that each suite of PeopleSoft applications, such as HR or CRM, resides in its own database.
Note. The PeopleSoft single signon solution applies only to PeopleSoft applications.
After the first application server/node authenticates a user, the system delivers a web browser cookie containing an authentication token. Pure Internet Architecture uses web browser cookies to store a unique access token for each user after they are authenticated initially. When the user connects to another PeopleSoft application server/node, the second application server uses the token in the browser cookie to re-authenticate the user behind the scenes so they don’t have to complete the signon process again.
Single signon is critical for PeopleSoft portal implementations because the portal integrates content from various data sources and application servers and presents them in a unified interface. When the users sign on through the portal, they always take advantage of single signon. Users need to signon once and be able to navigate freely without encountering numerous signon screens. Because single signon is so integral to the portal, you always need to configure it before deploying a live portal solution.
Note. The browser cookie is an in-memory cookie and is never written to disk. The cookie is also encrypted to prevent snooping and digitally signed using a check sum to prevent tampering.
The following table presents the fields that appear in the PeopleSoft authentication token:
|UserID||This field contains 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||This field 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||This field 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||This field 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. Single signon is not related to Integration Broker messaging, except for the fact that single signon functionality leverages the messaging concept of nodes and local nodes. 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.|
|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 message node password for the local node. Then the system hashes the resulting string using the SHA1 hash algorithm. For example ("+" means 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.
The key security features of the cookie authentication token 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, which is hardly enough time for a hacker to decrypt the information.