Wiki: USER PASSWORDS

USER PASSWORDS#

Login Security#

The Wiki application tightly controls who can access the system. Strict security rules are enforced for all types of users - Wikiusers, Self Service users and Candidates.

Wiki User Login#

Wiki users enter the Wiki Professional system through the login screen:

User Name: A user name must be provided. The user name is a unique identifier that indicates a user’s roles, capabilities and access rights. User names may be up to 30 alphanumeric characters. User names are assigned by a security administrator.

User Password: A user password must be provided to authenticate the person logging in. The password field is masked with asterisks as it is entered to keep it confidential. Passwords may be up to 16 alphanumeric characters; they are encrypted in the database. Passwords are initially generated by the system but may be subsequently maintained by the Wiki user or a security administrator.

Wiki users will only be allowed to use the system if their credentials match those on file and if there are no restrictions currently imposed on their access. They may be asked to change their password as soon as their login has been validated under any of the following circumstances:

their password has expired
a security administrator has chosen to “Force Password Change On Next Login”
access rules have changed

Wiki users credentials are validated against the information coded on the IMUS Access tab and are subject to the security rules established in the IMAR screen. The database that the user will be connected to is identified in the URL that was used to start the application.

Wiki User Forgotten Passwords#

If an Wiki user forgets their password, they should click the Forgot Password button on the login screen.

A dialog appears requesting their first name, last name, person code and email address. When they click the Send Email button, the system compares this information with the data currently on file. If the user can be authenticated and if they have an email address already on file, a new password will be generated and sent to them by email. Otherwise, they must contact their security administrator to have a new password assigned.

First Name: A first name must be provided.

Last Name: A last name must be provided.

Person Code: A person code must be provided. The person code is a unique identifier that was assigned to the person at the time the person was first entered into the system.

Email Address: An email address must be provided.

Self Service User Login#

Self Service users enter the Wiki Self Service system through the login screen:

Last Name: A last name must be provided. This field is not case sensitive.

Person Code: A person code must be provided. The person code is a unique identifier that was assigned to the person at the time the person was first entered into the system.

PIN: A PIN number must be provided to authenticate the person logging in. The PIN number field is masked with asterisks as it is entered to keep it confidential. PIN numbers may be up to 16 alphanumeric characters; they are encrypted in the database. PIN numbers are initially assigned by the system but may be subsequently maintained by the Self Server user or a security administrator.

The term “PIN” and “Password” can be used interchangeably. Self Service passwords are normally referred to as PIN numbers to differentiate them from Wiki User and Candidate passwords. Self Service users will only be allowed access if their credentials match those on file and if there are no restrictions currently imposed on their access. They may be asked to change their password as soon as their login has been validated under any of the following circumstances:

their password has expired
a security administrator has chosen to “Force Password Change On Next Login”
access rules have changed

Self Service user credentials are validated against the information coded on the IEID Self Service Access tab and are subject to the security rules established in the IMAR screen. The database that the user will be connected to is identified in the URL that was used to start the application.

Password error messages are intentionally vague so they do not inadvertently disclose the password schemes to unauthorized users.

Self Service User Forgotten Passwords#

If a Self Service user forgets their password, they can click the Forgot Password button on the login screen. A dialog appears requesting their first name, last name, person code and email address. When they click the Send Email button, the system compares this information with the information currently on file. If the user can be authenticated and if they have an email address already on file, a new password will be generated and sent to them by email. Otherwise, they must contact their security administrator to have a new password assigned.

Candidate Login#

Candidates enter the Wiki Candidate Self Service system through the following login screen:

Last Name: A last name must be provided. This field is not case sensitive.

Candidate Code: A candidate code must be provided. The candidate code is a unique identifier that was assigned to the candidate on their first login.

[Password]: A password must be provided to authenticate the Candidate. The password field is masked with asterisks as it is entered to keep it confidential. Passwords may be up to 16 alphanumeric characters; they are encrypted in the database. Passwords are initially assigned by the Candidate on their first login but may be subsequently maintained by the Candidate or a security administrator.

Candidates will only be allowed access if their credentials match those on file and if there are no restrictions currently imposed on their access. They may be asked to change their password as soon as their login has been validated under any of the following circumstances:

their password has expired
a security administrator has chosen to “Force Password Change On Next Login”
access rules have changed

Candidate credentials are validated against the information coded on the Self Service Access tab in the IRCA Assessments tab and are subject to the security rules established in the IMAR screen. The database that the candidate will be connected to is identified in the URL that was used to bring up the login screen.

New Candidate Verification#

Candidates that are new to the site should click the “Are you a new candidate?” link on the login screen. A dialog appears requesting their first name, last name and email address.

First Name: A first name must be provided.

Last Name: A last name must be provided.

Email Address: An email address must be provided.

When they click the Continue button, the system checks to see if the credentials they have entered are already on file. If they are on file, the Candidate must try logging in again or follow the “Forgot my password” path. New Candidates are shown their Candidate Code and asked to provide a password. They must enter the password a second time to confirm it. Candidates must remember their code and password for the next time they log in.

Candidate Forgotten Passwords#

If a Candidate forgets their password, they should click the Forgot Password link on the login screen. A dialog appears requesting their first name, last name and email address. When they click the Continue button, the system compares this information with the data currently on file. If the Candidate is valid and if they have an email address already on file, a new password will be generated and sent to them by email. Otherwise, they must contact their security administrator to have a new password assigned.

First Name: A first name must be provided.

Last Name: A last name must be provided.

Email Address: An email address must be provided.

Session Auditing#

Every successful login to Wiki initiates a new application session. Session connection information and user context data is recorded on the P2K_AM_SESSION_AUDITS table in the database. The system tracks who has accessed the system, when they logged in and out, how they accessed it and what roles they had at the time of the session.

Failed login attempts are also tracked in the database and in the application server logs.

Valid Password Formats #

Below is a list of the restrictions imposed on the format of passwords:

Passwords must start with an alphabetic character
Passwords cannot equal the user name
Passwords cannot be a common phrase like welcome, database, account user, password, oracle, computer, etc. This is controlled through a lexicon X_BLOCKED_PHRASES.
If a Minimum Password Size has been provided in the access rules, the password must be at least as long as the minimum length.
If the Must Contain Digit option is chosen in the access rules, the password must contain a numeric digit.
If the Must Contain Punctuation is chosen in the access rules, the password must contain at least one of the following characters: ! # $ % & ( ) ` * + , - / : ; < = > ? _
Passwords cannot contain the following characters: " ' @

Generated Password Formats #

System generated password are always 8 digits in the following format:

1st digit	random uppercase letter
2nd digit	random lowercase letter
3rd digit	random digit
4th digit	random digit
5th digit	random lowercase letter
6th digit	random lowercase letter
7th digit	random digit
8th digit	random digit

Because they follow a common pattern, it is easy to differentiate between numbers and letters (e.g. 0 vs o, I vs 1, etc.)

User Password Changes#

All users have the ability to change their own passwords from within the application.

Wiki User Password Changes#

Wiki users may change their own password through IMCU within the Wiki Professional application.

User Name: The user name defaults to the user who is currently logged in.

Existing Password: The existing password must be entered to authenticate the request.

New Password: A new password must be supplied.

Confirm Password: The new password must be entered a second time to ensure that it has not been keyed incorrectly.

Password validation is done as soon as the user hits the Save button. If the validation fails, the user is notified in a dialog. Password changes that pass the validation are effective immediately.

Self Service User Password Changes#

Self Service users may change their own password through the WEDPN screen within the Self Service application.

User Name: The user name defaults to the user who is currently logged in.

Existing PIN: The existing password must be entered to authenticate the request.

New PIN: A new password must be supplied.

Confirm PInThe new password must be entered a second time to ensure that it has not been keyed incorrectly.

The term “PIN” and “Password” can be used interchangeably. Self Service passwords are normally referred to as PIN numbers to differentiate them from Wiki User and Candidate passwords.

PIN number validation is done as soon as the user clicks the Save button. If the validation fails, the user is notified in a dialog. PIN number changes that pass the validation are effective immediately.

Candidate Password Changes#

Candidates may change their own password through the WCRPIN screen within the Candidate Self Service application.

User Name: The user name defaults to the user who is currently logged in.

Existing PIN: The existing password must be entered to authenticate the request.

New PIN: A new password must be supplied.

Confirm PIN: The new password must be entered a second time to ensure that it has not been keyed incorrectly.

Password validation is done as soon as the user clicks the Save button. If the validation fails, the user is notified in a dialog. Password changes that pass the validation are effective immediately.

Resetting User Passwords#

Security administrators are able to reset other user passwords when necessary.

Resetting Wiki User Passwords#

Wiki user passwords can be reset by security administrators through either the IMRU screen or through the IMUS Access tab within the Wiki Professional application. These functions should be highly secured.

Find Block: The Wiki user whose password is to be changed must be located in the Find block on the top line.

New Password: A new password must be supplied or the “generate” toggle must be turned on.

Confirm Password: If the new password is being supplied, it must be entered a second time to ensure that it has been keyed correctly.

Or Generate New Password: This toggle must be turned on if the security administrator wants the new password to be generated by the system.

Force Password Change On Next Login: This toggle allows the security administrator to force the user to change their password on their next login.

Password validation is done as soon as the security administrator clicks the Save button. If the validation fails, the security administrator is notified in a dialog. Password changes that pass the validation are effective immediately. System generated passwords are displayed back to the security administrator to be given to the user. If the user has an email address on file, the new password will be sent to the user by email.

Resetting Self Service PIN Numbers#

Self Service PIN numbers can be reset by security administrators through either IMRE or through the IEID Self Service Access tab within the Wiki Professional application. Access can be restricted to specific personnel records in both of these functions by setting up appropriate security rights.

Find Block: The person whose PIN number is to be changed must be located in the Find block on the top line.

New PIN: A new PIN number must be supplied or the “generate” toggle must be turned on.

Confirm PIN: If the new PIN number is being supplied, it must be entered a second time to ensure that it has been keyed correctly.

Or Generate New PIN: This toggle must be turned on if the security administrator wants the new PIN number to be generated by the system.

Force PIN Change On Next Login: This toggle allows the security administrator to force the user to change their PIN number on their next login.

The term “PIN” and “Password” can be used interchangeably. Self Service passwords are normally referred to as PIN numbers to differentiate them from Wiki User and Candidate passwords.

PIN number validation is done as soon as the security administrator clicks the Save button. If the validation fails, the security administrator is notified in a dialog. PIN number changes that pass the validation are effective immediately. System generated PIN numbers are displayed back to the security administrator. If the user has an email address on file, the new PIN number will be sent to the user by email.

Resetting Candidate Passwords#

Candidate passwords can be reset by security administrators through either the IRPIN or through the IRCA Assessments tab within the Wiki Professional application.

Find Block: The Candidate whose password is to be changed must be located in the Find block on the top line.

New Password: A new password must be supplied or the “generate” toggle must be turned on.

Confirm Password: If the new password is being supplied, it must be entered a second time to ensure that it has been keyed correctly.

Or Generate New Password: This toggle must be turned on if the security administrator wants the new password to be generated by the system.

Force Password Change On Next Login: This toggle allows the security administrator to force the Candidate to change their password on their next login.

Password validation is done as soon as the security administrator clicks the Save button. If the validation fails, the security administrator is notified in a dialog. Password changes that pass the validation are effective immediately. System generated passwords are displayed back to the security administrator. If the Candidate has an email address on file, the new password will be sent to the Candidate by email.

System Accessors#

Many different types of users use the Wiki system – Wiki Professional users, Self Service users and Candidates. All of these different types of users are referred to as “accessors” of the system. Wiki uses a consistent approach for managing all accessors of the system. The system also tracks user activity that could be useful in analyzing security breaches:

Date and time of the last successful login
Number of failed login attempts since a user’s last successful login
Number of successful logins to date for each user
Who made the last password change
When the last password change was made
Session audit records for each successful login

In addition to this information which is all held in the database, the application server logs also track each login.

Authorizing Users#

Each type of Wiki user has a specific way of being authorized to access the system.

Wiki users are created and authorized through IMUS.
Self Service users must be hired into the system; they may then be authorized to use the Self Service application through IEID.
Candidates who register through the web are automatically given access to the Candidate Self Service application at the time they register.
Candidates who are entered into the system through IRCA may also be given access to the Candidate Self Service application through IRCA.

Below is a description of each of the different ways users can be authorized in Wiki.

Authorizing Wiki Users#

Wiki users are maintained by security administrators through the IMUS within the Wiki Professional application. Users created through IMUS are stored in the P2K_AM_USERS table and also become Oracle users. This function should be highly secured.

Find Block: The user to be viewed or changed must be located in the Find block, unless an Add is being done.

User: A user name must be provided on an Add and cannot be changed after the user has been created. The user name is a unique identifier that identifies a user’s roles, capabilities and access rights. User names may be up to 30 alphanumeric characters. User names are always assigned by the security administrator.

Description: This field contains optional text that describes the user.

Email: An optional email address may be provided for the user. This is the address that system generated passwords will be sent to.

Person Code: If the user also has a unique Identity record in the system, a link to the Identity record may be provided.

Name: This 'display only' field shows the name of the person identified in the Person Code field.

Create / Retrieve / Update / Delete Toggles: These toggles indicate the overriding access capabilities assigned to the user. These may be reduced for individual functions.

P2K Access Information: This section provides the access information used by P2K. It is provided for compatibility reasons only.

Access Tab: This section contains the access information that is used by Wiki. Refer to the Common Accessor Information section for a detailed description.

Authorizing Self Service Users#

Each Self Service user must have an Identity record and be assigned a person code. However, it is not necessary for every person that is assigned a person code to be given Self Service access. Self Service users are maintained by a security administrator through the IEID Self Service Access tab within the Wiki Professional application.

Find Block: The person to be granted Self Service access must be located in the Find block.

User Profile: A user profile must be assigned to each Self Service user to identify their roles, capabilities and access rights. User profiles are defined on IMUS. The same user profile may be used for many Self Service users.

Person Code: The system displays the person code of the Self Service user.

First Name: The system displays the first name of the Self Service user.

Last Name: The system displays the last name of the Self Service user.

Personal Email: The system displays the email address of the Self Service user. This is the address that system generated passwords will be sent to. The email address is taken from IEPI.

Pswd/PIN Changed By: The system shows who last changed the Self Service user’s password.

Pswd/PIN Changed On: The system shows when the Self Service user’s password was last changed.

The term “password” and “pin” are both used for Self Service users. They mean the same thing and can be used interchangeably.

Remaining Access Information: Refer to the Common Accessor Information section below for a detailed description.

Authorizing Candidates#

Candidate access information is created when they follow the New Candidate process. Their initial password is assigned at that time but it may be changed later.

Candidate access information is viewed and maintained by a security administrator through the IRCA Self Service Access tab within the Wiki Professional application.

Find Block: The candidate must be located in the Find block.

Candidate #: The system displays the candidate number.

First Name: The system displays the candidate’s first name.

Last Name: The system displays the candidate’s last name.

Personal Email: The system displays the candidate’s email address. This is the address that system generated passwords will be sent to.

Password Changed By: The system shows who last changed the candidate’s password.

Password Changed On: The system shows when the candidate’s password was last changed.

Remaining Access Information: Refer to the Common Accessor Information section below for a detailed description.

Common Accessor Information#

All users of the system have associated accessor records made up of a header containing static information and date sensitive details containing information that varies over time.

Accessor Header Information#

Access Start Date: The Access Start Date identifies the earliest date the user is allowed access, regardless of the Access Status.

Access End Date: The Access End Date identifies the latest date the user is allowed access, regardless of the Access Status.

Force Password Change On Next Login: This toggle allows the security administrator to force the user to change their password on their next login.

Set / Reset Password: This action button allows the security administrator to reset a user’s password by automatically bringing up the appropriate Reset Password screen. When a password is reset, a new password is assigned, a new effective access detail record is created, the Access Status is changed back to “Active” and the Failed Attempts are erased.

Reactivate: This action button allows the security administrator to reactivate a user’s access in the event it has been locked out or disabled. During reactivation, a new effective access detail record is created, the Access Status is changed back to “Active” and the Failed Attempts are erased.

Last Good Access: The system shows the date and time of the last successful login.

Logins To Date: The system shows a count of the number of successful logins the user has had since the accessor record was created.

Accessor Date Sensitive Details#

Date Sensitive Navigator: The Date Sensitive Navigator is a special form block that allows users to view date sensitive records and make date sensitive changes. Refer to the User Interface manual for a more detailed description.

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

System Access Rules #

Security administrators establish their own rules for system access by type of user. Wiki 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

Wiki System Access Rules#

All access rules in Wiki 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.

Security administrators are encouraged to set up these rules manually to enforce the security restrictions required by their organization. Wiki’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 Wiki environment.

Oracle Profiles should no longer be used in the Wiki environment. Wiki 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 Wiki, it is also changed at the database level. Self Service users and Candidates are not identified as individual users at the database level.

Below is a description of the options provided on IMAR:

Accessor Type: The Accessor Type is a mandatory field that identifies the type of user.
The allowed values are based on the fixed lexicon X_ACCESSOR_TYPE.

Validation Method: Validation method is a mandatory field that identifies whether the new Wiki password facility is being used and it identifies the algorithm used for encrypting the passwords.
The allowed values are based on the fixed lexicon X_VALIDATION_METHOD:

Minimum Password Size: This optional numeric field specifies the minimum length of the password. Passwords that are shorten than this will be rejected.

Must Contain Digit: This toggle indicates that the password must contain at least one numeric digit. If the toggle is off the system does not impose a restriction.

Must Contain Punctuation: This toggle indicates that the password must contain at least one punctuation character. If the toggle is off the system does not impose a restriction.

Force Password Change Toggle: This field contains the default for the “Force Password Change” toggle for system generated passwords.

Password Must Change: This toggle indicates that new passwords must not match the prior password. If the toggle is off the system does not impose a restriction.

# Prior Passwords: This optional numeric field specifies the number of prior passwords that must be different than the new password. This option forces a user to use different passwords each time. If the field is empty the system does not impose a restriction.

Password Expires-Dys: This optional numeric field specifies the number of days that a user’s password can exist before going stale. Once the user’s password expires it must be changed on the next login. If the field is empty, the system does not expire the password.

Lock After Expires-Dys: This optional numeric field specifies the number of days following password expiration that the user’s access records will remain active. After this the user’s access records will be locked. If this field is empty the user’s access records will remain active indefinitely.

Login Attempts: This optional numeric field specifies the number of login attempts a user is allowed before the session expires. If the field is empty the system does not impose a restriction.

Max Login Attempts: This optional numeric field specifies the number of login attempts a user is allowed before their access records are locked out. If the field is empty the system does not impose a restriction.

IP Lockout Minutes: This optional numeric field specifies the number of minutes an IP address will remain locked out after the maximum number of login attempts have been reached. If this field is empty, the lockout remains until it is reset by a security administrator.

This feature uses a server setting that applies to an IP address; hence, all accessor types should use the same setting. If different IP Lockout Minutes are used for different accessor types, the most restrictive setting will apply.

This feature should not be used in environments that use kiosks.

Notes #

Click to create a new notes page

Table of Contents