PortalGuard has numerous integration methods that can help you leverage its functionality throughout your environment.

Direct Access

For customers that want to provide a direct link to their Nebula instance for purposes of SSPR or SSO. Users can access their Account Management page this way to change or enroll new phone numbers, change challenge questions/answers, etc.

Sidecar Mode

PortalGuard can enhance the login process for remote HTTP servers on which PortalGuard is not directly installed. This is referred to as "Sidecar" mode. A small JavaScript library is added to the login form for the target HTTP server. This new code temporarily suppresses the login to the target server and calls out to the PortalGuard server instead. PortalGuard validates the user's credentials and verifies that the user does not need to take any specific PortalGuard actions (e.g. setting challenge answers). If PortalGuard requires the user to take action, a floating frame appears over the top of the target server's HTML login form. The user uses this frame to perform the requested action directly against the PortalGuard server. Once no further action is required, the floating frame is closed and the original login attempt to the target server proceeds as normal. If no PortalGuard action is required of the user, then the floating frame never appears and the login attempt passes directly to the target server. Sidecar mode achieves a high level of integration with your current login forms without requiring any changes to the target server's back-end or authentication configuration. This allows you to easily add "Forgot password?" links directly to your normal login forms, allowing the PortalGuard "Reset Password" wizard to appear on demand in the floating frame. By leaving your standard login forms intact, end-user training, development changes and administrative overhead are almost completely eliminated.

Usage Scenarios

Best used for self-service actions

Using Sidecar is a quick way to provide users with the ability to unlock their accounts, force enrollment of answers to challenge questions, reset or recover their forgotten passwords and enroll their mobile devices for use in multi-factor authentication.

Not to be used for stronger authentication

The Sidecar interface is implemented using JavaScript which executes within the end-user’s browser. While this allows for rapid deployment by having the end user communicate directly with the PortalGuard server whenever necessary, it does not provide the ability to securely enforce authentication decisions to the target server. This is due to the fact that Sidecar does not change how the target server authenticates users on the back-end. Highly technical users could potentially bypass PortalGuard’s Sidecar JavaScript during their own browser sessions using JavaScript debuggers that are available in most web browsers today. Any manipulation, however, would be limited to impacting only their own browsing session and cannot affect the sessions of other users.

In light of this, Knowledge-based Authentication/KBA (username, password and challenge answer) and Multi-Factor Authentication/2FA (username, password and OTP) cannot be reliably enforced through Sidecar Mode because PortalGuardnever communicates its authentication decisions to the target server either directly or indirectly.

How It Works

The image below shows a standard login process between a user, a web browser and the configured user repository before Sidecar is implemented.

Server Access - Before Sidecar

1.The user opens the browser and accesses the target server.

e.g.www.acme.com

2.The target server sees that the user has not yet authenticated so it returns the HTML for its login page.

3.The user enters his or her name and password in the normal fields and presses the Enter key/clicks the “Login” button. This POSTs the user's credentials directly to the target server.

4.The target server validates the credentials against its configured user repository (e.g. Active Directory).

5.The user repository returns a success or failure code indicating the fidelity of the credentials.

6.If the credentials are correct, the target web server returns a session cookie that tiesthe user's browser session to the authentication that just took place.

Server Access - Before Sidecar

1.The user opens their browser and accesses the target server, e.g. www.acme.com

2.The target server sees that the user has not yet authenticated so it returnsthe HTML for its login page. The Sidecar JavaScript runs and silently changes the default submit behavior of the login form.

3.The user enters his or her name and password in the normal fields and presses the Enter key/clicks the “Login” button. The Sidecar JavaScript prevents the typical POST action and submits the form fields to the PortalGuard server.

4.The PortalGuard server validates the user's credentials against its configured user repository (e.g. ActiveDirectory).

5.The user repository returns a success or failure code indicating the fidelity of the credentials.

6.PortalGuard queries its security policies and user profile store to determine what features are in effect for the user and which requirements have yet tobe satisfied.

7.PortalGuard parses the data from the PortalGuard security policy and user profile to see if any user actions must be completed; such as challenge questions that need answering, impending password expiration, or mandatory enrollment.

8.If the user must interact with PortalGuard in some way, the response from the PortalGuard server will cause the floating <iframe> element to become visible. It will obscure the standard login form and the user will then interact directly with PortalGuard until the requirements are satisfied.

9.The Sidecar JavaScript is notified by the PortalGuard response that its direct interaction with the user is completed. The <iframe> element is hidden and the Sidecar JavaScript silently POSTs the username and password to the target server as it would if Sidecar mode was not in place. Note that any changes to the password enacted during the user's direct dealings with PortalGuard (e.g. a password reset via self-service or an expired password that was changed) will be automatically used.

10.The target server validates the credentials against its configured user repository just like it normally does. It has no knowledge of the user's interaction with the PortalGuard server, so it must verify the credentials are correct to ensure proper security.

11.The user repository returns a success code indicating that the username and password are correct. This step should never return a failure because PortalGuard has already validated the credentials against the same repository. Since PortalGuard and the target server are operating completely independent from one another, these seemingly redundant logins are imperative to ensure both processes remain secure.

12.The target web server returns a session cookie that associates the user's browser session to the authentication that just took place.

Requirements

Sidecar mode has the following requirements:

The target HTTP server must use a HTML form for user authentication. The HTTP server must not be configured to use Basic authentication since web browsers handle this form of authentication by simply popping up a dialog box in which the user enters his or her credentials.

PortalGuard must be configured to use the same user repository (e.g.Active Directory) as the target server(s).

Both the target and PortalGuard servers must both have Fully Qualified Domain Names (FQDN) in DNS that end with a common domain,e.g. "acme.com".

Both the target and PortalGuard servers must both be reachable on the network by end-users using their FQDNs, e.g. "www.acme.com" and "pg.acme.com".

JavaScript must be enabled on the end-user's web browser

The login page of target server must be edited to include the Sidecar JavaScript and <iframe>element

As an optional client-side component, you can install the PortalGuard Desktop on your workstations. The PortalGuard Desktop software allows workstation based challenge Enrollment & Recovery.

Usage Scenarios

This feature can be used to force users to enroll in the Challenge Question and Answer recovery feature (by providing personal answers to the questions they choose) AND reset their password directly from the Windows or Mac login screen.

When users log into the Windows work station,they can be forced to set challenge answers if they have not already done so.They must complete this enrollmen tbefore their Windows desktop will appear. If they forget their password, they can launch a password recovery wizard directly from the Windows login screen, which will allow them to reset their password and unlock their Active Directory account when on the network.

When users are off the corporate network but forget their Active Directory domain password, resetting the password is not an option as this requires network connectivity to an Active Directory domain controller. Instead they can restore access to their workstation by being shown their current/forgotten password after correctly answering a sufficient number of the same challenge questions. They can then login to their machine using cached credentials.

How It Works

PortalGuard Desktop integrates with Windows and Mac OS X Machines to communicate directly with the Nebula Server. This allows users to enroll challenge answers, reset their passwords, and unlock their Active Directory accounts. Since an Active Directory domain controller is reachable by the client, any new password can be used immediately to login to the workstation.

Once the user provides the correct credentials, the PortalGuard Desktop verifies that the user is in compliance with the settings in their PortalGuard policy.

For example: Since enrolling challenge answers can be enforced in this policy, if the user has not already done so, they will be forced to provide these answers before being able to access their desktop.

Offline Password Recovery (Windows Only)

If offline password recovery is enabled in the Nebula policy, the user's credentials are used to create and/or verify the user-specific, encrypted recovery information on the server. This encrypted information is validated and copied to the local machine upon each network login to Windows. If the user changes his or her Windows password from the workstation, or resets the password using PortalGuard, this recovery information is automatically rebuilt.

Decryption of the recovery information is attempted using the challenge answers provided by the user. Optionally, an offline lockout feature can be used to delete this recovery information after a configurable number of unsuccessful attempts.

Requirements

The following requirements are common for all features available in the PortalGuard Desktop component:

Windows 7,8, & 10 operating system (32 or 64-bit) Mac OS X, 10.8 or later

The.NET Framework 2.0 or later must be installed on Windows machines Installation must be performed by an administrator

Identity federation is the concept of linking a specific user identity across multiple systems or servers. When two servers are federated, the authentication against one can be leveraged to prove the user's identity to the other. Some application servers in the secondary role can allow this without requiring the user to register an account.

Identity federation typically entails some level of Single Sign-On (SSO). Once authentication has been performed against a primary server, the user's session with that server can then be used as a launch point for SSO-based access too the federated services. This can be used to realize the common business requirement of reducing access barriers without compromising the security of the systems involved.

There are multiple protocols that can be used to apply the successful authentication against one system to another, but Security Assertion Markup Language (SAML) has emerged as a clear front-runner (CAS, WS-Federation and OAuth can also be used). SAML is an XML-based language that is used to convey identity information. SAML is heavily leveraged today for numerous reasons:

It works for cloud-based services that are typically hosted offsite as well as “on premise”services.

The use of HTTP/HTTPS also allows for easier network administration since these ports are more frequently open in server or client firewalls.

Manual user authentication for multiple services can be redirected and always be performed against a single Identity Provider (IdP). This “choke point” allows for network and access policies to be controlled at a single point making them much easier to implement and enforce.

Usage Scenarios

Consistent authentication interface

When the user is always forced to login to your federation-capable applications using PortalGuard, a consistent authentication interface and process can be enforced.This reduces end user training and frustration associated with managing multiple accounts through multiple websites.

Enforcing self-service enrollment

Using identity federation offers a seamless way to provide users with the ability to unlock their account, enroll answers to challenge questions, reset or recover their forgotten passwords and enroll their mobile device for use in multi-factor authentication.

Multi-factor authentication

Because the end user communicates directly with the Nebula server, authentication decisions made by Nebula are strictly enforced. This ensures a high level of security and consistency.

How It Works

1.The user opens the browser on the client machine and accesses the target server, e.g.www.acme.com

2.The target server sees the user has not yet authenticated, it generates a SAML request and returns it alongside the originally requested URL (the “RelayState”) to the client machine as hidden input fields in an

HTML-form response.

3.JavaScript in the response automatically submits the form to the PortalGuard Identity Provider (IdP).

4.PortalGuard sees the user has not yet authenticated to it, it responds with a prompt for the user's credentials.

5.The user enters their username and password and submits them to PortalGuard.

6.The PortalGuard server validates the user's credentials against its configured user repository (e.g. Active Directory).

7.The user repository returns a success or failure code indicating the fidelity of the credentials.

8.PortalGuard queries its security policies and user profile store to determine what features are in effect for the user and what requirements have yet to be satisfied.

9.PortalGuard parses the data from the PortalGuard security policy and user profile to see if any further credentials are required from the user(e.g. for KBA or 2FA). If so, additional round-trips between the user and PortalGuard occur to receive and validate this information.

10.Once the user has fully authenticated to PortalGuard, it queries the configured identity claims store (e.g. Active Directory) for requested claim information such as username or email address. It adds these claim values to a SAML response and digitally signs the response XML to prevent tampering. The signed SAML response and original RelayState are added as hidden input fields in an HTML-form response, which is sent back to the user's browser.

11.JavaScript in the response automatically submits the form to the target server's Assertion Consumer Service (ACS).

12.The target server validates the SAML response and maps its identity claim(s)to the appropriate user account. The server then generates and returns a session cookie that ties the user's browser session to the authentication that just took place.

No passwords are included in the SAML response, so the target server does not need to contact its own user repository for authentication purposes. The digitally signed SAML response from a trusted IdP sufficiently proves to the target server that the user is authentic.

Requirements

The Identity Federation option has the following requirements:

  • The target server must support SP-initiated SAML SSO using the POST binding The target server must be configured to not allow manual authentication.
  • Otherwise, users could use that method and bypass the interactions with PortalGuard.

  • A trust must be configured between the PortalGuard Identity Provider and the target server/service provider.
  • The end user must have network connectivity (HTTPS) to both the Nebula server and the target server.
  • The PortalGuard server does not need network connectivity to the target server since the user's browser delivers all SAML messages.