All Collections
Getting Started
Scanning Secure Content
Scanning Secure Content

Methods to access authenticated or otherwise protected web environments.

Product Enablement avatar
Written by Product Enablement
Updated over a week ago

Overview

Allowing ObservePoint to audit your QA/staging servers is a critical step in the release cycle for your website. It will enable you to verify that data collection technologies are deployed correctly before data quality has been affected.

Most enterprise-level businesses have IT security protocols in place to protect QA/staging servers from unauthorized access. To audit these resources, your IT security group will need to allow ObservePoint access to these protected resources.

The following security methods are supported by ObservePoint:

  1. Firewall

  2. Basic authentication

  3. Proxy authentication

  4. Reverse Proxy

  5. Browser or form-based authentication

  6. Private DNS

  7. VPN (involves additional cost)

Note: Secure website addresses provided to ObservePoint must match your SSL Certificates in use by ObservePoint.

1. Firewall

When access is controlled by a firewall, instruct your IT security group to allow access to ports 80 and 443 for the ObservePoint IP addresses. These addresses are available here.

2. Basic Authentication

Instead of using firewall security, some businesses will use a server protocol called Basic Authentication. This is the case when a browser pop-up requests a username and password before allowing access to any content.

Here is an example of a browser pop-up request to authenticate a user.

Basic authentication transfers usernames and passwords between the browser and server in unencrypted plain text which can be intercepted. It is our recommendation that all QA/staging servers be secured using a firewall, since this is the most secure way to prevent unauthorized access to these resources.

The URL syntax for Basic Authentication appends the username and password separated by a colon to the beginning of the URL like this:

https://username:[email protected]

To scan a site using Basic Authentication:

  1. From a new or existing Audit or Journey, select Advanced Settings.

  2. At the top, navigate to Pre-Audit Action, select Create Pre-Audit Action, and make sure the Action Type is set to Navigate To.

  3. Enter the URL with your credentials appended to the URL e.g. https://username:[email protected]

  4. Save the configuration

Note: Best practice for Basic authentication is to use a secure protocol (https://) so that the credentials are not sent in the clear. However, regardless of the URL's protocol, the Basic Authentication URL is stored on ObservePoint's servers just like any other URL and is not encrypted. By specifying _https_ the ObservePoint browser will create a secure connection with your server and send the credentials in encrypted text.

3. Proxy Server

Some QA/staging servers are accessible via a custom web proxy. If this is the case, you will need to configure the Audit or Journey to utilize your custom proxy and any additional authentication you may have.

Your web proxy must be internet-accessible, and ObservePoint's IP addresses must be whitelisted.

To audit a site via a custom web proxy:

  1. Setup your Audit as normal and then select Advanced Setup

  2. Under Location, select use a custom proxy

  3. Input the proxy in the format required (e.g. http://example.com:8080)

From Advanced Setup you can select "use a custom proxy."

4. Reverse Proxy

One way ObservePoint can access Stage/QA environments is through Reverse Proxy. In simple terms, using Reverse Proxy, our servers make a request to a publicly accessible server owned by your organization and then your organization forwards the request to an internal server as shown in the diagram below.

To set up access for an internal, pre-production environment, ObservePoint will need the IP address of your reverse proxy server. Your IT team will need to know that the request will come from one of these ObservePoint IP addresses.

If your IT team configures the reverse proxy server for all of the ObservePoint IP addresses, then Audits or Journeys can use any of the available proxies.

Note: Only the Direct-Oregon, US IP address ( 35.161.29.125) is really necessary since the origin of the original request will get lost in the handoff.

5. Browser or Form-Based Authentication

Form-based authentication uses a login like you would to access your email or banking website.

Using form-based authentication with ObservePoint requires each field to have a unique HTML ID or other type of selector. The image below shows the username field has an ID of "edit-name".

Each input field needs a unique HTML ID or other selector.

Under the Pre-Audit Actions, tab add Actions to fill in the username and password fields and to click the Submit button.

6. Private DNS

ObservePoint can access your sites that are publicly accessible, yet not publicly known, when you provide ObservePoint with the private DNS entries for your websites. When ObservePoint adds your private DNS entries to its host files it will be able to resolve siteA.yourcompany.com to your IP address.

Note: This may need to be used in conjunction with approving ObservePoint’s IP addresses.

7. VPN

This solution requires a dedicated, site-to-site VPN tunnel configuration between the ObservePoint and client networks.

To maintain security, ObservePoint provides dedicated data collection servers, which will only connect to the client servers and ObservePoint systems.

The settings for VPNs are custom to each enterprise and need to be configured with the help of your Customer Success Manager.

Note: There is an associated cost to setting up a VPN that can be clarified with your Account Executive or Success Manager if you are unsure who that is or have further questions contact [email protected] for help.

ObservePoint will work with your network administrators to verify that VPN is an option for your company and will need basic information to evaluate and scope the solution, including:

  1. Primary network team contact name and email

  2. Type of firewall in use (Cisco, Juniper, etc.)

  3. Firewall public IP Address

  4. URLs and IP Addresses associated with the web servers hosting those URLs

  5. Confirmation that there are no routing conflicts, we want to apply a CIDR block that doesn't overlap with the customer network

Did this answer your question?