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.
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.
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
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.
The Directory Failover and Acceptance features only require upgrading your PortalGuard server to version 22.214.171.124. 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.