PortalGuard Overview

This guide describes how to install and configure PortalGuard. With PortalGuard, administrators can lock down access to their corporate intranet and extranet portals and provide end users with a more stream-lined, user-friendly authentication experience. Users can automatically unlock their account or reset their password directly from the browser without having to call the help desk.

PortalGuard increases the security of your passwords by adding features such as password quality, history, expiration, and lockout due to incorrect logins. By allowing users to securely reset their forgotten HTTP passwords via the web, PortalGuard reduces Help Desk calls and related user downtime.

Administrators can easily set password policies, such as having the user reset the password immediately following logon, or specifying the number of days until a user must reset the password.

In addition to the many preferences that an Administrator can set, PortalGuard offers a user-friendly interface for users to logon to portal servers and change their passwords.


Some of PortalGuard’s key features include:

Web-based Single Sign-On - PortalGuard ships with a built-in Identity Provider. This component can provide SSO to both on-premise and cloud-based web applications (e.g. Google Apps, Salesforce.com) using SAML or Forms-based SSO. Please see the Identity Provider / SSO section in this guide and the “Identity Federation” section in the PortalGuard Integration Guide for further details.

Enforce Multi-Factor Authentication – You can require users to authentication using Two-Factor Authentication (2FA - username, password and OTP) or Knowledge-based Authentication (KBA - username, password and challenge answer). Enforcing this for VPN users is accomplished using the RADIUS protocol. Please see the PortalGuard Integration Guide for further details.

Account/Password Synchronization - Users can manage the accounts and passwords for multiple systems from a single interface in real-time. This includes self-service features such as account unlock and password reset as well as performing a server-based password synchronization when the user changes their primary account password.

Account Self-Service

There are multiple options that can be provided for end users to manage their own accounts:

Account Unlock - Users can unlock their network account after sufficiently proving their identity via challenge answers, providing OTPs sent to their mobile device or alternate email address or both.

Password Reset - Users can reset their forgotten passwords after sufficiently proving their identity via challenge answers, providing OTPs sent to their mobile device or alternate email address or both.

Password Recovery - Users can recover or see their current password after sufficiently proving their identity via challenge answers, providing OTPs sent to their mobile device or alternate email address or both.

When using challenge answers, you can configure this feature to require answers to a configurable number of mandatory questions, optional questions, or both. Users must provide answers to mandatory questions, but optional questions have two settings that make it more user-friendly:

Shares - Of the questions defined by the administrator, this is the number of answers the user must provide when setting their challenge info. If 10 optional questions are defined and the number of shares is set to 5, the user must answer any 5 of the 10 questions during enrollment.

Threshold - Of the shares the user provides, this is the number of correct answers the user must provide to prove their identity. If the number of shares is 5 and the threshold is 3, the user must provide 3 correct answers to any 5 of the questions they answered during enrollment. This is more user friendly because it allows for cases where users may forget answers they had previously set.

Account Lockout - A configurable number of consecutive failed authentications can result in the user account being locked. An optional setting prompts the user with the number of strikes they currently have to help mitigate locked accounts.

You can configure lockouts to automatically unlock after a specified number of minutes. For more sensitive accounts, users can remain locked until the Help Desk can address the issue. The user is notified of any automatic interval in the user interface.

Password Rules – You can configure PortalGuard to control the expiration, quality, and history of users’ portal passwords.

Rules by User/Group/Hierarchy – You can assign PortalGuard’s rules to individual users, groups of users, or entire hierarchies of your domain. This flexibility gives you complete control for settings based on work responsibilities, location, or other criteria.

User Auditing – Do you need to know the last time a user logged in or keep track of how often they’re able to reset their password using the self-service functionality?

How It Works

PortalGuard works by intercepting authentication requests from your portal and redirecting them to PortalGuard’s login page. From this interface, users can still log in using the same username and password as usual, but they are also notified of password expiration, account lockout, or insufficiently complex passwords. They can then reset their forgotten passwords using highly configurable challenge question and answer functionality.

Base IIS Website

The workflow described below shows how PortalGuard communicates with Microsoft’s IIS server in more detail.

  1. An unauthenticated user opens a web browser and requests a resource from the SharePoint/IIS server.
  2. PortalGuard's login.aspx page is returned as the response from the server.
  3. The user enters their username and password in the fields and clicks the Login button.
  4. The PortalGuard logic in the login page uses AJAX to send the login information in the background to an ASP.NET web handler called PG.ashx. This web handler resides on the SharePoint/IIS server and is created as part of the PortalGuard installation. The user’s browser does not navigate away from the login page during this time.
  5. PG.ashx dynamically loads and calls into the PortalGuard application on the server. PortalGuard is implemented as stand-alone DLLs that are installed on the server. These DLLs are loaded by PG.ashx using P/Invoke.
  6. PortalGuard reads its policy and user profile data to determine how to authenticate the user. For example, if the user account is already locked, a response structure is populated with this information and the process skips to step 8.
  7. The user is looked up in the designated Active Directory or LDAP server. If the user exists, the validity of the provided password is checked by performing an LDAP bind operation against the server with the submitted credentials.
  8. PortalGuard checks whether there are any constraints that would prevent this user from logging in (for example, an expired password, another active login session, or an insufficiently complex password). A response structure is populated with the result of these checks and passed back to PG.ashx.
  9. PG.ashx passes the structure back to the PortalGuard logic on the login page. The response is interpreted by JavaScript within the PortalGuard logic. Any error conditions or messages are displayed to the user directly on the login page, clearly prompting them with any corrective actions they need to take.

If there are no conditions that prevent the login, the PortalGuard logic allows the original login attempt described in step 3 to continue. The authentication request is passed to the server's default authentication mechanism. The user receives an .ASPXAUTH token from SharePoint/IIS that will be used for the remainder of their browser session or until they manually log out.


Forms-Based Single Sign-On (FBSSO)

The Forms-Based Single Sign-On to 3rd party websites works by encrypting and storing end-users credentials on the PortalGuard server and automatically submitting this data to the proper 3rd party URL when the end-user requests SSO to the site from PortalGuard’s SSO portal. This feature is completely implemented on the PortalGuard server so it does not require any client-side software.

The administrator is responsible for making website “templates” available to end-users. These templates tell the internal PortalGuard engine how it should interact with the target websites when testing user credentials during enrollment or initiating SSO on the end-user’s behalf. Some pre-built templates ship with PortalGuard, but the IdP Configuration Editor also has a built-in Login Template creator that can help the administrator create templates for new websites. PortalGuard support can also assist with this process.


1) HTML Login Forms - Websites must utilize HTML-based login forms. Basic authentication is not supported.

2) Pre-existing User Accounts - Users must already have registered an account on the target website.

3) Username/Password Only - Full SSO only works for websites that allow login using only username and password.

4) SSO Only From PortalGuard - After enrolling for SSO, nothing prevents users from going directly to the target website and manually logging in. However, SSO is only supported when the user clicks the appropriate link on the PortalGuard SSO portal page.

5) Popup Blockers Disabled - Some websites require pre-fetching to create session cookies before login is attempted. For this kind of website, the user’s browser must allow pop-ups from the PortalGuard SSO site.


1) User logs into PortalGuard’s SSO portal (e.g. https://pg.acme.com/sso)

2) They choose to enroll their credentials for website X

3) They are prompted for their username and password for this site

4) The PortalGuard server makes one or more back-end HTTP requests to the target website to test the user’s credentials. The requests are formatted according to the chosen website’s SSO template.

5) If the PortalGuard server could not establish a session with the target website, the user is given the opportunity to change the credentials and try again.

6) If the credentials are deemed correct, the password is encrypted and a new entry is added to the user’s credential vault. The user sees a “success” message and is taken back to the SSO portal page.

7) The user now sees a new SSO tile for the target website

8) Clicking the tile causes the PortalGuard server to build and return a response that includes an HTML form containing the user’s credentials. This response will open in a new browser tab or window depending on browser configuration. The form is configured to automatically POST to the proper login URL for the target website. Since this POST is coming from the user’s browser, it will receive the response from the target website that sets the session-based cookie for access and redirects the user to the proper page.

Vault Protection

When a user enrolls for Forms-Based SSO, the password they provide is stored in their credential vault. Credential vaults are stored with users' PortalGuard user profile data. The following password protection options are currently available in PortalGuard:

a) None - Passwords are stored in clear-text. This is the least secure option and relies solely on the security of the PortalGuard user profiles. It is not recommended for security reasons, but it is available if desired.

b) Bootstrap Encryption - A different encryption key is randomly generated for each user’s vault. This key itself is encrypted with the same static key (the “bootstrap” key) used to encrypt PortalGuard's server-side settings and the resulting cipher-text is stored in the user’s vault. Vaults are safe only if the PortalGuard static key is not reverse engineered. This option also eliminates potential vault data loss due to key management since the bootstrap key does not change.

c) Generated Key (default) - This uses a patented process (#8,397,077) of retrieving user-specific data from the user directory and generating the encryption key from it. An attacker must have a user's vault, data seed(s) and reverse engineer the algorithm to crack the vault.


The FBSSO feature is entirely implemented on the PortalGuard server. This makes management very easy because there is no client-side software, but it also prevents the feature from working with all websites. The following website login designs are known to be unsupported:

1) CSRF Protected Logins - Cross-Site Request Forgery (CSRF) (link) is a well-known attack where a malicious web server attempts to perform an action on a different website by leveraging the user’s existing session with that site. Some websites (e.g. Google) have implemented anti-CSRF measures for the login process as well so they are not candidates for PortalGuard’s server implementation of FBSSO.

2) Multi-step Logins - Websites that ask for a username on one web page, then prompt for the password on a separate page are not supported. Banking and financial websites typically use this design. The PortalGuard server can only make one POST to the target server before the user’s browser takes control of the browsing session so there is no opportunity for PortalGuard to automatically provide the password. This limitation also applies to websites that require multi-factor authentication.

3) AJAX Logins - Some websites use a background AJAX call to validate credentials without leaving the login page. This call typically sets a session cookie and subsequent logic on the login page redirects the user to the appropriate page. PortalGuard cannot currently support this configuration.