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

You can set which database is queried when a user logs in at the role level in Constituent Manager.

  1. Open Constituent Manager and click the "Settings" button at the upper-left, then select the second menu item, "Constituent Roles"

  2. Select the role you want to configure

  3. Find the dropdown menu labeled "Authorization." This menu will be populated with any integrated databases configured to work with your site, as well as "Finalsite"

    Use the Authorization dropdown menu to identify which database will be used to check users’ login credentials.

  4. Choose the appropriate database that should be queried to authenticate users of this role. When role members login, the username and password they enter will be checked against the selected database

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.