Authentication priority for multi-role users

For sites that integrate with a remote database, you can specify whether users in a specific role should have their login credentials authenticated against the remote database, or against Finalsite's own cache of usernames and passwords. In some cases, users with more than one role applied to their account ("Parent" and "Alumni," for instance), those roles may be set to authenticate against different databases. This article will explain how to handle such situations, and how conflicts are resolved.

Configuring authentication for individual roles

To configure the authentication method for each role, go to Integrated Services Manager > Authentication, then choose the authentication you want to use from the list on the left. Once on the authentication settings screen, choose the "Role Settings" button.

To add a role to this authentication, click the "Add Role" button. Select the role you want to have available for this authentication, then click "add." The role will be added to that authentication type and automatically enabled. 

Note: A role can only have one authentication type, so adding it to one list will remove it from any other authentication that is currently enabled for that role.

If you disable a role's authentication setting by selecting the green checkmark, the role will default to Finalsite authentication. This can be useful if you need to revert to cached passwords in case of a third party outage, for example.

Authenticating multi-role users

Continuing the above example, imagine a single user who's assigned to both the "Parent" and "Alumni" roles. The "Parent" role is configured to authenticate against an integrated remote database, while "Alumni" constituents are authenticated to the finalsite cache of user credentials. When our dual-role user logs in, which database is used to check their credentials?

The answer is: both of them. The username and password will be looped over both authentication methods based on the authentication sequence that's set on each of the databases. If the first database checked authenticates the user, then the process stops and the user is logged in. If the first database doesn't authenticate the user (either because it doesn't have a record for that person, or just because the username/password do not match stored records), then the system will check the next database on the list. If that one fails, it proceeds to the next database and so on, until either the user is authenticated, or all databases are checked and none pan out. You can control the order in which the various databases are checked by using the "Sequence" setting in the Integrated Services Manager (see below).

To set the authentication sequence of your integrated databases,

  1. Open Integrated Services Manager and click the "Authentication" tab

  2. Choose a specific integration database (this example uses "LDAP," but your school might use a different remote database)

  3. Find the field labeled "Authentication Sequence" and enter a number from 1-99. Be sure to use a different number for each separate integration!

    A view of the Authentication Settings page

  4. When multi-role users login, the integration with the lowest sequence number will be queried first. If the user's credentials cannot be found in that database, the system will query the integration with the next-highest number, until the credentials are authenticated, or the user login fails on all databases.

Note: "Finalsite" is set by default to be authentication sequence 99. The first integration added to finalsite will automatically be assigned a sequence number 1. If you then add another authorization type it would be assigned authorization sequence 2, and so on. You can modify the authorization sequence for "Finalsite" if you wish, but we do not recommend changing it from the authorization sequence of 99. The remote authentications should be checked first, as this is where most authentications will be successful.

This cascade from one database to another will only occur if the user who's logging in is assigned to more than one role. If they are a single role constituent, then their credentials will only be checked against the authorization type specified for that role (see above). The login process will not cascade like it would for multi-role constituents.

Was this article helpful?
1 out of 1 found this helpful



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