CORE User Access Policy

Organizational Structure

Each department controller is the department security administrator for the departments under their purview. Department security administrators have the authority to manage user access to users in their departments. Each department controller may delegate CORE department security administration to his/her department staff. Department security administrators and delegates are responsible for entering and approving UDOCs to users in their department. 

User ID Naming Convention

Requirements:

1. maximum length of 16 characters

2. all lowercase letters

The user ID should follow a standard naming convention comprised of several nodes up to a maximum of 16 characters. An example of a user ID and an explanation of each of the naming convention nodes are described below:

1. First Initial: the first node is the initial of the user’s name

2. Period: the second node is a period to separate the first initial and last name

3. Last Name: the third node is the user’s last name. Due to the maximum number of characters the last name may have to be truncated

Examples:

• Anthony Smith = a.smith

• Johnny Messersmithington (exceeds 16 character limit, so truncate) = j.messersmithing

If the user ID is in use by another user, insert a number or replace the last character with a number when the character limit has been met.

Examples:

• Aldon Smith = a.smith1

• Jeff Messersmithington = j.messersmithin1

• Katherine Doe = k.doe

• Larry Smith = l.smith

• Lacie Smith = l.smith1

Password Resets

Users can reset their password via two methods:

1. Users are required to setup a password hint and security questions. Doing so will allow users to reset their own password by answering a security question. A user would reset their own password by clicking the “Forgot Your Password” link from the CORE logon homepage and following the prompts.

2. Contact the CORE Help Desk (core.help@state.co.us) with a password reset request.

Password shall NOT be shared with anyone. If a user believes their password has been compromised they must reset their password immediately via the aforementioned methods.

Users have three attempts to sign into CORE successfully. Upon entering an incorrect password for the third attempt, the user’s account will be locked. At this point, they must contact the CORE Help Desk for assistance.

CORE will automatically force users to reset their passwords every 90 days.

Central Approval

UDOCs will route centrally for several reasons:

• The Office of the State Controller (OSC) may require certain security and workflow roles to be added to a UDOC to route to the OSC for approval. The OSC has the authority to change workflow as they see fit to safeguard the integrity of the internal system and meet business requirements.

• Invalid selection of options under the “Applications” tab of the UDOC’s Header; only “Advantage Financial”, “Password Reset” and "ADVANTAGE Performance Budgeting" should be selected.

• Selection of any cost allocation security role.

When a UDOC routes centrally to the OSC for approval, the access will be reviewed based on the following criteria:

1. Professional need of access requested

2. “Application” options selected

Prerequisites For Roles

There are roles in the application that require an extra level of discretion and pre-requisites before approval will be given by the OSC. These roles and their requirement are listed below:

D_U_VC_DOC_ENTRY:

The OSC’s Central Accounting and Vendor Operations (CAVO) will review UDOCs requesting access to this role.  Departments will be limited to two employees per cabinet. A CORE Vendor Entry Background Verification form is required when "Add"ing this role to a user's access.

D_GA_APPR_MAINT:

The OSC’s Financial Services Unit (FSU) will review UDOCs requesting access to this role. This role is used to manage appropriation units on the APPR table. Completion of a FSU-led appropriations training is required before consideration will be given when “Add”ing this role to a user’s access.  Please contact dpa_FARmailbox@state.co.us for more information.

Foreign Organization Access

Foreign organization access constitutes extending a user’s access to include additional department codes to their home department (i.e. access to document entry and or table maintenance roles for another department). Department security administrators will communicate foreign organizational access needs with a comment on every UDOC explicitly listing departments the user needs access to. Proper procedure to communicate foreign organization access needs:

1. Insert a comment

2. Subject must clearly indicate purpose is for foreign organization access (e.g. Foreign Org, Foreign)

3. Comment must explicitly list all departments (e.g. AAAA, AABA, AAEA) or use cabinet code and wildcard to indicate entire cabinet access (e.g. A*; C***; E*)

• Comments must be added to a UDOC before it reaches a status of “Final”.

CORE Operations will receive an automatic email notification from CORE when the foreign organization security role, D_SW_UDOC_FORGN, has been “Add”ed or “Update”d, additional security roles are “Add”ed on a user’s UDOC, and it reaches the Final phase.

Note: Users requesting access to another department’s code(s) not under the purview of their department security administrator must receive authorization from the Controller(s) of the requested department(s). The approval to grant foreign organization access must be indicated by a comment from said controller(s) on the UDOC and listing the authorized department codes.

PB Access

PB Access constitutes extending a user’s CORE access to include access to the Performance Budget Application.  Department security administrators will communicate the PB access needs with a comment on every UDOC explicitly listing the Security Organization Codes the user needs access to and/or an existing PB User ID to mirror. 

Proper procedure to communicate PB Access needs:

1. Select ADVANTAGE Performance Budgeting box on the Applications section of the UDOC Header

2. Insert a comment with "PB Access" in the Subject field

3. Explicitly state PB Access Approved and list all Security Orgs (e.g. PUBLIC, F, APPS-F, FUNDS-F) or use another active user id to mirror access in the Comment field

Comments should be added to a UDOC before it reaches the status of “Final”. CORE Operation will receive an automatic email notification from CORE when the PB Approval security role, D_SW_UDOC_PBAPP, has been “Add”ed or “Update”d and additional security roles are “Add”ed on a user’s UDOC and it reaches the Final phase.

NOTE: Users requesting access to PB Application must receive authorization from the Budget Director of the user's home department.  This is indicated by a comment from the Budget Director on the UDOC.

Business Roles

Business Roles are new to CORE with the upgrade to Advantage 4.x.  The Business Role gives users a kind of shortcut homepage view specific to the user's actual job role.  These Business Roles do not affect the security and workflow access, they only visually present a homepage to specifically capture the intended type of work showing Quick Links and Widgets to help facilitate a user's job functions. 

Security Administrators need to add at least one Business Role to a UDOC for every new user, and should review existing assigned Business Roles for update UDOCs to ensure they align with the user’s job functions.  Users who are granted system access via a UDOC without a Business Role assigned will receive an error message and not be able to perform work until an update UDOC to assign a Business Role is completed.

Examples:  FIN BRoles for CORE

• AP General User

• AR General User

• Budget General User

• FIN General User

• Grant Accountant

• Inventroy Management

• Procurement General User

Access Ownership

Departments are responsible for ensuring that users in their department(s) do not have access to multiple user IDs. Access to one of the accounts should be disabled immediately, to the extent possible, when a duplicate user ID has been identified.

An exception to this is in circumstances of contract auditors that are auditing more than one agency. For the unique access needs that contract auditors require, department security administrators should set up an ID for the contract auditor for the home department that is being audited, following the standard CORE User ID naming convention. Since a single contract auditor may be auditing several agencies, the result is that an auditor may have User ID j.doe1 for home department AAAA and User ID j.doe2 for home department BAAA. It is recommended that AUDITOR be entered into the Locality field on the UDOC when the auditor is granted access. Department Controllers are responsible for ensuring appropriate access compliance for contract auditors in CORE for their home departments.

Statement of Agreement Form

A completed Statement of Agreement must be attached to a UDOC when the user is:

1. A brand new CORE user

2. A CORE user who transferred from a different cabinet or department not under the purview of the new department security administrator

Access may be revoked if the user violates the Statement of Agreement.

CORE Vendor Entry Background Verification

A completed CORE Background Verification form must be attached to a UDOC when the user is “Add”ing the Department Vendor Creation Transaction Entry Role (D_U_VC_DOC_ENTRY).

Application Timeout

All CORE environments timeout after 60 minutes of inactivity and require the user to enter their password again to access the system.

Controller's Role

The controller reserves the right to grant or remove access for users in their departments as they see fit to meet the business needs.

Add New User Access

To add a new user who has never had access to CORE, the department security administrator or designee enters the UDOC:

• Attach completed SOA to the Header line of the UDOC

• Attach completed CORE background check form, if applicable

• Add foreign organization access comment, if applicable

The submitted UDOC will route for department approval and then, if certain conditions are invoked, route to the OSC for additional approval. Upon the application of the final approval, an automatic email notification from CORE with an auto-generated temporary password will be sent to the user’s email entered on the UDOC. Foreign organization access will be setup manually by CORE Operations, if applicable.

Modify User Access

To modify an existing user’s access, the department security administrator or designee enters the UDOC:

• Attach completed SOA to the Header line of the UDOC, if applicable

• Attach completed CORE background check form, if applicable

• Add foreign organization access comment, if applicable

Remove foreign organization access, if applicable. When attempting to remove a security role that has an entry on the foreign organization table in CORE the following message will be displayed on the UDOC:

• "Unassignment of the Security Role is not permitted because Foreign Organization records exist for this User ID and Role combination. To unassign the Role, first, delete the associated foreign organization records."

Email the CORE Help Desk (core.help@state.co.us) when a UDOC receives the error above with subject Foreign Org Removal and include in the body of the email:

• User ID

• Security roles to delete

The submitted UDOC will route for department approval and then, if certain conditions are invoked, route to the OSC for additional approval. Existing users will not be sent an automatic email notification with a temporary password. The latest password used to log onto CORE will still be applicable. If necessary, see the steps in the documentation above for resetting a password. Foreign organization access will be setup manually by CORE Operations, if applicable.

Disable User Access

To disable an existing user’s access, the department security administrator or designee enters the UDOC in CORE. Remove foreign organization access, if applicable. When attempting to remove a security role that has an entry on the foreign organization table in CORE the following message will be displayed on the UDOC:

• "Unassignment of the Security Role is not permitted because Foreign Organization records exist for this User ID and Role combination. To unassign the Role, first delete the associated foreign organization records."

Email the CORE Help Desk (core.help@state.co.us) when a UDOC receives the error above with subject Foreign Org Removal and include in the body of the email:

• User ID

• Security roles to delete

Once submitted the UDOC will route for department approval. Properly completed UDOCs for disabling access should not route to the OSC for approval.

Change User Access

Users are permitted to change their user ID when they have completed a name change with their Human Resources Department (e.g., gets married). To change a user’s ID:

1. The user should ensure all transactions pending approval under their ID are approved or reassigned to another user.

2. The department security administrator must first disable the current user ID’s access and then can proceed to add a new user ID for the individual.

Transfer User Access

CORE users who transfer cabinets or departments must use the same user ID within CORE regardless of where or how many times they transfer. To transfer an existing user’s access:

1. The user should ensure all transactions pending approval under their ID are approved or reassigned to another user before transferring

2. The old department security administrator or designee will disable the user’s access on their last day or immediately after.

3. After step 2 has been completed, the new department security administrator or designee will enter a UDOC in CORE for the user.

4. If Foreign Org access is required for the new department, a comment indicating the additional access should be added to the new agency UDOC before it is submitted to final. This includes if temporary foreign org access is required by the employee for both the new and old agencies, such as during a duties transition period while the employee moves to the new agency.

Lock/Unlock Users

Users may be temporarily locked out of CORE. Security administrators may lock individual users and the CORE technical team may lock users en masse. A user access form is not required to lock users.

Lock Users Ad Hoc

Security administrators have the authority to lock individual users at their discretion. Security administrators should consider the following minimum factors in determining when it is appropriate to lock a user:

• The user will be on extended leave of generally more than 30 days

• Additional user training is required

• The department has concerns that its internal controls environment have been compromised

Lock Users En Masse

The State may need to lock users en masse for various reasons including, emergencies in which system activity must stop to remedy an issue, system maintenance, upgrades, and other downtime activities. The process for locking users is as follows:

1. The CORE System Administrator or his/her delegate will open a ticket with the CORE Vendor (CGI), marked as urgent, to run a script to lock out users. The script will turn the “Locked out” field on the SCUSER table to “Locked”.

2. While the users are locked out only a few users will be authorized to enter CORE via the Job Manager.

3. A notice to all users regarding the lock out will be communicated via a CORE Communication.

4. Once the system is ready to be unlocked, The CORE System Administrator or his/her delegate will open a ticket with the CORE Vendor (CGI), marked as urgent, to run a script to unlock users. The script will turn the “Locked out” field on the SCUSER table to “Active”.
   Note: The script will only unlock users who were active at the time the system was locked. That is, users who were locked in CORE prior to the mass lock-out, will remain locked.

5. A notice to all users regarding system readiness and user unlock will be communicated via a CORE Communication.

EMERGENCYID and BATCH Use 

EMERGENCYID and BATCH user IDs with administrator rights are available for checkout to CORE Operations staff. They are used to address critical issues that cannot be addressed by using a current security role or a combination of security roles, or the nature of the issue needs immediate remedy such that obtaining access through the standard UDOC process is not possible or reasonable based on the need. Procedure for requesting emergency ID:

1. The CORE Operations staff member must open or have an existing incident/change order/user story with a completed EMERGENCY ID and BATCH Request Form and supporting documentation attached. The form will:

• Define the issue

• Explain of analysis performed

• Define the end goal solution

• Have signoff from manager (via comment)

2. The CORE Operations staff member will communicate the ID issuance request to the System Administration Team for EMERGENCYID or BATCH.

• The System Administration Team will create a new Incident for reporting purposes, and then take appropriate system steps to assign EMERGENCYID or BATCH to the requester.

3. The CORE Operations staff member will use the EMERGENCYID or BATCH as intended.

4. The CORE Operations staff member will communicate when user ID usage is complete to System Administration Team

5. The System Administration Team will close EMERGENCYID or BATCH.

It is the responsibility of the requestor and their manager to support and validate the use of EMERGENCYID or BATCH. All and any activity of EMERGENCYID or BATCH between the time the requestor is emailed the password and the ID is subsequently locked by the System Administration team, its usage and purpose, etc., is the responsibility of the requestor.

The EMERGENCYID or BATCH is valid for 24 hours from issuance (i.e., when the requestor is emailed the password). If use of the EMERGENCYID or BATCH is completed prior to 24 hours, the requestor should notify the System Administration team to disable the ID. Otherwise, the System Administration Team will disable the ID and reset the password after 24 hours unless an extension is requested prior to the 24-hour deadline.

The System Administration team will review EMERGENCYID and BATCH access incidents on a weekly basis to ensure an incident has been opened for its use. In the event a discrepancy is identified in review, the System Administrator will remediate the finding(s) accordingly.

Non-Production Access

• All active CORE users in production are permitted to access the non-production environments. CORE Help Desk will confirm that the user already has an active production account in CORE before they reset the user’s password in the non-production environment.

• If an active CORE user in production does not exist in the non-production environment, the requestor must open a ticket with the CORE Help Desk by sending an email to core.help@state.co.us. It must include which environment they require access to and an account will be created by CORE Operations.

• If you do not have an active CORE production account, you are not permitted to have non-production environment access.

• Periodically, data from the production environment is copied into non-production environments, causing all the non-production data to be overlaid. As a result, any customized user access in the non-production environment is lost.

User roles in non-production environments still follow the same rules as the production environment. Unless authorized, users must not have access, like production, to the following security roles:

• ALL_READ

• ALL_UPDATE

• ADMN

• D_U_VC_DOC_ENTRY

• D_IC_DOC_ENTRY

Note: Users in the OSC and department users who play an instrumental role in any project testing may be provided ALL_UPDATE access at the discretion of the CORE System Administration team.