13 Setting Up JD Edwards EnterpriseOne Single Sign-On

This chapter contains the following topics:

Section 13.1, "Understanding the Default Settings for the Single Sign-On Node Configuration"
Section 13.2, "Setting Up a Node Configuration"
Section 13.3, "Setting Up a Token Lifetime Configuration Record"
Section 13.4, "Setting Up a Trusted Node Configuration"
Section 13.5, "Configuring Single Sign-On for a Pre-EnterpriseOne 8.11 Release"
Section 13.6, "Configuring Single Sign-On Without a Security Server"
Section 13.7, "Configuring Single Sign-On for JD Edwards Collaborative Portal"
Section 13.8, "Configuring Single Sign-On for Portlets"
Section 13.9, "Configuring Single Sign-On Between PeopleSoft Enterprise Portal and JD Edwards EnterpriseOne"

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

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

13.2.1 Understanding Single Sign-On Configurations and Their Relationships

In JD Edwards 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 13-1 Single sign-on table relationships

Description of "Figure 13-1 Single sign-on table relationships"

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

Set up node information.
Set up node lifetime.
Establish the trust between nodes.

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

Delete the trusted node relationship.
Delete the node lifetime.
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.

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

Click the Single Signon Node Configuration link.
On the Work With Node Configuration form, click Add.
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.

13.2.3 Revising a Node Configuration

Access the Work With Node Configuration form.

Select a node and then click Select.
On SSO Node Configuration Revision, modify the appropriate fields.

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

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

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.
Click OK to delete the node configuration.

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

13.3.1 Adding a Token Lifetime Configuration Record

Click the Single Signon Token Lifetime Configuration link.
On the Work With Token Lifetime Configuration form, click Add.
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).

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

13.4 Setting Up a Trusted Node Configuration

This section discusses how to:

Add a trusted node configuration.
Delete a trusted node configuration.

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

Click the Single Signon Trusted Node Configuration link.
On the Work With Trusted Node Configuration form, click Find, select a record, and then click Add.
On the Trusted Node Configuration Revision form, enter a node in the Node Name field and then click OK.

13.4.2 Deleting a Trusted Node Configuration

Access the Work With Trusted Node Configuration form.

Select a record and then click Delete.

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

JD Edwards 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.

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

JD Edwards 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.

13.5.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:

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

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

13.6 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 JD Edwards EnterpriseOne Windows client without using the security server. To sign in to JD Edwards 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 JD Edwards 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.

13.7 Configuring Single Sign-On for JD Edwards Collaborative Portal

The JD Edwards Collaborative Portal now uses token-based authentication for single sign-on between the JD Edwards Collaborative Portal and the JD Edwards EnterpriseOne HTML Web Server or EnterpriseOne enterprise server.

Portlets that access information on JD Edwards EnterpriseOne server generate a token based on the user ID, and send the token to the JD Edwards EnterpriseOne server. The server validates the token and enables the user to sign in. The requested information is returned to the portlet.

The token-based system requires that the JD Edwards Collaborative Portal user ID and the JD Edwards EnterpriseOne user ID are the same or that a mapping be set up for the user IDs on the JD Edwards EnterpriseOne server.

Note:

If JD Edwards EnterpriseOne and JD Edwards Collaborative Portal are sharing an LDAP instance, this is not an issue. Since JD Edwards EnterpriseOne only accepts uppercase user IDs in its database, JD Edwards Collaborative Portal will also require uppercase user IDs for the generated token to be validated.

13.8 Configuring Single Sign-On for Portlets

This section provides information on how to modify the TokenGen.ini file settings for single sign-on and contains single sign-on configuration information for these portlets:

EnterpriseOne Portlet (JSR168)
Collaborative Portal EnterpriseOne Menu
Hosted EnterpriseOne Portlet
CSS, ESS, SSS
EnterpriseOne Links
CRM

13.8.1 Modifying TokenGen.ini File Settings

Single sign-on requires that you change the TokenGen.ini settings for Node Name and Node Password to correspond to the entries in the JD Edwards EnterpriseOne security server. The values shown in the [NODE MANAGER] section are for a default install:

[NODE MANAGER]
NodeName=_GLOBALNODE
NodePwd=_GLOBALPWD

To modify these settings after the install, locate the TokenGen.ini file in this directory:

<WebSphere home>/properties

13.8.2 EnterpriseOne Portlet (JSR168)

With the EnterpriseOne portlet, the JAS server runs as part of the portlet rather than being connected to remotely. This also means that the EnterpriseOne portlet uses the jas.ini and jdbj.ini files that were installed as part of the JD Edwards Collaborative Portal install.

The user IDs must be synchronized between the JD Edwards Collaborative Portal and the JD Edwards EnterpriseOne user database. If the default environment and role are set in the OWWEB section of the jas.ini, these entries will be used for all users. If no default entries are set, the user will be asked to choose from a list of environments and roles when they go to a page with the JD Edwards EnterpriseOne portlet on it.

When multiple JD Edwards EnterpriseOne portlets are placed on a page, only one of the portlets displays the environment and role list. The other portlets display the warning message, "This portlet is waiting for authentication to be completed."

13.8.3 Collaborative Portal EnterpriseOne Menu

Before release 8.11, EnterpriseOne Menu (then called Task Explorer) used inherited trust for single sign-on. As of 8.11, the portlet uses the authenticate token. The environment and role are configured through the configuration screen of the portlet by the administrator. Alternatively, the default environment and role can be set in the jas.ini of the remote JAS server.

13.8.4 Hosted EnterpriseOne Portlet

Before release 8.11, the Hosted EnterpriseOne Portlet used inherited trust for single sign-on. As of release 8.11, the portlet uses the authenticate token. Environment and role are configured through the edit screen by each user. Alternatively, the administrator can set the default environment and role in the jas.ini of the remote EnterpriseOne JAS server.

13.8.5 CSS, ESS, SSS

Before release 8.11, these portlets used inherited trust for single sign-on. As of release 8.11, these portlets use the authenticate token. The environment and role are set through the portlet configuration screen by the administrator.

13.8.6 EnterpriseOne Links

Before release 8.11, EnterpriseOne Links used inherited trust for single sign-on. As of release 8.11, this portlet uses the authenticate token. The environment and role are still set through the portlet configuration screen by the administrator.

13.8.7 CRM

The CRM portlets, based on the Youcentric technology, continue to use the inherited trust system for single sign-on. CRM portlets included in the 8.11 JD Edwards EnterpriseOne solution are included in the EnterpriseOne portlet.

13.9 Configuring Single Sign-On Between PeopleSoft Enterprise Portal and JD Edwards EnterpriseOne

This section provides an overview of setting up single sign-on between PeopleSoft Enterprise Portal and JD Edwards EnterpriseOne and discusses how to:

Manage user ID mapping in JD Edwards EnterpriseOne.
Manage user ID mapping when using LDAP.
Synchronize user mapping between LDAP and JD Edwards EnterpriseOne while using LDAP authentication.
View user ID mapping when using LDAP.

13.9.1 Understanding Single Sign-On Between PeopleSoft Enterprise Portal and JD Edwards EnterpriseOne

Prior to JD Edwards EnterpriseOne release 8.11, single sign-on between PeopleSoft Enterprise Portal and JD Edwards EnterpriseOne was accomplished as follows:

PeopleSoft Enterprise Portal generated a token and sent it to JD Edwards EnterpriseOne.
JD Edwards EnterpriseOne called back to the PeopleSoft Enterprise Portal application server to validate token and received back a user ID.
The system used the user ID to sign on to JD Edwards EnterpriseOne.

Since JD Edwards EnterpriseOne can validate and sign on with a token generated by the PeopleSoft Enterprise Portal, it is no longer necessary to call back to the PeopleSoft Enterprise Portal side to validate the token. This simplification of the single sign-on setup between PeopleSoft Enterprise Portal and JD Edwards EnterpriseOne means that the following items are no longer required:

The psjoa.jar, psft.jar, and PeopleSoft.Generated.CompIntfc.jar files in the JD Edwards EnterpriseOne system. The latest JD Edwards Collaborative Portal installer does not install these files.
The PeopleSoftAppServer, PeopleSoftAppServerUser, and PeopleSoftAppServerPassword jas.ini entries in the OWWEB section.
The DBUser and DBPassword entries in the jas.ini are no longer required in the SECURITY section.
The setup of the component interface (PRTL_SS_CI) on the PeopleSoft Enterprise Portal. Additionally, the admin user for accessing this interface no longer needs to be set up.
The entry in the PSTRUSTNODES table on the PeopleSoft Enterprise Portal for the local node.

Note:

The environment and role entries are still set up the same as in previous releases, as defaults in the jas.ini on the JD Edwards EnterpriseOne HTML Web Server.

See JD Edwards EnterpriseOne Tools 8.98 HTML Web Server Reference Guide.

13.9.1.1 Time Zone Adjustment for PeopleSoft Enterprise Portal

When setting up single sign-on between PeopleSoft Enterprise Portal and JD Edwards EnterpriseOne, you must properly configure the ENTERPRISE TIMEZONE ADJUSTMENT setting in the JD Edwards EnterpriseOne enterprise server jde.ini file. This setting enables you to enter the difference in time between Greenwich Mean Time (GMT) and PeopleSoft Enterprise Portal Node time. You should change this setting whenever daylight saving time changes to reflect the difference between GMT time and the PeopleSoft Enterprise Portal Node time.

In this example of the ENTERPRISE TIMEZONE ADJUSTMENT setting, the difference between the GMT and PeopleSoft Enterprise Portal Node time is entered in minutes for a PeopleSoft Enterprise Portal that is running in Mountain Standard Time (MST):

[ENTERPRISE TIMEZONE ADJUSTMENT]
EntNode=-360

13.9.1.2 User ID Mapping for Single Sign-On

Since PeopleSoft Enterprise and JD Edwards EnterpriseOne systems have different user IDs, you must map the user IDs between the two systems in order for single sign-on to work. If you manage user IDs in a JD Edwards EnterpriseOne database, then you can use a JD Edwards EnterpriseOne application to map users. If you use LDAP to manage user information such as user IDs, passwords, and role relationships, then you must use the third-party LDAP tool to set up user ID mapping.

13.9.2 Managing User ID Mapping in JD Edwards EnterpriseOne

Access the SSO Environment Configuration Tools form. In JD Edwards Solution Explorer, select System Administration Tools (GH9011), Security Maintenance, Security Maintenance Advanced and Technical Operations, SSO Environment Configuration Tools.

Click the Configure the UserID Mapping link.
On the Work with SSO E/E1 UserID Mapping form, use the Add, Select, and Delete buttons to manage user ID mappings.
To add a user ID mapping, click Add.
On the SSO E/E1 userID Mapping Revisions form, complete the EnterpriseOne UserID and Enterprise UserID fields.

The system saves the record in the F00927 table.

Note:

If the JD Edwards EnterpriseOne user ID is not in the F0092 table, the system generates an error stating that it cannot add the mapping record.

13.9.3 Managing User ID Mapping when Using LDAP

JD Edwards EnterpriseOne can use LDAP (Lightweight Data Access Protocol) to manage user IDs, password, and role relationships. If the JD Edwards EnterpriseOne system is LDAP-enabled, this setting must be added to the jde.ini file:

[SECURITY]
LDAPAuthentication=true

13.9.4 Synchronizing User Mappings Between LDAP and JD Edwards EnterpriseOne While Using LDAP Authentication

JD Edwards EnterpriseOne provides an optional batch application, Synchronize the LDAP and EnterpriseOne Database (R9200040), that you can run to synchronize all of the user mappings between the LDAP and JD Edwards EnterpriseOne databases. The user mapping synchronization also occurs when a user signs in to JD Edwards EnterpriseOne. However, the synchronization only applies to the user who just signed in. Therefore, you should run R9200040 to:

Synchronize all users.
Purge obsolete users (such as the users that have already been removed from LDAP) from the database.

Note:

You should be extremely cautious when running this batch application since it not only synchronizes user mappings, but also synchronizes other user profile settings such as user-role relationships. Moreover, it will delete all the users that do not exist in LDAP.

To synchronize all user mappings between the LDAP and JD Edwards EnterpriseOne databases, run the R9200040 batch application:

This is an example of the results of running the R9200040 batch application:

Figure 13-2 R9200040 output

Description of "Figure 13-2 R9200040 output"

13.9.5 Viewing User ID Mapping When Using LDAP

When using LDAP to manage user sign-on information, you can still view the user ID mappings for single sign-on through JD Edwards EnterpriseOne.

Access the SSO Environment Configuration Tools form. In JD Edwards Solution Explorer, select System Administration Tools (GH9011), Security Maintenance, SSO Environment Configuration Tools.

On the SSO Environment Configuration Tools form, click the View UserID Mapping option.
On the Work with SSO E/E1 UserID Mapping form, select a mapping record and then click the Select button to view the mapping.