Ares has 5 components working to keep your reserve desk running smoothly:

• Web site for faculty and students to submit, organize, and retrieve reserve materials.
• Windows client for reserve desk staff to manage the entire life cycle of a reserve item.
• Web-based administration suite to manage all system configurations and Ares staff accounts.
• System Manager service that performs routine system maintenance such as updating copyright permissions and cleaning up reserve items.
• Web-based reporting module to procure an administrative view of how your reserves desk is performing.

Optional integration with e-Learning environments:

• For Blackboard Building Block users - Blackboard Academic Suite version 6.3.1.374 or later using Tomcat 5.0 and JDK 1.5.0.
• For Moodle users - Moodle version 1.5 or higher.

Authentication Back to top

Ares offers a variety of methods to authenticate patrons of the system. Some of these methods require external systems or authenticating servers; details on those requirements are within each section below. In all authentication methods, the username must be unique across the entire database and any passwords stored are one-way encrypted so that staff or database administrators cannot know the users’ passwords.

Standard Authentication

By default, all Ares installations are setup with Standard authentication. This type of authentication allows anyone with access to the registration pages to register him or herself, choose a username and password, and then use that username and password to login to the Aresweb. Users only need to register once and can update the information as often as necessary.

New customers are allowed to submit requests immediately after registering, but are marked as “not cleared” in the staff interface. Staff can then review those users and disavow them if they are not allowed to use the system (which also cancels the users’ requests) or clear them as valid users. Staff can clear customers at any point in the process.

Standard authentication does not verify user information against any external system upon registration or login. Once a customer registers with Ares he or she is allowed to login to the web interface until staff either blocks the user from submitting any further requests or disavows the user from the system.

LDAP Authentication

If your institution has an LDAP server available with potential Aresusers in it, you can use that server to authenticate any patrons. This server does not necessarily need to contain all potential Aresusers, as those who do not exist can be added through the client by staff or register themselves if given a link to First Time Users. Users cleared via LDAP are verified against the LDAP server at registration and each time they login to Ares.

Note: LDAP passwords are not stored in the Aresdatabase and are only used when typed in by the user to match against the LDAP server during registration and login. The password field in the Aresdatabase stores the encrypted version of a blank value, but is not used for any authentication.

The advantage to using LDAP is that the username and password a user enters is the same as other systems at your institution and if a user changes his or her password in the LDAP directory, that password is automatically used for Ares authentication as well. The disadvantage is that if your server loses connectivity to your LDAP server, those users cannot login to Ares because they cannot be authenticated by that external system.

RemoteAuth Authentication

If you do not want your users to enter a username and/or password to use Ares, but want to pass a known username to Ares for registration and login, you can setup RemoteAuth authentication. While there are few Ares customizations to enable this authentication, it does require technical knowledge of setting up your external authenticating system and having that server send information to the Aresweb server.

RemoteAuth authentication is slightly different than other authentication methods in that there is no logon page used for customers to enter a username and password. In most installations, sites add an ISAPI filter to the Aresweb server that intercepts the request for the web DLL in the RemoteAuth folder. If the username value has not been set, it redirects the user to the authentication server. If the username has been set, it checks the authentication server to see if the session is still active. RemoteAuth authentication expects a server variable that is set to the authenticating system and passed to Ares via the http header.

RemoteAuth authentication has been successfully used by sites with PubCookie, CoSign and Shibboleth.

PatronAPI Authentication

If you are using Innovative Interfaces as your ILS/OPAC and have purchased their PatronAPI module, you can setup Ares to authenticate users against that PatronAPI server for registration and login. PatronAPI authentication can be setup to either auto-clear customers who match entries in the PatronAPI server or to restrict access for both registration and login to the system.

Because most PatronAPI servers restrict access by ip address, you will most likely need to add your Ares web server to the list of IP addresses allowed to query the PatronAPI server.

Printing Back to top

In order to print most Ares documents used in the course of processing Special Collections requests, Ares uses a combination of document templates (Word documents) and output data files (Excel .xls files). During each print process, the data files and the document templates are merged together to create the new, complete document to be printed.

Merging of the two types of files is handled by the Ares client internally and the result is printed. You can edit the Microsoft Word template at any time to change formatting and content of the printouts.

E-mail Back to top

The Ares System Manager will send emails through whichever SMTP server is configured with Ares. All emails originate at the Ares server, enabling you to restrict SMTP access to a single IP address.