Attachment_2_Statement_of_Work_0001.pdf

STATEMENT OF

WORK

ACCESS CONTROL & IDENTITY MANGEMENT SYSTEM

(Keyless Entry System)

The following services to be provided for:

Riverside Indian School (RIS) 101 Riverside Drive, Oklahoma, 73005

Purpose:

The contractor is to provide all labor, supervision, parts, equipment to install a keyless system operational at the front gate entrance, all campus buildings, including administration, dormitories, cafeteria, gym, student recreation, and offices.

Location:

Riverside Indian School Campus

Conditions:

All work shall be coordinated with the COR and Facility Manager or his/her authorized representative.

Description of Service:

ACCESS CONTROL & IDENTITY MANGEMENT SYSTEM

IDENTITY MANAGEMENT SYSTEM (IMS)

The Access Control System (ACS) shall be fully embedded as part of a single Identity Management System (IMS). The IMS shall be an enterprise class IP-based software security platform.

Available native functionality within the IMS must include:

Server Software Module (SSM) Configuration Interface Access Service Integration Service Client Software Application (CSA) Microsoft Active Directory Sync Service (ADSS) Visitor Management ID Badge Design ID Badge Production (Onsite & Offsite)

GENERAL

The ACS shall be an enterprise class access control software solution. It shall be fully embedded within a single Identity Management System (IMS).

The ACS shall be capable of performing and integrating multiple security functions including the configuration, management and monitoring of cardholder access, hardware units (controllers), events, alarms, as well as real-time tracking and reporting. The ACS shall be highly scalable and include provisions for future growth.

The ACS shall be based on an open architecture Mercury platform and support multiple access control lock hardware manufacturers. The ACS shall be able to integrate with multiple non-proprietary interface modules, access readers, and other third-party applications.

SYSTEM ARCHITECTURE

The ACS shall be based on a client/server model. The ACS shall consist of a Server Software Module (SSM) and Client Software Applications (CSA). The ACS shall be both a multi-user and a multi-tasking environment.

The ACS shall support the installation of the SSM and CSA on the same machine. Conversely, the ACS shall support a distributed environment where the SSM and CSA can be installed across unlimited PCs over an IP network.

CSA's shall ping the SSM and check for updates. If updates are available, the CSA shall install the update without action from the user. Upon installation, the IMS will publish CSA's as an available installation program over the network. No CD shall be required to install a CSA at a remote PC connected to the network.

The ACS shall be an IP enabled solution. All communication between the SSM, CSA, and hardware controllers shall be based on standard TCP/IP protocol.

SYSTEM DESIGN GUIDELINES

The ACS shall be designed to run on a standard PC-based Windows server platform.

The ACS interface shall be easy-to-use and minimize the number of external applications required to configure and monitor the system. The user interface shall consist of a single configuration client interface and a single live monitoring client interface.

The ACS server modules shall be compatible with multiple 32-bit and 64-bit operating systems including any of the following Windows Server 2008 R2, Windows Server 2012, Windows Server 2012 R2, and Windows Server 2016.

The ACS client and management modules shall be able to run on all networkable versions of the following platforms: 32- and 64-bit versions of Windows 7, Windows 8, Windows 8.1, and Windows 10.

The system database server(s) shall be built on Microsoft SQL Server 2008 R2, 2012, 2014, and 2016 including Express versions.

SYSTEM SCALABILITY AND CAPACITY

The ACS shall be capable of supporting a wide range of configurations. The ACS shall be capable of supporting access control configurations that consist of a single door and one reader to a configuration consisting of a multitude of doors with facilities spanning multiple geographic areas.

The ACS shall support an unrestricted number of controllers and interface cards.

The ACS shall permit multiple instances of Client Software Applications (CSA) to run simultaneously on the network. The number of instances of CSA shall only be limited by the number of available application licenses.

The ACS shall support an unrestricted number of logs and historical transactions (events and alarms) with the maximum allowed being limited by the amount of hard disk space available.

SYSTEM SECURITY

The ACS shall limit what users can view in the configuration database via campuses (database segments). The administrator, who has all rights and privileges, shall be allowed to segment a database into multiple campuses. Users who are given access to a specific campus shall only be able to view entities within the campus they have been assigned.

SERVER SOFTWARE MODULE (SSM)

The SSM shall be fully embedded as part of the IMS.

The SSM shall be responsible for receiving, processing, and responding to requests from the CSA's and notification to CSA's of available updates.

The SSM shall support installation in a distributed environment with the application tier and database tier on separate servers.

The SSM shall be capable of running completely in a virtualized environment without third-party software.

The SSM shall automatically launch at computer start up, irrespective of whether a user is logged onto the machine or not.

CONFIGURATION INTERFACE

The Configuration Interface shall be fully embedded as part of the IMS.

The Configuration Interface shall be the central point of configuration for all the system information and component setup.

The Configuration Interface shall support the configuration / management of the following components and workflow:

Users Door Controllers (hardware units) Doors Schedules (Including Holiday Schedules) Access rules Cardholder Groups Lockdown Functionality Event Notification Service Alarms Conditions Users & User Groups Scheduled Tasks Custom Events Custom Output Behavior Custom Fields Toggle Functionality QuickPass Functionality

The Configuration Interface shall be able to run on the same server as the SSM or installed remotely on a separate PC.

The Configuration Server shall authenticate users and give access to the ACS based on predefined user access rights and privileges or through the direct integration with Microsoft Active Directory via the Active Directory Sync Service (ADSS).

ACCESS SERVICE

The Access Service shall be fully embedded as part of the IMS.

The Access Server shall be the server that synchronizes all hardware units under its control. The Access Server shall also be able to validate and log all access activities and events when the controllers are online.

The Access Server shall maintain the communication link with the hardware controllers under its control. It shall also continuously monitor whether the controllers are online or offline.

Synchronization of hardware units shall be transparent to users and shall occur in the background.

If communication is lost between the controller and the server, the system shall continue to function at its last downloaded capability and store a minimum of 250,000 transactions in the buffer. Once communication is restored, the records shall be uploaded to the server so that no transactions are lost.

The Access Server shall support doors and controllers located within one or more facilities.

At system start up, the Access Server shall load all the configuration information that is applicable to the units under its direct control.

The Access Server shall store all access events associated with the doors and controllers under its direct control.

INTEGRATION SERVICE

The Integration Service shall be fully embedded as part of the IMS.

The Integration Service shall enable the connection and data synchronization of the IMS to the following types of external systems:

Directory File Monitor and Parsing Direct ODBC Connection TCP/IP Connection Direct SQL Database Connection

The Integration Service shall support multiple data connections executed in sequential order to accommodate consolidation of identity information from multiple databases into one single IMS.

The Integration Service shall be able to run on the same server as the SSM or installed remotely on a separate PC or server for optimized performance.

CLIENT SOFTWARE APPLICATION (CSA)

The CSA shall be fully embedded as part of the IMS.

The Client Software Application (CSA) shall provide the user interface for Credentialing, Privilege Management, Activation/ Deactivation, Visitor Management and Monitoring. The CSA shall be Windows based and provide an easy-to-use graphical user interface (GUI).

The CSA shall perform functions without interfering with any of the Access Service operations (for example, responding to access requests, logging ACS events, etc.).

The CSA shall support multiple forms of IP network connectivity, including LAN, WAN and VPN technologies. The CSA shall be able to log into the ACS from a remote site.

The CSA shall provide an authentication mechanism, which verifies the validity of the user. As such, the administrator (who has all rights and privileges) can define specific access rights and privileges for each user group in the system.

Logging into a CSA shall be done either through IMS user accounts and passwords or using the operators’ Windows credentials when Active Directory authentication is enabled.

HARDWARE COMPATIBILITY LIST (HCL) OVERVIEW

The ACS shall interface with Mercury powered, IP-enabled hardware access controllers, and interface modules.

The ACS shall have used the open architecture Mercury platform that supports the integration of third-party IP-based door controllers. Through these door controllers, the ACS shall interface with industry standard access control readers.

The ACS will support mixed configurations of Mercury hardware devices and lock hardware.

Examples include:

Single PoE-enabled Controllers 2 reader Controllers Wireless locks (Including Aperio, NOE, LE, AD400) Monitoring Devices

MICROSOFT ACTIVE DIRECTORY SYNC SERVICE (ADSS)

The ADSS shall support a direct connection to a Microsoft Active Directory server. Active Directory integration shall enable the synchronization of information from the Active Directory server to the IMS.

Active Directory integration shall permit the central management of the IMS users, user groups and cardholders. When enabled, Active Directory shall manage user log on to the CSA's through the user's Windows credentials. Log on to the CSA shall utilize native Active Directory password management and authentication features.

It shall be possible to synchronize the following IMS entities and their information from Active Directory to the IMS:

Users (user-name, first and last names, email address, and more) User groups (user group name, description, and group email address) Cardholders (first and last names, description, email, and more) When enabled, the addition, removal, or suspension of a user's account in Active Directory shall result in the creation, modification, or disabling of the equivalent user account in the IMS as well as removal of the individual's name as a person able to be visited in the Visitor Management System.

When enabled, the addition, removal, or suspension of a user's account in Active Directory shall result in the creation or disabling of the equivalent cardholder account in the IMS.

System Supported synchronization methods for additions, modification, and disabling of synchronized entities shall include:

Manual synchronization Scheduled synchronization

USER AND USER GROUP MANAGEMENT

The ACS shall support the configuration and management of users and user groups. A user shall be able to add, delete, or modify a user or user group if he has the appropriate privileges.

Common access rights and privileges shared by multiple users shall be defined as User Groups.

Individual group members shall inherit the rights and privileges from their parent user groups.

IDENTITY & CREDENTIAL MANAGEMENT

The ACS shall support the configuration and management of credentials, i.e., access cards and keypad PIN numbers. A user shall be able to add, delete, disable, or modify a credential if he has the appropriate privileges.

The ACS and badging system must be fully integrated together. If a user is re-issued a credential, their old badge must be automatically deactivated in the ACS system as soon as a new badge is issued.

The system must offer a badging interface to read smartcard and Mifare card numbers into the database during the badge issuance process, eliminating a manual card number enrollment process.

User shall be able to add Custom Fields (user-defined fields) to credentials. Creating a new credential shall be accomplished either manually or automatically.

Automatic creation shall allow the user to create a credential entity by presenting a credential to a selected reader. The ACS shall read the card data and associate it to the credential entity. It shall be possible to automatically enroll any industry standard card format.

A downtime offline solution for printing credentials shall be offered to allow personnel to send a print job directly to a cloud-based print service if needed.

Manual creation shall allow the user to select the type of credential to create and to enter the data manually.

A custom card format feature shall allow the administrator to add additional custom card formats using an intuitive tool within the Configuration UI. The custom card format tool shall be flexible in the following ways:

Once enrolled, new custom card formats shall appear in the card format lists for manual card enrollment.

An unrestricted number of additional custom card formats can be added.

Batch enrollment of credentials shall be supported.

BADGE DESIGNER

The badge Designer shall allow the creation of multiple badge templates that define the content and presentation format of a cardholder badge to be printed.

Badge template shall be related to entity type.

Badges production shall be capable of printing to one or more printers located locally or on the network and printing shall occur automatically based on rules defined within the IMS.

Badge production shall consist of selecting the credential or entity type, the badge template (when applicable), and clicking print.'

Badge designer software shall be capable of designing badges for all entity types (card users, employees, contractors, visitors, etc.) within the same location.

The contents of a badge template must include:

The cardholder's first name The cardholder's last name The cardholder's picture Custom fields Bitmap graphics The name of the cardholder's credential Lines and rectangles Dynamic text labels linked to custom fields Static text labels Barcodes (Code 39, Code 128, PDF417, QR, EPIC and others)

Copy and paste of badge template objects shall be available from one design to another.

It shall be possible to set the border thickness, border color, and fill color of badge objects (content). It shall be possible to set the color of text labels.

It shall be possible to easily reorder the layer levels (bring forward, send to back, etc.)

Settings such as object transparency, text orientation, and auto-sizing of text shall be available or transparent to the user.

Standard portrait and landscape badge formats, custom card sizes and dual-sided badges shall be supported.

A badge template import, and export function shall be available to allow the sharing of badge templates between distinct or independent ACS.

Fields must be interchangeable between static and dynamic.

Fields (including custom fields) and information must be automatically pulled from the IMS database.

DOOR MANAGEMENT

The ACS shall support the configuration and management of doors. A user shall be able to add, delete, or modify a door if he has the appropriate privileges.

The ACS shall permit multiple access rules to be associated to a door. The ACS shall support the following forms of authentication:

Card Only Card or Keypad (PIN) Card and Keypad (PIN)

In/Out The ACS shall support in/out functionality. When an "out" situation is detected, an associated "out" event shall be triggered in the ACS.

The ACS shall have reporting capability of an "onsite list". In the event of an emergency, the onsite list shall be easily printable or emailed for the purpose of verifying who may still be left inside the building.

The ACS shall track people using the card readers within the building to actively show the last location a person passed through. The ACS shall track visitors who are issued credentials in the same manner.

SCHEDULE MANAGEMENT

The ACS shall support the configuration and management of schedules. A user shall be able to add, delete, or modify a schedule if he has the appropriate privileges.

ACCESS RULE MANAGEMENT

The ACS shall support the configuration and management of access rules. A user shall be able to add, delete, or modify an access rule if he has the appropriate privileges. readers), area. It shall be possible to create and unlimited number of access rules per door, area, or elevator floor.

Access rules shall determine whether a cardholder or cardholder group shall be granted or denied access based on a schedule. Once an access rule is created, the user shall associate the access rule to a door side, door, area, or elevator floor.

It shall be possible to program an access rule throughout the entire system.

An access rule shall be assignable to multiple door controllers. Separate access rules shall not be required if the same rule applies to several independent controllers.

The ACS shall support the viewing and/or configuration of the following properties for an access rule:

Access rule name Access rule description Schedule when the rule is active

Permissions when rule is active (grant or deny access) Cardholders and cardholder groups affected by the rule

REPORT GENERATION

The ACS shall support report generation (database reporting). Quick access to all current reports shall be possible through web links.

The ACS shall support both static and custom reports. Report generation shall not result in any degradation of system performance.

Reports shall be fully web based and accessible to the network.

SCHEDULED TASKS

The ACS shall support scheduled tasks. Scheduled tasks shall be executed on a user-defined schedule at a specific day and time. Recurring or periodic scheduled tasks shall also be supported.

Scheduled tasks shall support standard actions available within the ACS such as sending an email or creating a delimited text file.

CUSTOM FIELDS

The ACS shall permit the creation of custom fields. Unlimited custom fields shall be supported.

CARD READERS

Multi-technology card readers are required. Supported card formats should include MOCA, BadgePass, Schlage, XceedlD, MIFARE, HID Proximity protocols, HID iClass, GE/CASI, Proxlite, AWID Proximity, LenelProx, etc.

Reader must have A read range of up to 4.5" or better Environmental protection for indoor or outdoor placement Security Key Management UL Listing Mullion mount available· Mini-mullion sizes (smaller read range), where approved for install Readers must be PIV compliant.

GENERAL CODES AND STANDARDS

All work shall comply with the applicable codes and standards as issued by NEC, ANSI/EIA/TIA, BISCI, IEEE, UL and NFPA.

The complete system installed at each location shall meet all applicable Fire Codes for exiting the building.