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 in which the user performs 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 is allowed to continue 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.

The 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 form that cause 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.

The screenshots below illustrate:

1) A standard corporate login form

2) Forcing the user to set their challenge answers using the PortalGuard Sidecar

3) Allowing users to reset their forgotten password using the PortalGuard Sidecar directly from the standard login form

Usage Scenarios

Best used for self-service actions

Using Sidecar is a quick way to provide users the ability to unlock their account, force enrollment of answers to challenge questions, reset or recover their forgotten passwords and enroll their mobile device 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 when necessary, it does not provide the ability to securely enforce authentication decisions to the target server.This is because 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 web browsers today.Any manipulation, however, would be limited to impacting only their own browsing session and cannot affect the sessions of other users.

Thus 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 PortalGuard never 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 their browser and accesses the target server, e.g. www.acme.com
  2. The target server sees the user has not yet authenticated so it returns the HTML for its login page.
  3. The user enters their name and password in the normal fields and presses the Enter key or clicks the “Login” button.This POSTs the user’s credentials directly to the target server.
  4. The target server validates the user’s 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 that ties the user’s browser session to the authentication that just took place.

Server Access - After Sidecar

  1. The user opens their browser and accesses the target server, e.g. www.acme.com
  2. The target server sees the user has not yet authenticated so it returns the HTML for its login page.The Sidecar JavaScript runs and silently changes the default submit behavior of the login form.
  3. The user enters their name and password in the normal fields and presses the Enter key or clicks the “Login” button.This would normally POST the user’s credentials directly to the target server.Instead, the Sidecar JavaScript prevents this 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. Active Directory).
  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 what requirements have yet to be 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/enrollment or impending password expiration.
  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.It then automatically hides the <iframe> element and 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 user’s 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 their credentials.
  • PortalGuard must be configured to use the same user repository (e.g. Active Directory) as the target server(s).
  • 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".
  • 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