4 Employing Sign-in Security
This chapter contains the following topic:
4.1 Understanding Sign-in Security
This section discusses:
-
Sign-in security overview.
-
Security table access.
-
Password encryption.
-
Sign-in security setup.
-
Process flow for sign-in security.
-
Sign-in security for web users.
4.1.1 Sign-In Security Overview
JD Edwards EnterpriseOne security runs on a logic server in a dedicated internal process. You create a security table on the data server that stores information, such as:
| Value | Description |
|---|---|
| EnterpriseOne User | The user ID used to sign in to JD Edwards EnterpriseOne. |
| EnterpriseOne Password | The user's password, which the software validates when the user signs in to JD Edwards EnterpriseOne. |
| System User and System Password | The actual user and password used to connect to all database management systems (DBMS). If the JD Edwards EnterpriseOne environment includes more than one DBMS, you can create different system users and passwords for each data source. |
| Change Frequency | The frequency of password changes required by the software. |
| Last Change | The date that the password was last changed. |
You must define a security record for each user either by group or by individual. It is recommended that you map multiple users to the same system user. For example, each user can use the same system user that the software uses to connect the database management systems. By setting up the security in this manner, you can simplify database administration of users and passwords.
You can also set up unified logon with JD Edwards EnterpriseOne to simplify sign-in security. When you set up unified logon, JD Edwards EnterpriseOne uses Windows Authentication to verify security. This verification enables sign-in security to use the network logon information that a user supplies when logging on to Windows; JD Edwards EnterpriseOne does not require the user to enter another user ID and password when signing in.
4.1.2 Security Table Access
If you keep the system user and password secure, no users have direct access to the Security table (F98OWSEC). The exception to this situation is for system administrators who maintain the security information. The JD Edwards EnterpriseOne security server has access to the F980WSEC table through JDENet.
You must perform all of the validation and changes of JD Edwards EnterpriseOne passwords through a JDENet message to the enterprise server that has the F980WSEC table. Upon validating a JD Edwards EnterpriseOne password, the JDENet message returns the system user and password that you enter. These words are encrypted across the network. Internally, this system password is used for all connections to databases.
Using the database management system, you should place database security on the F980WSEC table. You should also assign JD Edwards EnterpriseOne object security to the F980WSEC table so that users cannot access the object except to enter User Password Revisions.
See Also:
4.1.3 Password Encryption
You can enter the initial sign-in password for each user in these ways:
-
Type it manually.
-
Use a default password established through the sign-in security processing options.
-
Have JD Edwards EnterpriseOne enter it automatically because the user has an existing security record.
When typing a password manually or when using the processing option default password, you cannot see the password for a new user because you are typing it in. When you revise this record, however, the system encrypts the password so that all you see are asterisks. The number of asterisks does not represent the number of characters in the password. The user security application does not know what the password is. The application is given a flag that indicates that a password was entered. The system stores the actual password on the security server within a binary object in the F980WSEC table. The system accesses the binary object when the user security application requests a change or inquiry.
4.1.4 Sign-In Security Setup
This checklist is an overview of the steps that are required to set up sign-in security:
| Sign-in Security Setup Step | Description |
|---|---|
| Determine location of the F98OWSEC table. | Ensure that the F98OWSEC table is located in the system data source on the enterprise server, and ensure that the table is mapped to the correct data source through the Object Configuration Manager.
If your system data source resides on the enterprise server, the F980WSEC table should reside in the system data source. However, if the system data source is located on the deployment server (or other servers), the F980WSEC table should be moved to the server map data source for the enterprise server. If you have more than one logic server, you should use only one as the security server. |
| Set database security on the F98OWSEC table. | From within the DBMS, place database security on this table to prevent a user from accessing the object, except to enter passwords through User Password Revisions. |
| Place security on the logic server's jde.ini file. | The DBMS user ID and password to the Sign On Security table are stored in this file.
Caution: Implementing jde.ini file security will prevent Server Manager from modifying configuration settings. |
| Create security records for individual users. | Assign these:
|
| Verify and modify the jde.ini file on the JD Edwards EnterpriseOne logic server for the platform environment. | If you use a unified logon, you need to change the settings for a unified logon in the [SECURITY] section as well as in the JD Edwards EnterpriseOne [SECURITY] settings. |
| Set up a unified logon server. | If you use a unified logon with the JD Edwards EnterpriseOne security, set up a unified logon server for each instance of JD Edwards EnterpriseOne on each server. For example, if you have an NT server with multiple releases of JD Edwards EnterpriseOne, you need a unified logon server for each release on the server.
The unified logon server differentiates instances of JD Edwards EnterpriseOne based on the port numbers for these instances. For example, if the port number for JD Edwards EnterpriseOne is 6104, the port number for the associated unified logon server is 6104. Other instances and unified logon servers use different port numbers. |
| Verify and modify jde.ini file. | Verify and modify the jde.ini file that will be deployed to the server's workstation installations. |
| Set up sign-in security. | Require sign-in security for all machines. |
4.1.5 Process Flow for Sign-in Security
JD Edwards EnterpriseOne provides sign-in security with an architecture that is designed to provide user security for JD Edwards EnterpriseOne and the logically attached database management systems. The security architecture prevents you from viewing the database or system password and from bypassing JD Edwards EnterpriseOne applications to view and change data.
This text explains the process flow for standard sign-in security:
-
Workstations sign in to JD Edwards EnterpriseOne by using their user ID and password.
These workstations can be networked or standalone workstations, laptop computers, or other JD Edwards EnterpriseOne hosts.
If you enter a valid user ID and password, as validated against the local workstation installation, the start-up process continues.
-
As the software starts, it tries to detect an operational network environment.
If a network is not detected, the software allows local operation in a store-and-forward mode. Because the workstation or laptop computer is not connected to a network or an enterprise server, no validation can be performed against the F980WSEC table. Therefore, security is limited to that provided by the local workstation or laptop installation.
If a network is detected, the software encrypts the password information and sends it over the network to the JD Edwards EnterpriseOne enterprise server.
The enterprise server checks the incoming validation request against a table of valid users and passwords. If the user ID and password information are valid, the software accepts the sign-in values and returns the system ID and password to the logically attached database servers. This information is also encrypted on the enterprise server prior to broadcast on the network.
This graphic displays a process flow model for standard sign-in security:
Figure 4-1 Process flow model for standard JD Edwards EnterpriseOne sign-in security
Description of "Figure 4-1 Process flow model for standard JD Edwards EnterpriseOne sign-in security"
The process flow for sign-in security with a unified logon is as follows:
-
A user starts up JD Edwards EnterpriseOne on a workstation.
-
JD Edwards EnterpriseOne verifies that the unified logon is active and then sends an authentication request to the unified logon server, based on the domain user ID.
Note:
The unified logon server is not a physical server. It is a device that verifies sign-in security against the domain sign-in security maintained by Microsoft Windows.During jdesnet initialization, jdesnet activates the unified logon server thread. The unified logon server ends automatically when jdesnet ends.
-
The unified logon server searches its user list for an entry that matches the domain user ID. When the server finds a match, the server sends a validation request to the enterprise server.
-
The enterprise server verifies that the response from the unified logon server matches the security information in the F980WSEC table.
-
If the security information from the user list on the unified logon server matches the security information in the F98OWSEC table on the enterprise server, the start-up process continues.
-
The first time that a user signs in to JD Edwards EnterpriseOne with the unified logon, the Environment Selection appears.
The user must enter an environment in the Environment field. Select the option to set the environment as the default, and avoid the Environment Selection form on subsequent sign-in attempts.
This illustration displays the process flow for unified logon:
4.1.5.1 ShowUnifiedLogon Setting
The ShowUnifiedLogon setting in the [SECURITY] section of the jde.ini file allows users to reset whether the Environment Selection form appears at sign-in. This feature allows users to change the environment later. This table describes the jde.ini file setting for the [SECURITY] section:
| Value | Description |
|---|---|
| 0 | A value of 0 for ShowUnifiedLogon disables the Environment Selection form. When you click the option on the Environment Selection form to set a default environment, you set this value to 0. |
| 1 | A value of 1 for ShowUnifiedLogon enables the Environment Selection form. When a user signs in to JD Edwards EnterpriseOne, the Environment Selection form appears and allows the user to choose an environment. This setting is the default for ShowUnifiedLogon. |
4.1.6 Sign-in Security for Web Users
The JD Edwards EnterpriseOne security server and the F98OWSEC table authenticate Java/HTML, Portal, and Interoperability users who sign in to JD Edwards EnterpriseOne across the internet to the JAS security server. The JAS security server acts as an interface between the web user's client workstation and the security server.
When web users sign in, disconnect, or make a password change, the JAS server sends the request using a JDENET message to the security server, which, in turn, accesses the F98OWSEC table. The security server then returns the authentication through a JDENET message to the JAS security server. If the user is authenticated, the security info is cached to the JAS security server.
The JAS security server acts as an intermediary between the Java/HTML, Portal, and Interoperability client and the security server.
This graphic displays a process flow for sign-in security with unified logon for web users:
Figure 4-3 Sign-in security with unified logon for web users
Description of "Figure 4-3 Sign-in security with unified logon for web users"
As the security intermediary, the JAS security server handles these tasks:
-
Connecting to the JD Edwards EnterpriseOne security server for user security authentication and password when a web user signs in.
-
Switching to a secondary JD Edwards EnterpriseOne security server when the primary server is down, provided the correct jas.ini settings are defined.
-
Notifying Java/HTML, Portal, and Interoperability client workstations when a user password has expired.
If an Interoperability user's password has expired, sign-in fails without notification of the cause.
-
Sending error message to user log after the web user has attempted unsuccessfully to sign in x number of times to JD Edwards EnterpriseOne, where x is the number of sign-in attempts defined in the F98OWSEC table.
-
Allowing Java/HTML and Portal users to change name and password.
-
Encrypting JDENET messages sent between the JAS security server and the JD Edwards EnterpriseOne security server.
-
Keeping a valid user session open until the user signs off or the session expires.
To the web user, sign-in and sign-out function the same as they do to a user on Windows, UNIX, or iSeries platforms.
To set up security for web users through the JD Edwards EnterpriseOne security server, add these parameters to those that already exist in the jas.ini file:
| [SECURITY] Parameter in jas.ini File | Parameter Value |
|---|---|
| NumServers | Total number of JD Edwards EnterpriseOne security servers that are available to web users signing on to the system. If this parameter is missing, the default value is 1 and the primary security server handles the sign-in. |
| SecurityServer | Name of the primary security server. |
| SecurityServerN | Name of the secondary security server. The value of N is 1 for the first secondary server, 2 for the second, and so on. Assign values to this parameter if you want sign-in to switch to a secondary server if users cannot sign in to the primary server. |
| UserLogonCookie= | If the value is TRUE, the user can save signon information (username, password, and environment) in an encrypted cookie on the workstation and does not have to type the information in for subsequent sign-ins. If the value is FALSE, the feature is disabled. |
| #CookieLifeTime unit | Unit of time used to measure a cookie's lifetime. For example, the parameter value day means that the cookie's lifetime is measured in days. |
| Cookie LifeTime | Amount of time before a cookie expires. The unit of measure is defined by the #CookieLifeTime unit parameter value. If that value is day and the value of the Cookie LifeTime parameter is 7, the cookie expires in seven days. |
If you define one primary server and two secondary servers, the jas.ini file [SECURITY] settings look like this example:
NumServers=3 SecurityServer=JDED SecurityServer1=JDEC SecurityServer2=corowhp2 UserLogonCookie=TRUE #CookieLifeTime unit is day CookieLifeTime=7
If you define one or more secondary servers, sign-in fails over to the secondary server if the primary server is down. If both the primary JD Edwards EnterpriseOne security server and a secondary server as defined in the jas.ini file fail, the JAS server fails the user sign-in.
If you do not define a server number or any secondary servers, the jas.ini [SECURITY] settings look like this example:
[SECURITY] SecurityServer=JDED UseLogonCookie=TRUE CookieLifeTime unit is day CookieLifeTime=7
4.1.7 Setting Processing Options for P98OWSEC
The User Security program (P98OWSEC) has processing options that you can use to set a default password when creating user security for users or roles, and to set a default change frequency for the password:
4.1.7.1 Default
Although processing options are set up during JD Edwards EnterpriseOne implementation, you can change processing options each time that you run a program.
- 1. Enter a '1' to default the User ID into the password field.
- 2. Enter in the default Change Frequency.
- 3. Enter the number of sign-on attempts a user is given prior to being disabled.
- 4. Enter if a new user is to default to as enabled or disabled.
- 5. Enter a '1' to force immediate password change of new users.
4.1.7.2 Password
Although processing options are set up during JD Edwards EnterpriseOne implementation, you can change processing options each time you run a program.
- 1. Enter the daily password change limit that will be applied to all users when attempting to change a password.
-
If this field is 0 or is left blank, there will be no limit on daily password changes.
- 2. Enter the minimum password length that is to be used when users attempt to change a password.
-
If this field is 0 or is left blank, the password will not be checked for a minimum length.
- 3. Enter the minimum number of character that must be used within a password.
-
If this field is 0 or is left blank, the password will not be checked for characters.
- 4. Enter the minimum number of numerics that must be used within a password.
-
If this field is 0 or is left blank, the password will not be checked for numerics.
- 5. Enter the maximum number of consecutive characters that can be used in a password.
-
If this field is 0 or is left blank, the password will not be checked for consecutive characters.
- 6. Enter the minimum number of special characters that must be within a password.
-
If this field is 0 or is left blank, the password will not be checked for special characters.