Gilbert Public School District No. 41

NOTICE OF REQUEST FOR PROPOSAL

Identity Management System

18-28-07-23

EXHIBIT A

Purpose

The Gilbert Public school district has a need to replace our existing Identity Management Systems with a new system. This needs to be a completely new system, designed from the ground up. Technology changes, major system replacements and evolving requirements have left us with a system that no longer meets our needs. The District is requesting a “turn-key” operation that will include installation, training, and implementation unless offers for an Application Service Provider are received and found to be more desirable.

GPS expectations are this this will be a turn-key system completely functional at the go live time no later than July 1 of 2018. It will be necessary to develop and implement the new systems “side by side” working with GPS personnel in order to insure correct functionality and proper systems integrations. The primary integrations will be with Microsoft Active Directory and with Google mail, applications and Apps for Education. The main data sources will be Tyler’s Infinite Visions financial and HR system and the Infinite Campus student information systems. Both of these have been in production for several years. Both Infinite Campus and Infinite Visions are Microsoft server based products. Both utilize MS SQL as their respective database servers.

History: Our existing system was developed in house based around Novell's Identity Management product. These systems have been in place and operating for 10 years or longer. The Novell IDM was coupled to a custom written account management system that interfaced originally with an AS400 hosted Pearson CIMS system. The account management system is a Java based system running on the Linux platform. The CIMS student information system has been replaced twice. The current system is the Infinite Campus product. The CIMS financial and human resource management products have been replaced by Tyler's Infinite Visions system.

The Gilbert Public Schools staff have identified required characteristics, functions, components and optional/desired features of a comprehensive Identity Management Systems solution. These requirements are listed and categorized on the following pages, according to overall and specific identity management system components.

  1. Preparation and Expectations

The District has done some preliminary investigation of current identity management systems and options in order to determine the District requirements, as well as desires, for the system selected. The following specifications listed are a summary in nature:

  1. Proposals shall provide extensive documentation describing how the product functions. Include all details about the hardware standards for both hosted and remote servers and client requirements compatible on Windows, MAC, iOS and Android operating systems.
  2. Provide information regarding all necessary upgrades for the duration of this proposal including costs if applicable.
  3. Confidentiality of District information is required. If you are submitting a proposal for an ‘Application Service Provider’ (ASP), please note that all communications must be done through ports 80 and 443.
  4. System must also inter-operate with the District’s existing network and systems infrastructures.
  5. Data security considerations must be included. This should be for intersystem communications, data storage and connection to internet based services and providers.
  6. The vendor is required to have a thorough understanding of and system compliance with federal legislation (e.g., FERPA, COPPA, HIPAA etc.).
  1. Current GPS Field Mappings

File from Account Management / GUSD-TREE/AS400 driver / GUSD-TREE / IDM-TREE / ACTIVE DIRECTORY / Infinite Campus / Infinite Visions / Field In Another Table / Comments
username / CN / CN / CN / CN / username / portalUserName
lastName / LastName / Surname / Surname / SN / lastName / LastName
firstName / FirstName / Given Name / Given Name / firstName / FirstName
jobtitle / Title / Title / Title / Title / Student / JobID / tblPRMasterJobs
blank / Email / Internet Email Address / Internet Email Address / mail / emailAddress / EmployeeEmail / not used
departmentnumber / l / L / L / company / tblPRPrimaryWorksitesID / tblPRPrimaryWorksites / Look for Code in tblPRPrimaryWorksites
telephoneNumber / WorkPhone / Telephone Number / Telephone Number / telephoneNumber / telephoneNumberHome / WorkPhone / not used
fax / Fax / Facsimile Telephone Number / Facsimile Telephone Number / facsimileTelephoneNumber / not used
telephoneNumber2 / WirelessPhone / mobile / mobile / telephoneNumberCell / CellPhone / not used
accountType / employeeType / EmployeeType / EmployeeType / Staff, Student
probationDate / employeeStatus
middleInitial / Initials / Initials / Initials / middleName / MiddleName / First initial of middle name
jobType / jobCode / JobCode / JobCode / tblPRMasterClassification / tblPRMasterClassification / Certified,Classified, etc
homeZip / homeZipCode / zip / EmployeeZipCode
homeState / homeState / state / EmployeeState
File from Account Management / GUSD-TREE/AS400 driver / GUSD-TREE / IDM-TREE / ACTIVE DIRECTORY / Infinite Campus / Infinite Visions / Field In Another Table / Comments
preferredFirstName / preferredName / preferredName / preferredName / givenName / alias / FamiliarName
roomNumber / roomNumber / homeroomNumber
employeeId / workforceID / workforceID / workforceID / employeeNumber / EmployeeID
superkey / accessCardNumber / accessCardNumber / accessCardNumber / superKey
homeCity / homeCity / city / EmployeeCity
ssnLast4 / pager / pager / pager / EmployeSSN / Last 4 SSN
defaultPassword / nspmDistributionPassword / nspmDistributionPassword / nspmDistributionPassword / nspmDistributionPassword / see comments / default is gps+lower of first initial of first name+last 4 ssn
locationName / departmentNumber / departmentNumber / departmentNumber / locationName / tblPRPrimaryWorksitesID / tblPRPrimaryWorksites / Look for Code in tblPRPrimaryWorksites
dob / vehicleInformation / vehicleInformation / vehicleInformation / dob / BirthDate / MM/DD/YYYY format
homeroomNumber / roomNumber / homeroomNumber
homeroomUsername / costCenter / costCenter / costCenter
gradYear / jackNumber / jackNumber / jackNumber / department / gradYear
studentGrade / studentGrade / studentGrade / studentGrade / physicalDeliveryOfficeName / grade
noInternet / noInternet / noInternet / noInternet
Login Disabled / Login Disabled / dirxml-uACAccountDisable / status / tblPRStatusID / tblPRMasterStatus / Active,Pending Term, Inactive, LOA, New Hire Next YR, Volunteer, Active Retiree

SCOPE OF WORK

  1. Basic project overview
  1. Analyze existing systems designs, requirements and documentation to fully understand our systems, logic requirements and data flows both current and known future.
  2. Review fundamental system and platform changes that have taken place and all related issues.
  3. Design appropriate replacement technologies, structures and data flows to reflect new requirements.
  4. Review and redesign allgroup support functionality for both Microsoft Ad and all Google connected functions including email (email list membership management is a particular concern). The redesign of group structures and support procedures must be both effective and manageable going forward.
  5. Review all proposed designs with GPS and adjust as needed
  6. Installations, development and implementation of the new solution, working “side by side” with GPS staff and any GPS designees
  7. Testing, review and modification phase.
  8. Full scale testing by June 4, 2018
  9. Go live no later than July 2 2018
  10. Complete full documentation of the new solution including explanation of logic and data flows. This is due at the Go Live date July 1.
  11. This solution must allow for maximum flexibility to accommodate new requirements going forward.
  1. Systems Requirements

This section will require detailed responses, preferably line by line. Submit responses with corresponding number/letter so they can be easily identified by the committee.

  1. The solution proposed must address the Preparation & Expectations and the General Expectations listed above.
  1. The proposal should also include any available features and functions that were not specified above, but that are available as part of the solution. Only currently available systems and the latest releases of software should be proposed. Systems and/or software under development or in the planning phase will not be considered. Features that will be available only on a future release of software will be considered unavailable.
  1. Please specify whether the software can be hosted at Gilbert Schools or if it is an ASP, hosted by the vendor.
  1. If the product will be hosted at Gilbert Schools, it must be operational on any Gilbert Schools-provided computer hardware and/or network equipment without modification. The system must have an architecture that supports scaling to 45,000+ user accounts or more. The proposal must describe the infrastructure that supports the solution, including open standards and platform independence. Provide required server specifications and quantities, as well as server software and database server software requirements.
  2. If the product is available as an ASP, all features of the identity management system must be operational on any Gilbert Schools end-user workstation without significant modification. The system must have an architecture that supports scaling to 45,000+ user accounts or more. The proposal must describe the infrastructure that supports the solution, including open standards and platform independence. Please provide a copy of your Application Service Provider (ASP) Web Hosting Service Level Agreement.
  1. The proposal must address how the project will be conducted and managed. A narrative description of the approach and a detailed project plan are required. Gilbert Public Schools reserves the right to employ and third party to represent GPS as project managers if it should choose to do so.
  1. At a minimum, the project plan must include a milestone chart including tasks (for all phases of the project) to be performed, the timeframe and proposed staff member(s) designated for the completion of each task.
  1. All programming, database schema and scripting fully documented
  1. All support and administration processes fully documented
  1. User self-service portal including password management.
  1. Possible optional user resource request management, include pricing for this functionality
  1. There will be a requirement for administrative utility functionality for manually creating, modifying and suspending user accounts. This process must take place without disrupting underlying functionality.
  1. There is a need for exporting user information files for external use. This should include basic formats for export such as CSV or Excel file format.
  1. The ability to search and report on any available attribute fields
  1. Delegated role based administration. Example - designated personnel at campus sites should be able to look up and reset student usernames and passwords through a web portal interface.
  1. Tight integration with both Google Apps and Microsoft AD. Google apps passwords and account characteristics synchronization is a requirement.
  1. Change processing should occur in a timely fashion. Event driven, real time process is preferred (batch driven process is second choice). Efficiency and timeliness of processing is an extremely important consideration
  1. Encrypted password storage for all systems at all locations, not reversible.
  1. Auto-creation of all standardized users from HR and SIS data (i.e. campus assignments, group memberships and al additional required characteristics)
  1. Auto-creation of staff and student groups from HR and SIS data (i.e. campus assignment and group creation by section numbers)
  1. Ability for manual entry of user accounts that are not tied to employees or students. (i.e. generic accounts, test accounts, possible external parent accounts)
  1. Auditing requirements. The solution must provide an audit log that records all changes to the systems including the originating system or person implementing said changes.
  1. Multiple systems interface capabilities supporting Microsoft, Google, and Linux integrations, ADFS, Secure LDAP, SAML, Google Apps for Education, manual file and batch based export of CSV and similar format files, MS SQL based connection (ODBC).
  1. It will very likely be necessary to redesign, re-engineer and reconstruct interfaces between our new systems and Google’s systems.
  2. These individual integrations must be customizable and adaptable to future requirements
  1. System must have the capacity to expand and be customizable using schema extensions if necessary. (one example would be the GPS SuperKey).
  1. Any and all programming code, scripts, queries, processes and related work product developed during this project will become the sole property of Gilbert Public Schools. Full documentation detailing the operation, maintenance and update of these functions must be included.
  1. All deliverables are due at the time of go live, July 2, 2018
  1. User Account Lifecycle Management
    Personnel changes entered into the HR/SIS system will drive a process where the users account is created/modified/suspended/end-of-life.
  1. Creation process:
  2. This will start by the generation of a unique (algorithm based) new user account name, user email address and creation of user accounts for appropriate systems. These must be created in the appropriate logical location (site) designated.
  3. User home drives must be created on the appropriate systems for the appropriate site locations. Passwords will be assigned, initially based on a predefined algorithm.
  4. User will be added to the appropriate groups for managing security, email list memberships and access to appropriate application software. These group memberships will be based on site designation, employee type designation and employee role (title).
  5. The user account will also be populated with all appropriate additional information such as employee ID, additional assigned site information, phone numbers and other contact information and any other information determined to be appropriate.
  6. The existing GPS system includes the creation, assignment and use of an additional attribute known as the “superkey”. This is a unique identifier that permanently stays with the user in question, even if associated accounts are deleted and recreated. This was a necessary step to ensure identification of a user account across multiple systems that may use overlapping user numbering schemes. It is likely that this will be needed going forward and must be addressed in your response. This may be thought of as an alternative to the social security number as a unique user identifier. This needs to be able to be generated either by GPS or by the platform.
  1. Modification process: This process must be able to complete on an automated basis. Basic user information changes such as the following:
  2. Movement or reassignment of user to an alternate work or school site
  3. Name changes due to marriage, divorce or other life event
  4. Promotion of position or advancement of grade levels
  5. Student grade level promotion; etc.
  6. Changes must include account characteristics and status changes. If the user moves to an alternate site the users account, information and home drive are to migrate and "follow" the user to their new location. The user’s group memberships must be modified appropriately.
  7. Changes of this type will also be populated throughout all connected systems.
  1. Utility Support for modification process: Individual attributes must also be modifiable in an interactive fashion through an admin utility that updates appropriate fields in connected databases. Examples of this would include changing a email address or login name to reflect a nickname or other alias that is determined to be appropriate.
  1. Suspension process: When a user’s account is no longer required it must be disabled or suspended.
  1. The user’s data should be moved to "departed users" location.
  2. The account should be placed on a timer for deletion after a predetermined period of time. User names also will not be reused for a predetermined time period, at least three years.
  1. Security Processes:
  1. User password changes and resets must be processed on a real time, priority basis to all connected systems.
  2. User account suspension or disablement must be processed on a real time, priority basis to all connected systems.
  3. If the employee is placed on long term leave, is suspended or terminated the user account will be acted upon with priority to suspend and disable the account. Personnel accounts for users who have left the district will be disable but not deleted for a predetermined period of time.
  1. The solution should interface with the following systems, but should not be limited to:
  2. The Infinite Campus student information system
  3. Infinite Visions HR and financial management system
  4. Microsoft active directory structures
  5. Microsoft and Linux based application systems
  6. Google applications and Google applications for education including the Google mail system
  7. Microsoft and other SQL databases utilizing ODBC
  8. Secure LDAP interfaces
  9. Flat file text exports utilizing CSV and other file formats for batch processing or manual import and export processes.
  1. Scalability. The proposed solution must be scalable to support increased school sites and user counts. Please describe scalability and the process of expansion to accommodate for additional needs.
  1. Roles within the solution. There should be different types of roles that can be granted to different types of users.
  2. A role for System Admin who can do everything he/she needs to do within the solution.
  3. A role for Support who can change attributes and locations manually, change passwords, manage groups etc.
  4. A role for site based staff who can manage groups and/or reset passwords.
  1. Single sign on solution for external applications would be desirable, please identify supporting features if you offer a single sign on solution.
  1. Groups. We have over 23,000 groups. Approximately 200 are logically created and maintained with user attributes. Another 1000 groups are maintained by hand and membership is not logically based. 20,000 groups exist based on class/section information. A few of these groups are very large, over 35,000 members.
  2. The solution should allow for logical creation and maintenance of groups.
  3. The solution should allow for manually maintaining groups by support staff.
  4. The solution should allow for exporting of group members into a .csv file
  5. The solution should allow for unsophisticated end users to create, update, approve, and delete group memberships without using Google’s interface or Active Directory tools.
  6. The solution should allow for specific users to maintain specific groups, not the ability to change all groups.
  7. The solution should allow for multiple group changes, deletions, and updates at once.
  8. The solution should be able to “synchronize” or “reconcile” group memberships in G-Suite, Active Directory, and the solution. Removing users from G-Suite groups when they are no longer in Active Directory and solution groups. The solution should allow for reporting on the number of groups, their members, and comparison with other connected systems (G-Suite group memberships, Active Directory group memberships, solution group memberships).
  9. The solution should allow for creating and maintaining owners, managers, and members of groups in G-Suite. Other permissions like whoCanPostMessge and whoCanViewGroup will be controlled from the solution, not by using the G-Suite tools.
  10. The solution should allow for calling out to PowerShell or Python to make custom scripts to interact with Active Directory and G-Suite.
  11. The solution should allow for maintaining groups by logic within the solution, by hand via support staff, by hand via unsophisticated end users, and programmatically via PowerShell and Python.
  12. Additional requirements
  1. Training:
  1. Training shall be provided for systems administration and support personnel and for programming personnel. This shall be detailed certification level technical training or equivalent. This will be included for a minimum of three persons that GPS shall designate.
  1. Training shall be provided for systems programming personnel. This shall be detailed certification level technical training or equivalent. This will be included for a minimum of three persons that GPS shall designate.
  1. User level training. Materials shall be provided to support training for users who must interact with these systems. For example clear documentation or video presentation of usage of the self-service password reset portal.
  1. Services: This section will require detailed responses. Submit responses with corresponding letter/number so they can be easily identified by the committee.
  1. Continuing technical support. The process for initiating a support call, hours of support and maximum support time should be described in detail.
  1. SLA – Describe the expected uptime and SLA for your solution if ASP
  1. Platform: This section will require detailed responses. Submit responses with corresponding letter/number so they can be easily identified by the committee.
  1. If the proposed solution is “district hosted” the Offeror must specify all hardware requirements necessary to run the software being proposed. Although hardware cost may not be a part of this response, the Offeror must define, in detail, the hardware platform and system architecture required to robustly implement its solution. The Offeror must define its overall approach to hardware implementation and scalability. If the proposed solution is “vendor hosted” (ASP) hardware specifications will not be a required part of your response.
  1. The Offeror must define the recommended, not minimum, requirements to support its proposed solution. The proposed software must be scalable to provide expandability and growth to the District as a whole. The proposed software must function in the District’s existing environment. Workstations will be operating over a high speed Ethernet switched VLAN routed wide area network.