Agiloft provides a number of methods to configure user access. The system provides integration with common authentication standards, including Google OAuth and SAML, as well as other Single Sign-On (SSO) providers. In addition, administrators can configure hotlinks and access URLs, and set up two-factor authentication (2FA). To begin configuring system access, navigate to Setup > Access.
- LDAP Access: Provides an overview of integrating Lightweight Directory Access Protocol (LDAP) with Agiloft to synchronize users, authenticate logins, and provide single sign-on support.
- Single Sign-on: Details different methods for using single sign-on with Agiloft, which is a method of simplifying user access by authenticating against a single identity source.
- Two-Factor Authentication: Describes how two-factor authentication works with Agiloft, which requires users to verify their identity using a code sent to their mobile device.
- Hyperlinks: Provides an overview of using hyperlinks to access the system, in addition to performing other actions.
- Exit and Login URLs: Details how to customize Exit and Login URLs, which determine where the user is taken when they log out or are timed out of the system, respectively.
- Restrict IP Addresses: Provides instruction on using the IP Restrictions wizard to prevent access to the system unless a user is located with in a set of whitelisted IP address ranges.
- Groups: Provides an overview of how groups work in the system, as well as how to set group permissions with the Group Permissions wizard and the Table Permissions wizard.
- Teams: Provides an overview of how teams work in the system, as well as how to use the Teams wizard.
User information—including login, password and other data—has its source in one of two places:
- Users who actively log into Agiloft will have a user record in one of the subtables of the People table. Users are generally imported, created manually, or generated through some other automated process.
- User data may also be stored in an external system, such as in LDAP or Microsoft Active Directory (AD), which is used as the master set of user information. An Identity Provider stores the user's login and password across several applications or systems.
Even if a user is authenticated through LDAP or AD, Agiloft creates a user record for them that is then used in rules and other parts of the system as if the user were a native user.
How do Users Access the System?
- There are several ways to log in:
- Through a custom login page with a login block that may sit on the corporate web site.
- Through an autologin hyperlink or button that contains a login/password and other parameters—KB name, Table, State, Search, Record ID and so on—and that may be encrypted and time limited if it is sent in an outbound email.
- Through a single sign-on method: the user is logged into a corporate intranet or web portal already, and then clicks a hyperlink that passes the user information into the system to authenticate the user without having to enter a login again.
- Through the system login page.
- The system login is generally located at: https://hostname/gui2/login.jsp. For certain servers, http://hostname/gui2/login.jsp or http://hostname:8080/gui2/login.jsp may be used.
Custom login blocks can be added to any webpage using standard HTML like this:
This will result in:
Bash Script to Generate a Login Page
The bash script file linked below will allow you to generate such a login page. Simply download the script to the Linux server and run it:
Accessing the System without a Login
Not all users are given logins, but in many cases these users still need to access the system to update records. For instance, an external user may not have a login, but they may receive an email with a hyperlink that allows them to access the system to update a service record. With email updates like these, the system checks the user's email address and tries to match it to a record in the People table to find the user's login. If the system does not find a login or finds no matching record, it logs the user in as the "Anonymous User."
The Anonymous User is an actual user in the system with a user record. Users without logins create and edit records under this user. When users without logins make changes to records, the Anonymous User appears in Append Only fields and history fields.
If you send email links to people who are not users, make sure to put the Anonymous User in a group that has the right to view or edit other people's records. Otherwise, the user will be unable to view or edit the record if they click the email link. Keep in mind that if you put the Anonymous User in a Power User group, they will use an assigned or floating Power User license.
Do not delete the Anonymous User or users without logins will be unable to access the system.
Best Practice Tip
If you plan to use email with known external contacts so that they can update or create records, set up user records for them in the External Users table, even if you don’t want them to actually log in to the system.
When a new external user is created, you can have a rule that sets a login by default to their email address and sets a password to a random string. But if you don't place them in a group, they will never be able to actually log in to the system. But by giving them a login, you allow the system to better process any changes they make, and you can track these changes in history fields.
There are two ways to let users reset their passwords:
- To let users reset their password via email, assign them to a group that permits this on the General tab of the group permissions.
- If you are using a custom login page, add a Send Password link or button to your login page that calls up another custom HTML page.
Reset Password Page
The HTML code required on the reset password page is shown below. You can add additional instructions or information for the user and insert this into your own website Look and Feel scheme:
Using this function does not send the user the current password because this could create a security problem. Instead, the password is changed to a random string of characters; this new password is sent by email, and the user must then login and create a new password from inside the system.
Reset Password by SMS
In addition to email, you can allow users to receive a password reset token by SMS. A 6-digit SMS code is generated and sent to the cell phone number in the user's profile, if one exists. The login screen will change to an authentication screen where the user must enter the code.
After this, they can enter and confirm their new password.