12 Understanding JD Edwards EnterpriseOne Single Sign-On

This chapter contains the following topics:

12.1 JD Edwards EnterpriseOne Single Sign-On Overview

JD Edwards EnterpriseOne single sign-on enables users that are signed in to either PeopleSoft Enterprise Portal or JD Edwards Collaborative Portal to access JD Edwards EnterpriseOne applications without re-entering a user ID and password. Single sign-on provides these benefits:

  • Allows users to navigate between PeopleSoft Enterprise Portal and JD Edwards EnterpriseOne applications seamlessly.

  • Increases the security for the JD Edwards EnterpriseOne system since passwords are no longer passing between different sub-systems in JD Edwards EnterpriseOne.

    Note:

    JD Edwards EnterpriseOne does not support single sign-on between JD Edwards EnterpriseOne applications and third-party applications.

12.2 Authenticate Tokens

JD Edwards EnterpriseOne uses an authenticate token to achieve single sign-on. The authenticate token contains criteria that grants access to a JD Edwards EnterpriseOne application from PeopleSoft Enterprise Portal or JD Edwards Collaborative Portal. When a user signs on to either system, after successful authentication, the system generates an authenticate token. When a user accesses an JD Edwards EnterpriseOne application, the system uses the generated token to validate the user against the JD Edwards EnterpriseOne security server. As a result, the user does not have to manually sign on to the system again.

When a user signs on to either system, an authenticate token is generated after successful authentication. When the user accesses an EnterpriseOne application, the system uses the generated token to validate the user against the EnterpriseOne security server. As a result, the user does not have to manually sign on to the system again.

For security purposes, all authenticate tokens expire after a certain period of time and contain a digital signature that ensures the token cannot be tampered with.

An authenticate token contains these properties:

Property Description
User ID The user ID that the server issued the token for. When the browser submits this token for single sign-on, this is the user that the application server signs in to the system.
Language Code The language code of a user. When the system uses a token for single sign-on, it sets the language code for the session based on this value.
Date and Time Issued The date and time the token was first issued. The system uses this field to enforce a time-out interval for the single sign-on token. Any application server that accepts tokens for sign-on compares this value against the amount of time set in the application server to accept tokens. The value is in Greenwich Mean Time (GMT) so it does not matter which time zone the application server is in.

Note: The system date and time is used to validate the expiration of a token. Changing these values on the server may expose a potential security risk.
Issuing Node Name The name of the machine that issued the token.
Signature A digital signature that the application server (node) uses to validate the token for single sign-on by ensuring that the token has not been tampered with since it was originally issued. The machine 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 Node Name+ Issuing Node Password)

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

12.3 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 iSeries 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 iSeries 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 iSeries. To resolve this issue, on the iSeries server, you should change the QUTCOFFSET value manually whenever there is a change in daylight savings time to ensure proper calculation of GMT time.

12.4 How a Node Validates an Authenticate Token

The node validates an authenticate token by checking whether:

  • The token signature has been changed.

  • The token is expired.

  • The token is generated by a trusted node.

This diagram is an example of token validation in a multiple node setup:

Figure 12-1 Token validation in a multiple node setup

Description of Figure 12-1 follows
Description of "Figure 12-1 Token validation in a multiple node setup"

According to this configuration, the following tokens are validated by a node:

  • Node A validates tokens generated by node B and node C if received less than 30 minutes from generation.

  • Node B validates tokens generated by node A if received less than 60 minutes from generation.

  • Node C validates tokens generated by node B if received less than 90 minutes from generation.

The following tokens are not validated by a node:

  • Node B cannot accept a token generated by node C, even though node C trusts node B.

  • A node will not accept a token if the time between its generation and reception by the node is greater than the token lifetime set for that node. For example, node A cannot accept a token from node B if the token was generated more than 30 minutes prior to being received by node A.

    Note:

    No node will accept a token if its signature has been changed. The system verifies this by comparing the token signature and the hash value of the token body.

12.5 Single Sign-On Scenarios

This section discusses how single sign-on works in these scenarios:

  • Launching a JD Edwards EnterpriseOne application from PeopleSoft Enterprise Portal.

  • Launching a JD Edwards EnterpriseOne application from JD Edwards Collaborative Portal.

12.5.1 Launching a JD Edwards EnterpriseOne Application from PeopleSoft Enterprise Portal

The illustration and steps in this section explain how single sign-on works when a user signs in to PeopleSoft Enterprise Portal and launches a JD Edwards EnterpriseOne application:

Figure 12-2 Single sign-on between PeopleSoft Enterprise Portal and JD Edwards EnterpriseOne applications

Description of Figure 12-2 follows
Description of "Figure 12-2 Single sign-on between PeopleSoft Enterprise Portal and JD Edwards EnterpriseOne applications"

  1. The user signs in to PeopleSoft Enterprise Portal in a Web browser using a PeopleSoft Enterprise user ID and password.

  2. The web browser sends the user ID and password to the PeopleSoft Enterprise application server (node).

  3. The PeopleSoft Enterprise application server authenticates the user credentials and generates an authenticate token.

  4. The PeopleSoft Enterprise application server delivers a cookie containing an authenticate token to the Web browser.

  5. The web browser stores the cookie on the local machine.

  6. The end user tries to launch a JD Edwards EnterpriseOne application through PeopleSoft Enterprise Portal.

  7. The PeopleSoft Enterprise Portal sends the authenticate token to the JD Edwards EnterpriseOne application server.

  8. The JD Edwards EnterpriseOne application server validates the token (through the JD Edwards EnterpriseOne security server).

12.5.2 Launching a JD Edwards EnterpriseOne Application from JD Edwards Collaborative Portal

The illustration and steps in this section explain how single sign-on works when a user signs in to JD Edwards Collaborative Portal and launches a JD Edwards EnterpriseOne application:

Figure 12-3 Single Sign-on between JD Edwards Collaborative Portal and JD Edwards EnterpriseOne applications

Description of Figure 12-3 follows
Description of "Figure 12-3 Single Sign-on between JD Edwards Collaborative Portal and JD Edwards EnterpriseOne applications"

  1. The user signs in to JD Edwards Collaborative Portal through a web browser using a JD Edwards EnterpriseOne user ID and password.

  2. The system sends the user ID and password to the JD Edwards Collaborative Portal.

  3. JD Edwards Collaborative Portal authenticates the user ID and password against either LDAP, JD Edwards EnterpriseOne tables, or WebSphere security.

  4. A token is generated for the user ID.

  5. When single sign-on is required for JD Edwards EnterpriseOne, the token is sent to either a JAS Server or a JD Edwards EnterpriseOne application server.

  6. The JD Edwards EnterpriseOne security server validates the token and grants access to the JD Edwards EnterpriseOne application.