This page (revision-39) was last changed on 26-Nov-2021 10:22 by jaiken

This page was created on 26-Nov-2021 10:22 by jmyers

Only authorized users are allowed to rename pages.

Only authorized users are allowed to delete pages.

Page revision history

Version Date Modified Size Author Changes ... Change note
39 26-Nov-2021 10:22 30 KB jaiken to previous
38 26-Nov-2021 10:22 31 KB rforbes to previous | to last
37 26-Nov-2021 10:22 31 KB rforbes to previous | to last
36 26-Nov-2021 10:22 31 KB rmorrell to previous | to last
35 26-Nov-2021 10:22 31 KB rmorrell to previous | to last
34 26-Nov-2021 10:22 31 KB jmyers to previous | to last
33 26-Nov-2021 10:22 31 KB jmyers to previous | to last EMAIL_ADDRESS ==> EMAIL_ADDRESS(Disambiguation)
32 26-Nov-2021 10:22 31 KB jmyers to previous | to last
31 26-Nov-2021 10:22 31 KB jmyers to previous | to last
30 26-Nov-2021 10:22 31 KB jmyers to previous | to last
29 26-Nov-2021 10:22 31 KB jmyers to previous | to last
28 26-Nov-2021 10:22 32 KB jmyers to previous | to last
27 26-Nov-2021 10:22 32 KB jmyers to previous | to last
26 26-Nov-2021 10:22 33 KB jmyers to previous | to last
25 26-Nov-2021 10:22 33 KB jmyers to previous | to last
24 26-Nov-2021 10:22 33 KB jmyers to previous | to last
23 26-Nov-2021 10:22 33 KB jmyers to previous | to last
22 26-Nov-2021 10:22 33 KB jmyers to previous | to last
21 26-Nov-2021 10:22 33 KB jmyers to previous | to last

Page References

Incoming links Outgoing links
USER PASSWORDS
USER PASSWORDS

Version management

Difference between version and

At line 257 changed one line
;[Access Status|ACTIVE_STATUS]:The Access Status field indicates whether the user can access the system during the time period of the chosen date sensitive record. This field is maintained by the system but can also be entered manually.
;[Access Status|ACTIVE_STATUS]:The Access Status field indicates whether the user can access the system during the time period of the chosen date sensitive record. This field is maintained by the system but can also be entered manually. \\ \\Both the Access Start/End Dates and the Access Status are checked before a user is allowed to log in.
;[Failed Attempts| ]:The system shows the number of failed login attempts that the user has had since the last good login during the time period of the chosen date sensitive record.
;[Password Has Been Set| ]:The system indicates via a toggle whether a password exists for the time period of the chosen date sensitive record.
At line 259 removed 12 lines
The allowed values are:
|Active - access is currently allowed (subject to the access start/end dates)
|Disabled - access is currently disabled (must be activated manually)
|Locked Out - user is currently locked out of the system (must be activated manually)
|Pending - user has been created but password has not yet been assigned
Both the Access Start/End Dates and the Access Status are checked before a user is allowed to log in.
Failed Attempts
The system shows the number of failed login attempts that the user has had since the last good login during the time period of the chosen date sensitive record.
Password Has Been Set
The system indicates via a toggle whether a password exists for the time period of the chosen date sensitive record.
At line 272 changed 17 lines
Security administrators establish their own rules for system access by type of user. ePersonality offers many techniques for restricting access:
• Users are authenticated at login time - they must identify who they are and they must supply a confidential password
• Highly secure encryption techniques are used for all passwords, with no ability to de-encrypt
• Complicated password schemes are supported:
- ability to force codes to be a minimum length
- ability to force the use of at least one numeric digit
- ability to force at least one punctuation character
- case sensitive
• Users are notified by email whenever their password is changed, if they have an email address
• The system is able to force password changes after a specified number of days
• The system is able to force a new password to be different from the previous ‘n’ passwords
• An option is provided to lock out users who do not sign in and change their password within a specified number of days; a security administrator must reset their password to reactivate them
• The system has the ability to automatically shut down a session after a number of unsuccessful login attempts
• IP addresses can be locked out for a specified number of minutes after a maximum number of unsuccessful login attempts
• Security administrators are able to force users to change their password on their next login
• Security administrators can specify access start and end date for logins
• Security administrators can enable or disable access for any user for any time period
Security administrators establish their own rules for system access by type of user. [{$applicationname}] offers many techniques for restricting access:
*Users are authenticated at login time - they must identify who they are and they must supply a confidential password
*Highly secure encryption techniques are used for all passwords, with no ability to de-encrypt
*Complicated password schemes are supported:
**ability to force codes to be a minimum length
**ability to force the use of at least one numeric digit
**ability to force at least one punctuation character
**case sensitive
*Users are notified by email whenever their password is changed, if they have an email address
*The system is able to force password changes after a specified number of days
*The system is able to force a new password to be different from the previous ‘n’ passwords
*An option is provided to lock out users who do not sign in and change their password within a specified number of days; a security administrator must reset their password to reactivate them
*The system has the ability to automatically shut down a session after a number of unsuccessful login attempts
*IP addresses can be locked out for a specified number of minutes after a maximum number of unsuccessful login attempts
*Security administrators are able to force users to change their password on their next login
*Security administrators can specify access start and end date for logins
*Security administrators can enable or disable access for any user for any time period
At line 290 changed 2 lines
!ePersonality System Access Rules
All access rules in ePersonality are defined by accessor type on the IMAR-Establish System Access Rules screen. Access rules do not have to be set up in advance. They are created automatically during the first login if they do not already exist. However, the automatically generated access rules have no restrictions.
![{$applicationname}] System Access Rules
All access rules in [{$applicationname}] are defined by accessor type on [IMAR]. Access rules do not have to be set up in advance. They are created automatically during the first login if they do not already exist. However, the automatically generated access rules have no restrictions.
At line 293 changed one line
Security administrators are encouraged to set up these rules manually to enforce the security restrictions required by their organization.
Security administrators are encouraged to set up these rules manually to enforce the security restrictions required by their organization.
At line 295 changed one line
ePersonality’s login and password verification techniques are all implemented within the application software and are not dependent on the database engine. The access rules no longer come from Oracle Profiles. Oracle Profiles should no longer be used in the ePersonality environment.
[{$applicationname}]’s login and password verification techniques are all implemented within the application software and are not dependent on the database engine. The access rules no longer come from Oracle Profiles. Oracle Profiles should no longer be used in the [{$applicationname}] environment.
At line 297 changed one line
Oracle Profiles should no longer be used in the ePersonality environment.
Oracle Profiles should no longer be used in the [{$applicationname}] environment.
At line 299 changed one line
eP users are synchronized with the Oracle database users. When a user is created through the IMUS screen, an Oracle user is also created in the database. When a user’s password is changed in ePersonality, it is also changed at the database level. Self Service users and Candidates are not identified as individual users at the database level.
[{$applicationname}] users are synchronized with the Oracle database users. When a user is created through [IMUS], an Oracle user is also created in the database. When a user’s password is changed in [{$applicationname}], it is also changed at the database level. Self Service users and Candidates are not identified as individual users at the database level.
At line 301 changed one line
Below is a description of the options provided on the IMAR screen:
Below is a description of the options provided on [IMAR]:
At line 303 changed 2 lines
;Accessor Type:The Accessor Type is a mandatory field that identifies the type of user.
The allowed values shown below are based on the fixed lexicon X_ACCESSOR_TYPE:
;[Accessor Type| ]:The Accessor Type is a mandatory field that identifies the type of user.
The allowed values shown below are based on the fixed lexicon [X_ACCESSOR_TYPE]:
This page (revision-39) was last changed on 26-Nov-2021 10:22 by jaikenTop