Aeon Exclusive: Authentication Process & Customizing Settings

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. The UserValidation table is accessible from the Aeon Customization Manager under Web Interface | Authentication. This allows staff to make any minor corrections to the table or add an individual user. For adding large numbers of users to the UserValidation table, though, staff should use an automated script to import an exported list into the UserValidation table on a database level. While it is technically possible to also allow users to self-register, it is generally removed as an option in order to limit access. Staff can add users through the client and set their authentication to Aeon Authentication. Setting the WebAuthType to Aeon Exclusive sets the Users.AuthType value to Default.

Adding Users to the UserValidation table

You will first need to upload the text file to your Aeon SQL Server for importing. If your server is hosted, contact Atlas regarding sending the file for import. The rest of these instructions pertain to only self-hosted servers with access to their own SQL Server. Once the file is in place, you would then browse the SQL Server Management Studio under Databases | AeonData and right-click on the database to choose Tasks .. Import Data.

Then, follow these instructions:

1. A Data Transformation Wizard will open.
2. Choose your Flat File Source as the source. Make sure that the file is delimited (separated by a character, usually a comma).
3. Verify the file format and column delimiters. There should be a preview pane below.
4. Set your source to your local SQL Server by filling out the Server name, authentication, and database.
5. The next screen should show your source as the text file and the destination. You will need to change the Destination from the default table name to UserValidation by clicking in that field and choosing it from the drop-down.
6. Click Next. You will want to run this immediately, but will also want to check the box to *Save an SSIS package for later execution*. It defaults to saving the package to the SQL Server. The schedule should be changed, or else it will run every day at midnight. It assumes that the text file will be in that same location each time, so be sure that you put the text file in a location where you'll be able to FTP it in the future.
7. Click Next. Give the package a name if you chose to create one (i.e. UserValidation import for Aeon).
8. Click Next. Review the import in the final form. It should be going from a flat file to a SQL Server table. Click Finish to import the file and schedule the job.

For example, if you wish to limit access to Aeon to only those users who have a library card, you can import a list of those library cards into the UserValidation table where the library card is the username. If you would like to import other information about those users (name, address, contact information, etc.) you can do that as well.

Usernames and Passwords for UserValidation

If your patrons are going to authenticate through the use of the UserValidation table, you will need to configure the username requirements and temporary initial password for your patrons. It is technically possible to not use the password field and leave that blank but is not recommended for security and privacy issues.

Usernames- The username patrons would enter when logging into the patron web pages would go in the Username field of the UserValidation table. This field must be unique across the entire database. If your list of users to import has duplicate entries, you will get errors trying to import those users into the UserValidation table.

Passwords- The password value can be implemented by entering the password for all users into the PlainTextPassword field of the UserValidation table. This field is used only for the initial registration of new users to compare to the value the new customer types in and is no longer used for future logins. 

Example

For example, if you would like all Aeon customers to use their library card as their username and their last name in all lowercase as their password, you can enter those values into the UserValidation table. The Username field would be 123456789 if that is the customer's library card number and the PlainTextPassword field would be "smith". Note that while you are using the customers' last name as his password, you would want to enter that value into the PlainTextPassword field and not the LastName field. Any other information you wish to pre-populate can be entered in UserValidation as well (FirstName, LastName, Phone, EMailAddress). Because you are using the PlainTextPassword field, the Password field in UserValidation would be blank. 

When John Smith first attempts to use Aeon, he would type in his library card number and his last name into the username and password fields on the logon form. He would not need to click on a First Time Users link to register. Aeon first checks if the username 123456789 exists in the Users table. If not, it then checks if the username 123456789 exists in the UserValidation table. That username is found, so Aeon then checks if the encrypted value of "smith" matches the value in the Password field of UserValidation. It doesn't match (because the Password field is blank), so Aeon then checks if the value of "smith" matches the value in the PlainTextPassword field of UserValidation. That value matches so John Smith's username is added to the Users table with an encrypted version of "smith" stored in the Password field of the Users table. John Smith is then directed to the NewAuthRegistration.html page to fill out any other necessary information for his user account. If other fields were populated in the UserValidation table, those values would appear on the registration form.

After registering, if John Smith returns to the Aeon web, he would again enter his username of 123456789 and his password of "smith" on the logon form. Aeon would verify that 123456789 exists in Users as well as verify that 123456789 still exists in UserValidation. It would no longer verify the Password or PlainTextPassword fields in UserValidation, but would verify the encrypted value of what John Smith typed in with the encrypted value stored in the Users table. As long as John Smith has not been disavowed by staff in the client, he is then allowed to login to the system.

Setup 

For Aeon Exclusive authentication, the WebAuthType key in the Customization Manager (Authentication | WebAuthType) should be set to AeonExclusive. Customers could technically reset their passwords after registering with the system, but it may not follow with your model of known usernames and passwords (i.e. library card and last name). 

Overriding Aeon Exclusive Authentication

Sites using Aeon Exclusive authentication may want to create a dummy user to test their web pages or may find it necessary to occasionally allow a user who is not in the UserValidation table to access the web pages. You can do this by using the Aeon Authentication checkbox in the User Information form to override Aeon Exclusive authentication with Aeon authentication. Checking the Aeon Authentication checkbox or the User Information form overrides the WebAuthType key setting of AeonExclusive for that user and changes the Users.AuthType field from Default to Aeon. In order for this to work, the user should not be included in the UserValidation table.