Page tree
Skip to end of metadata
Go to start of metadata

Access Methods

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

You can also control access by imposing IP address restrictions on your system. For more information, see Security.

User Access

User informationincluding login, password and other datahas 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 parametersKB name, Table, State, Search, Record ID and so onand 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:

    <form method= "post" 
     action="" > 
     <input type= "hidden" name= "KeyID" 
     value="0" > 
     <input type= "hidden" name= "state" 
     value= "Main" > 
     <input type= "hidden" name= "project" 
     value= "KnowledgeBaseName" > 
     <input type= "hidden" name="exiturl" 
     value="" > 
     <input type= "hidden" name= "loginurl" 
     value="" > 
     <table border= "0" width= "90%" > 
     <tr><td align=left>Username:</td> 
     <td> </td> 
     <input type="text" size= "30" 
     maxlength= "50" 
     name= "user" 
     value= "admin"> 
     <tr><td align=left>Password:</td> 
     <td> </td> 
     <input type="password" size= "30" 
     maxlength= "50" 
     name= "passwd" > 
     <td align=left> </td> 
     <td> </td> 
     <input type= "submit" 
     value= "Login" > 

    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:

sudo bash

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

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.

Sending/Resetting Password

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:

 <form action="http://[serverhostname]/gui2/resetPassword" 
 Login:<input type=text name=login size=25 maxlength=50><br> 
 or email address:<input type=text name=email size=25 
<input type="hidden" name="resettype" value="email" />
<input type="hidden" name="resettype" value="text message" />
<input type="hidden" name="mode" value="request" />
<input type=hidden name=project value=[KB Name]> 
<input type=submit value=Go> 

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.