Some Finalsite installations are "integrated" with another database holding account information that's used not only for logging users into the website, but also for keeping track of class schedules, grades, biographical information and other data for students, faculty members and others associated with the school. These databases are called "Student Information Systems," and integrating them with the website installation means that IT administrators need only maintain a single database, while users have only one account to access all of the school's online resources. This can be very efficient for users and site admins, but it does require a somewhat more complex network system. If you're not sure why this might be a drawback, ask your school's IT administrator how they feel about adding additional complexity to the network (hint: bring coffee and snacks.)
A key component of this network is the connection between the website and the Student Information System that allows them to pass data back and forth. Ordinarily, usernames and passwords (collectively called "credentials") are stored in the SIS database. When a user logs into the site, Finalsite takes the credentials that user types in and checks them against the SIS database to ensure that they match. This process is called "remote authentication," because Finalsite checks a "remote" system (the SIS) to "authenticate" the supplied data. An interruption in the connection between the website and the SIS then would mean that user credentials could not be checked against the remote system, leaving users unable to login.
As a backup to that sort of interruption, SIS-integrated Finalsite installations can use a procedure called a "failover" to ensure that site users would still be able to login if there were any difficulty with the connection between the SIS database and the website. The basic premise is that the Finalsite database maintains its own separate, secure cache of credentials that can be used if the connection to the SIS is unavailable (in fact, this is exactly how Finalsite works for schools that do not have an SIS integration - the site itself maintains the record of usernames and passwords*). If there is ever a disconnect between the website and the database, a site admin can set the website to "fail over" from using the SIS to check user credentials to using its own internal repository of usernames and passwords to authenticate users.
There are two aspects involved in configuring the remote authentication failover process: setting up password caching, and establishing the methods of authentication for constituent roles. Password caching simply means that the Finalsite installation maintains a separate record (or "cache") of user login information, i.e., usernames and passwords. The method of authentication describes which record the website looks to when checking whether or not credentials entered by a site user are correct: the SIS record, or the website record. This configuration process is completed when the website is first deployed.
Establishing a Failover
To setup the failover functionality, password caching must be enabled in the Authorization settings in Integrated Services Manager.
To check if password caching has been configured, open Integrated Services Manager and click the "Authorization" tab at the top of the window. You'll see the available methods of authentication appear in the left-hand menu; one of them will be "finalsite," the other will be your school's Student Information System (in this example, SeniorSystems; other examples might be LDAP, VeraCross, PCR, or something else entirely).
Click on the name of your school's SIS (not "finalsite") to display the settings. Make sure the checkbox marked "Enable Cached Passwords" is selected.
With this checkbox selected, your Finalsite installation is setup to maintain a separate record of user credentials which could be used in case the network connection to the SIS database is unavailable.
Establishing a failover
To setup a failover, use the "Authentication Sequence" field. Type a different number in this field for each authentication method. The system will step through each one in turn, starting with the lowest number, and cycle through all of the available methods to try and log a user into the site.
Imagine a site with two authorization methods, SeniorSystems and finalsite. If SeniorSystems is set to "1" in the Authorization Sequence and finalsite is set to "2," the website will default to using SeniorSystems to authorize users (because it has the lower sequence number). If the authorization against SeniorSystems' credential cache fails for any reason, the system will then attempt to authorize the user against finalsite's own credential cache. If that method fails as well, the user will receive an error message.
When the SIS database is not available
Testing the SIS connection
Before you switch from authenticating against the SIS database to authenticating against the Finalsite database, it's a good idea to test the network connection to the database to ensure that the problem really lies with that connection.
- Open Integrated Services Manager and select the "Authorization" tab.
- Click on the name of your school's integration database (not "finalsite").
- Select the "Test Authentication" button, and enter a valid username and password in the appropriate fields.
- If you encounter an error saying that the authorization failed, then you know that there is an issue with the connection to the SIS database. At this point, you can switch to using failover authentication by following the steps below.