11 Setting Up JD Edwards EnterpriseOne Single Sign-On

This chapter contains the following topics:

11.1 JD Edwards EnterpriseOne Single Sign-On Overview

JD Edwards EnterpriseOne single sign-on enables users that are signed in to JD Edwards Collaborative Portal to access EnterpriseOne applications without re-entering a user ID and password. Single sign-on increases the security for the EnterpriseOne system since passwords are no longer passing between different sub-systems in EnterpriseOne.

Note:

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

11.1.1 Authenticate Tokens

EnterpriseOne uses an authenticate token to achieve single sign-on. The authenticate token contains criteria that grants access to an EnterpriseOne application from 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 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.

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.

11.1.2 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.

11.1.3 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 11-1 Token validation in a multiple node setup

Description of Figure 11-1 follows
Description of ''Figure 11-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.

11.1.4 Single Sign-On Scenario: Launching an 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 an EnterpriseOne application:

Figure 11-2 Single Sign-on between JD Edwards Collaborative Portal and EnterpriseOne applications

Description of Figure 11-2 follows
Description of ''Figure 11-2 Single Sign-on between JD Edwards Collaborative Portal and EnterpriseOne applications''

  1. The user signs in to JD Edwards Collaborative Portal through a web browser using an 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, EnterpriseOne tables, or WebSphere security.

  4. A token is generated for the user ID.

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

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

11.2 Understanding the Default Settings for the Single Sign-On Node Configuration

By default, when there is no configuration table specifications in the system and no configurations in the jde.ini file, the security server uses these settings for node information:

Setting Description
Logical Node Name _GLOBALNODE
Physical machine name N/A (The default settings are all the same independent of the physical machine that it is residue in.)
Regular token timeout 12 hours
Extended token timeout 30 days
Trusted node _GLOBALNODE

As a result, the EnterpriseOne system will generate a token with node name _GLOBALNODE, and it will only accept a token with node name _GLOBALNODE.

Note:

Using default settings may expose a potential security risk. Thus, it is highly recommend to overwrite the single sign-on settings using the single sign-on configuration applications discussed in this section.

11.3 Setting Up a Node Configuration

This section provides an overview of the single sign-on configurations and discusses how to:

  • Add a node configuration.

  • Revise a node configuration

  • Change the status of a node.

  • Delete a node configuration.

11.3.1 Understanding Single Sign-On Configurations and Their Relationships

In EnterpriseOne, the node configurations are stored in a database. The node lifetime configuration is the configuration for the existing node, and the nodes in the trusted node configuration must have an existing node that has the lifetime configurations. The node properties are stored in these three database tables:

  • Node Configuration Table (F986180). This table contains the information of a node in the single sign-on environment, such as the node name, description, machine name, node status (active/inactive), and the password.

  • Node Lifetime Configuration Table (F986182): This table contains the lifetime information for an existing node. The node lifetime configuration information, such as the node name, regular token lifetime, and extended token lifetime.

  • Trusted Node Configuration Table (F986181): This table contains the trust relationship between two nodes.

This diagram shows the relationship among these tables:

Figure 11-3 Single sign-on table relationships

Description of Figure 11-3 follows
Description of ''Figure 11-3 Single sign-on table relationships''

This configuration requires that you configure the single sign-on settings in this order:

  1. Set up node information.

  2. Set up node lifetime.

  3. Establish the trust between nodes.

You should delete the single sign-on settings in this order:

  1. Delete the trusted node relationship.

  2. Delete the node lifetime.

  3. Delete the node information.

Alternatively, you can delete the node information directly by deleting the node record in the F986180 table. The system will automatically delete the record's corresponding entries in the Node Lifetime (F986181) and Trusted Node (F986182) tables.

11.3.2 Adding a Node Configuration

Access the SSO Environment Configuration Tools form. In JD Edwards Solution Explorer, select System Administration Tools (GH9011), User Management, User Management Advanced and Technical Operations, and then double-click SSO Environment Configuration Tools.

  1. Click the Single Signon Node Configuration link.

  2. On the Work With Node Configuration form, click Add.

  3. On the SSO Node Configuration Revisions form, complete these fields:

Field Description
Node Name Enter a logical name associated with this node. The length of the node name cannot exceed 15 characters.
Node Description Enter a description of the node.
Machine Name Enter the physical machine name where the node resides.
Node Status Specify whether the node is active or inactive.
Node Password Enter a password for the node. The password ensures that tokens that are generated from the node do not get tampered with.
Verify Node Password Re-enter the password.

11.3.3 Revising a Node Configuration

Access the Work With Node Configuration form.

  1. Select a node and then click Select.

  2. On SSO Node Configuration Revision, modify the appropriate fields.

11.3.4 Changing the Status of a Node

Access the Work With Node Configuration form.

Select the node and then from the Row menu, select Active/Inactive to change the status of the node.

11.3.5 Deleting a Node Configuration

Deleting an existing node configuration results in the removal of its lifetime configuration and trusted node configuration records in F986181 and F986182 respectively.

Access the Work With Node Configuration form.

  1. Select the node that you want to delete and click Delete.

    A warning message appears informing you of the corresponding records that are deleted when you delete a node configuration.

  2. Click OK to delete the node configuration.

11.4 Setting Up a Token Lifetime Configuration Record

A node that has a token lifetime configuration always generates a pair of lifetime configuration records—one for the regular token and one for the extended token. The trusted node configuration depends on the token lifetime configuration. You can add a pair of new token lifetime configuration records for an existing node.

This section discusses how to:

  • Add a token lifetime configuration record.

  • Delete a token lifetime configuration record.

11.4.1 Adding a Token Lifetime Configuration Record

Access the SSO Environment Configuration Tools form. In JD Edwards Solution Explorer, select System Administration Tools (GH9011), User Management, User Management Advanced and Technical Operations, and then double-click SSO Environment Configuration Tools.

  1. Click the Single Signon Token Lifetime Configuration link.

  2. On the Work With Token Lifetime Configuration form, click Add.

  3. On the Token Lifetime Configuration Revision form, complete these fields:

    • Regular Token Lifetime

      Specify the expiration time for a regular token. The default value for a node is 720 minutes (12 hours).

    • Extended Token Lifetime

      Specify the expiration time for an extended token. The default value is 4320 minutes (three days). However, the recommended value for this setting is 43,200 minutes (30 days).

11.4.2 Deleting a Token Lifetime Configuration Record

Access the Work With Token Lifetime Configuration form.

Note:

If one token lifetime configuration record is deleted, then another token lifetime configuration for the same node and the trusted node configurations that have this node in it will be deleted as well.

On the Work With Token Lifetime Configuration form, select a node and then click the Delete button.

Note:

A dialog box appears warning you that if you delete this record, the system will delete the extended and regular token lifetime configuration records and the trusted node configuration records of this node.

11.5 Setting Up a Trusted Node Configuration

This section discusses how to:

  • Add a trusted node configuration.

  • Delete a trusted node configuration.

11.5.1 Adding a Trusted Node Configuration

The nodes that you add to a new trusted node configuration must already be defined and have token lifetime configuration records.

Access the SSO Environment Configuration Tools form. In JD Edwards Solution Explorer, select System Administration Tools (GH9011), User Management, User Management Advanced and Technical Operations, and then double-click SSO Environment Configuration Tools.

  1. Click the Single Signon Trusted Node Configuration link.

  2. On the Work With Trusted Node Configuration form, click Find, select a record, and then click Add.

  3. On the Trusted Node Configuration Revision form, enter a node in the Node Name field and then click OK.

11.5.2 Deleting a Trusted Node Configuration

Access the Work With Trusted Node Configuration form.

Select a record and then click Delete.

11.6 Configuring Single Sign-On for a Pre-EnterpriseOne 8.11 Release

EnterpriseOne stores single sign-on node configuration information in new tables (F986180, F986181 and F986182). These tables are not available in pre-8.11 releases (such as release 8.94). However, you can still configure single sign-on for the pre-release through single sign-on node settings in the jde.ini file.

This section discusses how to:

  • Modify jde.ini file node settings for single sign-on.

  • Work with sample jde.ini node settings for single sign-on.

11.6.1 Modifying jde.ini file Node Settings for Single Sign-On

EnterpriseOne comes with standard default settings for single sign-on. If you do not want to accept the default settings, you can overwrite the default single sign-on node settings by configuring the jde.ini file.

See Understanding the Default Settings for the Single Sign-On Node Configuration.

Access the jde.ini file to modify the single sign-on node settings.

In the [TRUSTED NODE] section of the jde.ini file, add the appropriate values to these settings:

Setting Description
numTrustedNodes Enter the number of trusted nodes.
RegularLifeTime Enter the expiration time (in minutes) for a regular token.
ExtendedLifeTime Enter the expiration time (in minutes) for an extended token.
NodeName Enter the logical name for the first node.
MachineName Enter the number of trusted nodes.
NodePassword Enter the password for the first node.
NodeName1 Enter the logical name for the second node.
MachineName1 Enter the physical machine name for the second node.
NodePassword1 Enter the password for the second node.

11.6.2 Working with Sample jde.ini Node Settings for Single Sign-On

This section contains examples of node settings in the jde.ini file for single sign-on configurations:

11.6.2.1 Example 1:

A system administrator wants to install the EnterpriseOne system on three machines: SUN1, IBM1 and HP1. He wants all three machines to trust each other, and no other machines will be trusted. In this case, the administrator can configure the jde.ini as follows and deploy it on SUN1, IBM1, and HP1:

[TRUSTED NODE]
numTrustedNodes=3

For Sun:

NodeName=NodeSUN1
MachineName=SUN1
NodePassword=NodePwd

For IBM:

NodeName1=NodeIBM1
MachineName1=IBM1
NodePassword1=IBM1Pwd

For HP:

NodeName2=NodeHP1
MachineName2=HP1
NodePassword2=HP1Pwd

11.6.2.2 Example 2:

A system administrator wants all EnterpriseOne servers in the network to trust each other. Moreover, he wants to change the default node configuration as follows:

  • Change the node password to NewPwd.

  • Change the regular token lifetime to 30 minutes instead of 12 hours.

  • Change the extended token lifetime to 60 minutes instead of 30 days.

In this case, the administrator can configure the jde.ini as follows and deploy it to all the enterprise servers in the network:

[TRUSTED NODE]
numTrustedNodes=1
RegularLifeTime=30
ExtendedLifeTime=60
NodeName=_GLOBALNODE (The node name must be _GLOBALNODE)
MachineName=_GLOBALNODE (The machine name must be _GLOBALNODE)
NodePassword=NewPwd

11.7 Configuring Single Sign-On Without a Security Server

When there is no security kernel available in the system, a user can directly sign in to the EnterpriseOne Windows client without using the security server. To sign in to EnterpriseOne without a security server, you must:

  • Set SecurityServer=<blank> in the [SECURITY] section of the client jde.ini file.

  • Sign on to EnterpriseOne using the system (database) user ID and password.

In this case, the EnterpriseOne Windows client generates an authenticate token locally. This token is referred to as a local token. A local token is very similar to a regular token except that it has a fixed node name (_LOCALNODE) and contains the system user name and password. A local token can only be accepted by a local fat client or an enterprise server without a security server, for example SecurityServer=<blank> in the server jde.ini.

Note:

If you sign in to EnterpriseOne without a security server, you can only run the business functions and UBEs that are mapped to either the local machine or the enterprise server without a security server.

When a local token is used, the default value for regular token lifetime is 12 hours and the default value for extended token lifetime is 30 days. You can override these default values for the local token using the SSO Environment Configuration Tools application or by modifying the appropriate settings in the jde.ini file of the Windows client, deployment server, and enterprise server.

These are sample jde.ini node settings to override _LOCALNODE for the local token:

[TRUSTED NODE]
numTrustedNodes=1
RegularLifeTime=4320
ExtendedLifeTime=43200
NodeName=_LOCALNODE
MachineName=_LOCALNODE

Note:

You cannot override the node password for _LOCALNODE in the jde.ini file; you must use the SSO Environment Configuration Tools application to do this.