15 Setting Up JD Edwards EnterpriseOne Single Sign-On

This chapter contains the following topics:

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

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


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

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

This image is described in surrounding text.

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.

15.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 15-2 Single Sign-on between JD Edwards Collaborative Portal and EnterpriseOne applications

This image is described in surrounding text.
  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.

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

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

15.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 15-3 Single sign-on table relationships

Description of Figure 15-3 follows
Description of ''Figure 15-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.

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

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

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

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

15.4 Configuring EnterpriseOne HTML Server for JSON Web Token (JWT) (Release 9.2.3.2)

This section discusses how to:

  • Understand JSON Web Token Authentication.

  • Configure EnterpriseOne Server Trust of the HTML Server.

  • Add an existing certificate to a new keystore.

  • Configure HTML Server with a certificate.

15.4.1 Understanding JSON Web Token Authentication

To provide single sign on access using JD Edwards EnterpriseOne and any JWT producing authority, including Oracle Mobile Cloud Service, you need to configure the EnterpriseOne Server trust of the HTML Server, add an existing certificate to a new keystore, and then configure the HTML Server with a certificate. These configurations allow you to establish a trust relationship between a token provider (such as Mobile Cloud Service) and an EnterpriseOne AIS Server and HTML Server.

JWT Authentication Flow

For authentication with a JWT, the following must take place:

  • The public key certificate used for token generation by the third party must be provided.

  • You must store this certificate in a secure PKCS12 keystore (.p12) and upload it to the EnterpriseOne HTML Server.

  • You must configure the EnterpriseOne HTML Server with the keystore name, keystore password, and certificate alias.

  • Principal passed in the JWT must match the EnterpriseOne user ID.

  • You must configure the EnterpriseOne HTML Server as a trusted node through a single sign-on trust configuration.

Figure 15-6 shows the authentication flow in an environment in which JWT is used for authentication.

Figure 15-4 JWT Authentication Flow

This image is described in surrounding text.

The following steps describe the authentication flow:

  1. A JWT is generated with the private key and sent in the Bearer header of an AIS token request. (Stateless requests are also supported).

  2. The JWT is forwarded to the EnterpriseOne HTML Server by the AIS Server in the Bearer if login is required, and the AIS Server is configured to allow a JWT.

  3. The JWT is validated against the public key, the token timeout is validated, and the principal (user) is extracted from the JWT payload. A PS Token is generated for that user and sent for authorization by the Security Server (EnterpriseOne Enterprise Server).

  4. The Security Server checks the PS token with SSO node trust, and then an authorization response is returned to the EnterpriseOne HTML Server.

  5. The authorization response is returned to the AIS Server. The PS Token is included in the response.

  6. The authorization response is returned to the AIS client (third-party). If passed, for a token request the response includes an AIS token.

JWT Internal Flow

For authentication with a JWT, the following must take place:

  • You must configure the private key certificate that is used for token generation on the AIS Server. It is initially configured with the Demo Certificate.

  • You must configure the public key certificate used for token validation on the HTML Server.

  • You must store the certificate in a secure PKCS 12 keystore (.p12) and upload it to the HTML Server.

  • You must configure the EnterpriseOne HTML Server as a trusted node through the single sign-on trust configuration.

Figure 15-5 shows the internal authentication flow in an environment in which JWT is used for authentication.

Figure 15-5 JWT Internal Authentication Flow

Surrounding text describes Figure 15-5 .

The following steps describe the internal authentication flow:

  1. A JWT is generated for each subscriber (with the subscriber user ID) and is passed to the JTML Server to establish a session.

  2. The JWT is validated against the public key, the token timeout is validated, and the principal (user) is extracted from the JWT payload. A PS Token is generated for that user and sent for authorization by the Security Server (EnterpriseOne Enterprise Server).

  3. The Security Server checks the PS token with SSO node trust, and then an authorization response is returned to the EnterpriseOne HTML Server.

  4. The authorization response is returned to the AIS Server. The PS Token is included in the response.

  5. The AIS Server uses that subscriber's session to execute the defined notification and then logs out.

15.4.2 Configuring EnterpriseOne Server Trust of the HTML Server

You need to configure the EnterpriseOne Server Trust of the HTML Server before you configure the HTML Server with a certificate.

Access the Work With Node Configuration form.

  1. Ensure that a Trusted Node configuration is already created.

    See Setting Up a Node Configuration.

  2. Use the Security section of the Server Manager configuration to enter the exact Node Name and Node Password configured for the HTML Server.

    Notice that the Node Password is hidden because the environment is configured with a site key that encrypts all passwords in the configuration files. You can use either configuration, with or without site key.

  3. Bounce the EnterpriseOne Server and then the HTML Server.

15.4.3 Adding an Existing Certificate to a New Keystore

Use the Java keytool utility to create a keystore to securely encapsulate the certificate.

  1. Locate the keytool inside the JDK bin directory.

  2. Make sure the certificate file (.cer) is located on the same machine as the JDK.

  3. Execute the keytool command as follows, substituting values for alias, file, and keystore.

    keytool -import -alias <your-alias> -file <your-cer-file> -keystore <your-keystore-name>
    

    e.g.

    keytool -import -alias abcdomain -file "/usr/certs/mycert.cer " -keystore "/usr/certs/mykeystore.p12"
    
  4. Enter a password for the keystore, make sure to remember this password as it will be used in configuring the HTML Server in Server Manager.

  5. You will be prompted to trust the certificate, type Yes and then click Enter.

  6. The system stores the keystore in the location you indicated with the .p12 extension.

  7. To verify that the certificate is in the keystore, use the following keytool utility command. Enter the password when prompted. The system lists the certs in the store.

    keytool -list -v -keystore ""/usr/certs/mykeystore.p12"
    

15.4.4 Configuring HTML Server with a Certificate

There are two separate configuration sections in Server Manager to allow for all certificates in each store to be trusted. Each section allows for one keystore; multiple certificates can be imported into that keystore.

The external section is for configuring certificates for a JWT token generated outside of the JD Edwards system.

The internal section is for configuring certificates for JWT tokens generated by AIS Servers, for communication between the AIS and HTML Servers (for example, notifications and scheduler). By default, the demo certificate is enabled. The demo certificate is always allowed. If you have enabled the demo certificate and included certificates in a keystore, all of them can be used. The demo certificate will be tried first if it is enabled.

Note:

Any certificates that you include in the internal keystore much match the certificates configured for each AIS Server associating with the HTML Server (public/private key pair).

Before you start configuring the HTML Server with a certificate, you need to upload the .p12 file to the machine where the HTML Server is deployed.

Access the Server Manager Configuration form.

  1. Select the Security configuration for the HTML Server.

  2. For the External OAuth JWT Trust Configuration for Authentication, enter the keystore location details, and the password of the keystore.

  3. For the AIS Internal JWT Trust Configuration for Authentication, enter the keystore location details, password of the keystore, and select whether to use the demo certificate.

  4. Apply the change, synchronize, and bounce the HTML Server.

  5. Make sure the site key is enabled, so the password is encrypted and hidden after the sync/bounce.

15.5 Configuring EnterpriseOne HTML Server for JSON Web Token (JWT) (Release 9.2.0.5)

This section discusses how to:

  • Understand JSON Web Token Authentication.

  • Configure EnterpriseOne Server Trust of the HTML Server.

  • Add an existing certificate to a new keystore.

  • Configure HTML Server with a certificate.

15.5.1 Understanding JSON Web Token Authentication

To provide single sign on access using JD Edwards EnterpriseOne and any JWT producing authority, including Oracle Mobile Cloud Service, you need to configure the EnterpriseOne Server trust of the HTML Server, add an existing certificate to a new keystore, and then configure the HTML Server with a certificate. These configurations allow you to establish a trust relationship between a token provider (such as Mobile Cloud Service) and an EnterpriseOne AIS Server and HTML Server.

For authentication with a JWT, the following must take place:

  • The public key certificate used for token generation by the third party must be provided.

  • You must store this certificate in a secure Java keystore (.jks) and upload it to the EnterpriseOne HTML Server.

  • You must configure the EnterpriseOne HTML Server with the keystore name, keystore password, and certificate alias.

  • Principal passed in the JWT must match the EnterpriseOne user ID.

  • You must configure the EnterpriseOne HTML Server as a trusted node through a single sign-on trust configuration.

Figure 15-6 shows the authentication flow in an environment in which JWT is used for authentication.

Figure 15-6 JWT Authentication Flow

This image is described in surrounding text.

The following steps describe the authentication flow:

  1. A JWT is generated with the private key and sent in the Bearer header of an AIS token request. (Stateless requests are also supported).

  2. The JWT is forwarded to the EnterpriseOne HTML Server by the AIS Server in the Bearer if login is required, and the AIS Server is configured to allow a JWT.

  3. The JWT is validated against the public key, the token timeout is validated, and the principal (user) is extracted from the JWT payload. A PS Token is generated for that user and sent for authorization by the Security Server (EnterpriseOne Enterprise Server).

  4. The Security Server checks the PS token with SSO node trust, and then an authorization response is returned to the EnterpriseOne HTML Server.

  5. The authorization response is returned to the AIS Server. The PS Token is included in the response.

  6. The authorization response is returned to the AIS client (third-party). If passed, for a token request the response includes an AIS token.

15.5.2 Configuring EnterpriseOne Server Trust of the HTML Server

You need to configure the EnterpriseOne Server Trust of the HTML Server before you configure the HTML Server with a certificate.

Access the Work With Node Configuration form.

  1. Ensure that a Trusted Node configuration is already created.

    See Setting Up a Node Configuration.

  2. Use the Security section of the Server Manager configuration to enter the exact Node Name and Node Password configured for the HTML Server.

    Notice that the Node Password is hidden because the environment is configured with a site key that encrypts all passwords in the configuration files. You can use either configuration, with or without site key.

  3. Bounce the EnterpriseOne Server and then the HTML Server.

15.5.3 Adding an Existing Certificate to a New Keystore

Use the Java keytool utility to create a keystore to securely encapsulate the certificate.

  1. Locate the keytool inside the JDK bin directory.

  2. Make sure the certificate file (.cer) is located on the same machine as the JDK.

  3. Execute the keytool command as follows, substituting values for alias, file, and keystore.

    keytool -import -alias <your-alias> -file <your-cer-file> -keystore <your-keystore-name>
    

    e.g.

    keytool -import -alias abcdomain -file "/usr/certs/mycert.cer " -keystore "/usr/certs/mykeystore.jks"
    
  4. Enter a password for the keystore, make sure to remember this password as it will be used in configuring the HTML Server in Server Manager.

  5. You will be prompted to trust the certificate, type Yes and then click Enter.

  6. The system stores the keystore in the location you indicated with the .jks extension.

  7. To verify that the certificate is in the keystore, use the following keytool utility command. Enter the password when prompted. The system lists the certs in the store.

    keytool -list -v -keystore ""/usr/certs/mykeystore.jks"
    

15.5.4 Configuring HTML Server with a Certificate

Before you start configuring the HTML Server with a certificate, you need to upload the .jks file to the machine where the HTML Server is deployed.

Access the Server Manager Configuration form.

  1. Select the Security configuration for the HTML Server and enter the certificate location details, the password of the keystore, and the alias of the certificate.

  2. Apply the change, synchronize, and bounce the HTML Server.

  3. Make sure the site key is enabled, so the password is encrypted and hidden after the sync/bounce.

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

15.6.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).

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

15.7 Setting Up a Trusted Node Configuration

This section discusses how to:

  • Add a trusted node configuration.

  • Delete a trusted node configuration.

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

15.7.2 Deleting a Trusted Node Configuration

Access the Work With Trusted Node Configuration form.

Select a record and then click Delete.

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

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

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

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

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

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