Integrated database password management and authorization failovers

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.

Note: there is a limitation that users must have logged into the website at least once in order to take advantage of this failover setup. Users who have never used their credentials to login to the site would not be able to take advantage of the failover in the event of a disrupted network connection to the database.

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.

  1. Open Integrated Services Manager and select the "Authorization" tab.
  2. Click on the name of your school's integration database (not "finalsite").
  3. Select the "Test Authentication" button, and enter a valid username and password in the appropriate fields.



  4. 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.

    Note: It is recommended that multiple user credentials are tested to rule out a problem with any particular account in the system that is authenticating the user. Typically when the network connection to the 3rd party system is down, all users authenticated through that system will not be able to log in. If only a few users cannot log in, it is most likely an issue with their account in the 3rd party system rather than with the network connection.

 

Was this article helpful?
1 out of 1 found this helpful
Have more questions? Submit a request

Comments

0 comments

Please Sign in to leave a comment if you don't see the comment box below.