Nodes

A node is a machine that can generate or validate an authenticate token. The node contains properties that you set to control security and specify parameters for which tokens the node will accept. The system stores the node properties in the database or the jde.ini files, depending on your particular setup.

Each node contains these properties:

Property	Description
Node name	A logical name associated with this node. The length of the node name cannot exceed 15 characters.
Node password	Each node has a password which is known only by the system administrator. It serves as a key to ensure that the token does not get tampered with after it is generated.
Physical machine name	The physical machine name in which the node resides.
Trusted nodes list	This property contains the list of nodes that can be trusted by this node. For security purposes, only tokens that are generated by predefined machines can be accepted. These predefined machines are called trusted nodes. The trusted node is one-way, for example if you set up node A to trust node B, it does not mean that node B trusts node A.
Token lifetime properties	When validating a token, the node checks the time the token was issued against the amount of time that you set in the token lifetime properties. For example, if you set the token lifetime for six hours, and the node receives a token that was originally issued seven hours prior, the node will not accept the token. You can use these two properties to specify the token lifetime: Regular token lifetime This property specifies the expiration time for a regular token. A regular token gives a user the authority to run a regular short-run process, such as a business function. The default value for this property is 12 hours. Extended token lifetime This property specifies the expiration time for an extended token. An extended token gives a user the authority to run a long-run process, such as a UBE, after it is issued. The default value for this property is 30 days.

Note: On the IBM i platform, GMT time calculation does not take into account daylight savings time. Consequently, there can be a one hour difference in GMT time calculation between tokens generated on IBM i and Windows platforms. If you set the token timeout values as 12 hours (the default) or longer, you will notice this issue in sessions running for longer than 11 hours. If you set the token timeout values as less than one hour, then the tokens generated on Windows will automatically expire on IBM i. To resolve this issue, on the IBM i server, you should change the QUTCOFFSET value manually whenever there is a change in daylight savings time to ensure proper calculation of GMT time.