Functionality

The PortalGuard API allows you to add all functionality available within PortalGuard to your own web applications.The lists below describe this functionality.

 

Account Self-Service

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.

 

Multiple Authentication Factors

OTP via Mobile Device — Allows for two-factor authentication by requiring the user to provide a username, password & OTP sent to their mobile device via SMS.PortalGuard can require the user to enroll their mobile device through its browser-based interface.PortalGuard has its own proprietary Time-based OTP generating app and the Google Authenticator is also fully supported.

Hardware Tokens — PortalGuard supports a multitude of OTP methods including YubiKey, RSA SecurID and HMAC-based OTP (OATH) tokens.

Challenge Answer Required on Login — Allows for more robust authentication by requiring the user to provide a username, password & answer to a randomly chosen question they have previously answered in order to login.

 

Single Sign-On (SSO)

SAML — A digitally-signed one-time token is generated by the PortalGuard server and sent to the target server as proof of authentication.Subsets of SAML versions 1.1 and 2.0 and WS-Federation are supported.

WS-Federation — Part of the larger Web Services Security (WS-Security) framework, WS-Federation defines mechanisms for allowing disparate security realms to broker information on identities, identity attributes and authentication (link). Microsoft products typically require WS-Federation.

CAS — A standard protocol developed by Yale University that is very commonly supported by applications in higher education.PortalGuard supports the primary subset of CAS 3.0.

Forms-Based SSO — User’s credentials for 3rd party websites are encrypted and stored on the PortalGuard server.The user can manage credentials for supported 3rd party websites and can receive SSO by clicking links on the PortalGuard SSO portal page.

 

Account/Password Synchronization

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.

 

Login Session Concurrency

Prevent Concurrent Login Sessions — PortalGuard can prevent users from having more than one concurrent login session with the portal server.This is achieved by assigning the user a session identifier cookie that persists for the life of the browser.This session identifier is also stored in the user’s profile.In order to clear the session from the user profile, the user must perform a logout on the website.If a user shuts down their browser without manually logging out, attempted logins with that account will not be permitted until the session is cleared from the user profile.

 

User Lockout

User Strikeouts — A configurable number of consecutive failed authentications will result in the user’s account being locked.Once an account has reached the strike limit, no end-user operations can be performed on it (login, change password, reset forgotten password, etc).PortalGuard counts invalid passwords -AND- invalid challenge answers (if password recovery is enabled) as strikes.If not struck out, a successful authentication (either via password or challenge answers) will clear any strike count on the user’s profile.

Strikeout Warnings — During authentication, the end user will see a message that a strike has been written to their account.The information includes how many strikes are on the account and the number remaining before the account is locked out.

Strikeout Expiration — To ease user frustration and administrative overhead, strikeouts can be configured to automatically expire.The number of minutes strikeouts should remain in effect is configurable in the policy.When this feature is enabled, user attempts to authenticate with a locked account will receive notification of the number of minutes they must wait before the account is unlocked.

Inactivity Lockout — A hold can be placed on user accounts based on a configurable number of days of inactivity.This hold prevents all actions.PortalGuard uses its capability to track last login times to enable this functionality.This setting does not make changes to the user account in LDAP to achieve this lock - it is only within the user’s PortalGuard profile that the lock is enforced.

 

Password Expiration

Expiration Period — The number of days until the user will be forced to change their password through the PortalGuard interface.This period counts from the last password change through PortalGuard.

Grace Period — The number of days after a user’s password expires that will still be allowed to login using the current password.When logging in with an expired password, the user will receive notification of the number of days until the grace period ends and have the option of continuing the login without changing their password.When the grace period ends, the user will be forced to change their password in order to login to the web server.

Expire On First Use — If desired, the first time a user logs in through the PortalGuard interface, they can be required to change their password immediately.This is one way to force the user to comply with the password complexity rules enforced by PortalGuard.

Check Password Strength on Login — The other way to ensure compliance with the password rules configured through PortalGuard is to proactively check the password strength of user’s passwords when used to login.This is a much more granular approach to ensuring password quality compliance because it only affects accounts with passwords that are not complex enough.If you are required to make a change to PortalGuard’s password complexity rules, this setting will help ensure that users comply with the rule changes immediately.

 

Auditing

Log Last Login — Stores the date and time the user last logged in through PortalGuard.The value is always stored in Greenwich Mean Time (GMT).

Log Last Password Change — Stores the date and time the user last changed their password through PortalGuard.This is updated when the user changes their password by providing the current one or by resetting their password with challenge questions and answers.The value is always stored in Greenwich Mean Time (GMT).

Log Last Password Recovery — Stores the date and time the user last reset their password through PortalGuard using a password recovery mechanism.This can help show Return on Investment (ROI) by tracking how often users are able to restore their own access without calling the Help Desk.The value is always stored in Greenwich Mean Time (GMT).

 

Password Complexity Rules

PortalGuard maintains its own password settings apart from those for your user repository.It is recommended that you set PortalGuard’s rules equal to or stricter than those for the user repository to ensure that passwords acceptable to PortalGuard are not considered unacceptable by the user repository.

 

Password History — PortalGuard can store hashes (using SHA-1) of passwords previously changed through its interface.This functionality allows specification of the number of entries to maintain in the history.This functionality follows a “first in, first out” (FIFO) mechanism for storing the hashes. Alternatively, the number of days’ worth of hashes can be specified to prevent users from iterating through permutations of their password to get back to their “favorite” one during the same day(s).

Minimum Length — The minimum number of characters a password must contain.This check can be skipped.

Maximum Length — The maximum number of characters a password may contain.This check can be skipped.

Minimum Lowercase — The minimum number of lowercase characters a password must contain.This check can be skipped.

Minimum Uppercase — The minimum number of uppercase characters a password must contain.This check can be skipped.

Minimum Numeric — The minimum number of numeric characters a password must contain.This check can be skipped.

Minimum Special — The minimum number of non-alphanumeric characters a password must contain.This check can be skipped.