BASIS Card Access Agreement v1.0 Introduction This document describes the agreement between the Department of Computer Science and Engineering (CSE) and units who wish to take advantage of CSE's BASIS card access infrastructure. The goal is to minimize the potential for misunderstanding by clarifying past discussions. This is not meant to be a legal document - some use of common sense and trust between the parties is required. Described briefly, the objective is to provide a common card access service for the constituent units at a lower cost than the units would be able to obtain individually. This can be done by administering the common infrastructure (databases, server hardware, licenses, support contracts, etc) from a single location, but splitting the costs proportionally based on the number of devices a unit owns. CSE has built integration features into their implementation that would be difficult for other units to maintain, but are highly desirable, making CSE a logical crystallization point for such a collaborative effort. Description of Card Access Architecture Before describing the different responsibilities and services, it is important to understand the card access terminology and design that is used. The software used to do the access control administration is called BASIS from Best Access Systems. It is composed of a database, a license server, a communication server, and a client tool. The database is implemented as an Oracle database on a Solaris server. The license and communications servers run on a Windows 2000 server. The client tools are run on any Windows workstation. To interact with the BASIS system you must have the client installed, have a username and password in the database, and a client license must be available for you to use. The hardware architecture is described as a "networked" card access system. The communication server described above communicates over the IP network to an "access panel," which is connected to one or more "reader panels" via a serial line. These reader panels connect to the door or elevator control systems and card swipe readers. Typically, one access panel is installed in a building, and many reader panels are attached to it. Administrative control in the software is granted at the access panel level, which means that two units may share an access panel, but BOTH would be able to manipulate access rights on the associated readers. Services and Responsibilities CSE administers the hardware and software related to the license and communication servers and the database. Backups are made of the database on a nightly basis in case of catastrophic failure - this is not an undo command, but simply a point-in-time snapshot of the entire state of the card access system. CSE administers the licenses and support contracts involved with the system, coordinates billing with members, and provides a liaison function with Best Access when needed. CSE develops and maintains the software needed to support the integration with campus administrative systems, allowing automatic access grants and revocations based on rules designed by the member units. Finally, CSE assists the member or prospective member to assess their card access needs and to assist in basic training. Members are responsible for the costs associated with the purchase and installation of new equipment. They are also responsible for their share of the annual support contracts and license upgrades that are needed to keep the service functioning properly. These shares are determined by the number of access control points (card readers) that they own in relation to the total. For example, if CSE owned 25 of the 50 readers associated with the system, they would be responsible for 50% of the annual costs. Because client (administrative GUI) licenses are in a "pool" that is shared between all of the members, the applications cannot be left running all of the time. If they are no longer needed, the applications should be shut down, allowing that client license to be allocated to someone else. If growth in the system warrants an increase in the number of client licenses, the upgrade will be paid for proportionally by all members as described above. The member unit who owns the equipment (access panels, door locks, etc) is responsible for any service, upgrade or repair costs of that equipment, with the following caveat. The member units may agree to purchase "blocks" of support time at a discounted rate from Best Access, and those blocks would be applied to any service calls. In this case, member units would still be responsible for the replacement hardware costs, but labor would be covered under the support contract. New Members Adding new member units to the service must be done in an equitable way. The startup costs would include paying their "share" of the annual costs with their readers added into the total, prorated based on the amount of time left on the existing contracts. For example if there were 40 readers in the system before unit X started and they added 5 of their own, on an annual basis their percentage of the fees would be 11%. If there were 6 months left before the annual support and licensing contracts were renewed this would be prorated by 50%, leaving them responsible for paying about 6% of the total annual fee. Of the "founding members," CSE has contributed the basic infrastructure, the School of Medicine has paid for the license upgrades for the BASIS server and the programming API, the School of Nursing has paid for a client license, and the School of Health Related Professions has paid for a client license. Leaving the Service If a member wishes to leave the service they can do so at any time, but under the following constraints. Licenses are not transferable, and so they will need to contact Best Access to obtain the needed server and client licenses, and identify a server to run the software. The equipment that they own will need to be reconfigured to use this server. The annual fees are not refundable, however if a service contract is in effect the member unit will continue to be able to use it for the duration of that contract year. $Id: cardaccess.agreement,v 1.2 2003/02/06 20:12:52 stock Exp $