PortalGuard's Latest in Feature Updates - Summer 2019

PortalGuard Upgrade There is never a shortage of feature and enhancement requests from our customer base. These have been critical to ensuring PortalGuard's relevance in the authentication space so keep them coming! Features that make it into PortalGuard are either directly funded by a customer through our Tailored Authentication program or they are requested by multiple customers. For the latter case, these features bubble up because they will benefit more than a single customer. This blog covers some of the latest features added to PortalGuard.

Automatic Directory Fallback/Failover

For years, PortalGuard could only operate against a single directory during login. That directory was "resolved" using either the server name in the URL or any prefix or suffix on the username value. This new fallback functionality allows a PortalGuard server to search for users across multiple directories. It allows end users to login using a simplified username format (e.g. "theuser") rather than requiring them to enter a username with a specific prefix (e.g. "DomainA\theuser") or suffix (e.g. "theuser@domainA.org"). It performs directory "fallback" until the user is found -OR- all directories have been searched.

When enabled, the precedence of the directories is configurable so the largest or most common directories should be set with the highest priority. Because searching stops once a user match is found, usernames must be unique across all included directories. This feature does NOT test passwords on same-named accounts in multiple directories as this would continually result in "strikes" on the accounts in higher priority directories when users in secondary directories login.

help desk modifier

Besides providing a more convenient login experience for end-users, this feature also allows users of the PortalGuard Help Desk Console to specifically choose the directory where the target user(s) exist. Before this, the target directory was fixed as the one resolved either by the server name in the URL or the prefix/suffix of the logged-on Help Desk user. This new flexibility will prevent the need for Help Desk admins in organizations from having to maintain a Help Desk account in each directory.

Integration with BIO-key’s WEB-key Product for Browser-Based 2FA

Some states in the US have strict laws about use of an employee's personal phone for business purposes. 


California has a statute requiring businesses to reimburse employees that must use their personal cell phone for business purposes. This can get very expensive in terms of money and procedures so it's understandable that most organizations want to avoid it altogether. Hardware-based tokens are one alternative, but the extra cost and having to handle cases where employees forget or lose these are also problematic.

screenshot 2

Biometrics is an option since employees cannot "forget" or misplace their second factor because, well, the second factor is them! As such, PortalGuard has added support for BIO-key's WEB-key solution as an additional browser-based 2FA method. This integration focuses on WEB-key's fingerprint support using hardware-based readers but it also has some support for proximity cards. Users can launch the WEB-key client to enroll their fingerprints directly from the PortalGuard Account Management page and establish WEB-key as their default or fallback method for browser-based 2FA.

End-User Agreement Acceptance

PortalGuard has long been able to display a "Terms of Use" agreement before allowing a user to login. It had some limitations like only supporting a single agreement and can present formatting challenges since the text is stored as a JavaScript string. This new feature adds the ability to maintain multiple, targeted, WYSIWYG-editable "agreements" and report on end-user acceptance or rejection of each. This can be used to ensure end-users have agreed to a customizable statement before accessing a specific application which can help satisfy compliance requirements.

This new feature is based on PortalGuard's existing "Announcements" extension, so its installation and use are required. Each applicable agreement is shown after the user has manually provided valid credentials during a browser login. A single agreement is shown at a time with separate "Accept" and "Reject" buttons. Clicking "Reject" logs the timestamp of the user's action in SQL, overwrites any older "rejection" timestamp and redirects them to a configurable URL. The user does not have a valid PortalGuard session at this point, so they do not yet have access to your portal or any SSO-based websites. A "rejected" agreement is shown to the user the next time they login manually through PortalGuard.

Clicking the "Accept" button logs the timestamp of the user's action in SQL and allows them to continue. If another agreement must be accepted, it is displayed at this point. Once a user "accepts" an agreement, it will no longer be displayed to them, but it can be reported on through SQL by administrators.

Installation Requirements

The Directory Failover and Acceptance features only require upgrading your PortalGuard server to version To use the BIO-key integration, that same version of PortalGuard is required, but you must also install the WEB-key Client software and have a compatible fingerprint reader on each workstation that will use it.


Do you like the option of another 3rd party biometric 2FA method within PortalGuard? Would your institution like end-users to accept an agreement before accessing specification applications? Please let us know or contact us for more information.

Tags: Authentication Security, End user experience, MFA, Multi-Factor Authentication, PortalGuard, Access Control, Access Management, Active Directory, PortalGuard Configuration, PortalGuard for Education, PortalGuard Update, SOL-based directory, two-factor, Two-Factor Authentication, secure login, security risk, login session, mobile authentication, Biometrics, front-end login, voice biometrics, domain policy, fingerprint readers, enable 2fa, security compliance, features, voice recognition, tailored authentication, automatic delivery fallback/failover, web-key, bio-key

Gregg Browinski

Author: Gregg Browinski