EAD

Aeon can import your EAD files on the fly using an XML transform that can be customized to your institution's format. Atlas will need sample EAD files to test their compatibility with Aeon.

You can also decide how you would like requests to be initiated from EADs based on:

• Granularity: How specific are your EAD records and how does this match up to your physical collections? While Aeon has the ability to merge and clone records received as needed, you can configure Aeon to closely match your holdings, eliminating the need to clone or merge all EAD requests.
• Access: Do your patrons search the EADs before your catalog? From your catalog? The route of access will determine where you want to add an OpenURL link to Aeon from your EAD files.

OpenURL Back to top

OpenURL is an industry standard way of encoding resource metadata into a URL. Aeon supports all configurations of OpenURL and is highly customizable for different OpenURL sources.

• ILS: You will need to enable an OpenURL link from your library system into Aeon. This is how patrons will place Aeon requests without rekeying their information.
• EAD: You will need to enable an OpenURL link from your EADs into Aeon.

Authentication Back to top

Aeon 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 Aeon 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 Aeon web. 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 Aeon 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.

Exclusive Authentication

Some institutions would like to limit access to the Aeon web to a known list of users. This list can come from any external database and be imported into the UserValidation table in Aeon for the Aeon web to verify against before allowing users to register or login.

LDAP Authentication

If your institution has an LDAP server available with potential Aeon users in it, you can use that server to authenticate any patrons. This server does not necessarily need to contain all potential Aeon users, 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 log on to Aeon.

Note: LDAP passwords are not stored in the Aeon database 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 Aeon database 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 Aeon authentication as well. The disadvantage is that if your server loses connectivity to your LDAP server, those users cannot login to Aeon 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 Aeon, but want to pass a known username to Aeon for registration and login, you can setup RemoteAuth authentication. While there are few Aeon 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 Aeon web 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 Aeon web 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 Aeon 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 Aeon 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 Aeon web server to the list of IP addresses allowed to query the PatronAPI server.

Printing Back to top

In order to print most Aeon documents used in the course of processing Special Collections requests, Aeon 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 Aeon 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 Aeon System Manager will send emails through whichever SMTP server is configured with Aeon. All emails originate at the Aeon server, enabling you to restrict SMTP access to a single IP address.