Understanding the PS_TOKEN Cookie

    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 messaging, except for the fact that single signon functionality leverages the messaging concept 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 message node 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.