Agiloft supports single sign-on (SSO) on the web via integration with Apereo CAS (Central Authentication Service). This allows Agiloft to have integrated authentication with products such as uPortal, BlueSocket, TikiWiki, Mule, Liferay, Moodle, and others.

From the user's point of view, the typical integrated scenario is simple. First, they log in to a CAS-enabled product such as uPortal. Then, using a hyperlink from within the portal, the user can easily access Agiloft.

Technical Overview

For the typical integrated scenario described above, the following occurs:

1. When the user logs in to the CAS-enabled product, CAS issues a secure token that is usually stored as a cookie. 

2. When the user clicks the hyperlink to access Agiloft from within the portal, Agiloft uses a client-side redirect to pass the URL contained within the hyperlink to CAS. Note that this is the same process that occurs if the user selects a CAS-aware hotlink from within an email they received from the KB.

   1. If the user is currently logged in to CAS, CAS verifies the token and redirects the user back to the URL within Agiloft. The location of the Agiloft instance is determined automatically at installation time or overridden when the Hotlink Server Root URL global variable is passed to CAS to tell it where to find the Agiloft instance after authentication is performed.

   2. If the user hasn't logged in to CAS or CAS requires reauthentication, then CAS displays a login form, authenticates the user, and, if successful, performs a client-side redirect back to the URL within Agiloft. As above, the location of the Agiloft instance is determined automatically at installation time or overridden when the Hotlink Server Root URL global variable is passed to CAS to tell it where to find the Agiloft instance after authentication is performed.
3. When CAS sends the user back to the original URL, the redirect contains another secure token that confirms that authentication has been performed. After verifying the authenticity of the secure token,  Agiloft obtains the username via direct connection to CAS and logs in. 

Setup

To configure SSO with CAS, complete the following steps on a per-KB basis:

1. Go to Setup > System > Manage Global Variables.

2. Edit the CAS Server Login URL global variable to enter your CAS login URL. For example: https://<your_host>/cas/login

3. Confirm that the CAS Ticket Validator global variable contains the correct CAS Server version for your setup. If it doesn't, edit it so that it does.

4. Embed a correctly formatted hyperlink to Agiloft within your CAS-enabled product. The hyperlink embedded within the CAS-enabled portal follows the usual rules for Agiloft Hyperlinks but uses a special entry point, /cas-login, and doesn't specify user and password credentials. When creating the link, use a plus sign (+) in place of any spaces in the KB name.

   Example

   <a href="https://example.agiloft.com/gui2/cas-login?keyID=0&project=Example+KB+Name&state=Main">https://example.agiloft.com/gui2/cas-login?keyID=0&project=Example+KB+Name&state=Main</a>

   The structure of the URL output is: https://DOMAIN_NAME/gui2/cas-login?KB+NAME&state=main

   For example: https://example.agiloft.com/gui2/cas-login?Example+KB+Namestate=main

   For system-generated email hotlinks, you don't have to make any changes to accommodate SSO and non-SSO users. Based on a user's login method, Agiloft manages which hotlink URL they receive in email. Each time a user logs in, the system sets a hidden SSO Authentication Method field in the user's record. If a user logs in with a standard username and password, the value is STANDARD. If a user logs in with CAS SSO, the value is CAS. This value determines whether email hotlinks go to login.jsp or cas-login. Don't edit a user's SSO Authentication Method because you might prevent them from accessing the system.
5. Finally, to make sure users can't circumvent SSO and log in to Agiloft directly, follow the instructions in Force SSO Login below.

Force SSO Login

To force users to log in with SSO, you can prevent them from accessing Agiloft with their username and password. Follow the steps below to make the Password field optional in the Employees table and then remove passwords for employees who should log in with SSO.

1. First, make the Password field optional in the Employees table:
   1. Go to Setup Employees and go to the Fields tab.
   2. Edit the Password field and go to the Options tab.
   3. Find the Make this a required field setting and change the value from Yes to No.
   4. Click Finish to save the change.
2. Next, for employees who should always use SSO to log in, reset their passwords to a null value:
   1. Go to the Employees table and select each user who should use SSO from this point on.
      Don't select every user in your system. It's best to leave at least one administrator unchanged, if not the whole admin team, in case you encounter SSO issues in the future that prevent users from logging in with SSO.
   2. Click Edit Fields in the action bar.
   3. Select Password, then click Next.
   4. On the Update tab, select A formula.
   5. In the Password field, enter the variable $global.null and click Next.
   6. On the Confirm tab, clear the Run rules and Update defaults checkboxes, then click Finish.

Now, users whose passwords were reset can only log in with SSO.