Development Tools & Technology

Version No: 2.0

Author: Ben
Felix, Brian Carroll
Date Issued: 7th
November, 2014

Implementation of
BrowserStack
Licensing, Administration and Governance
7th November, 2014

Internal Use Only

Purpose

This document details the proposal for the implementation of the

BrowserStack “Live” CBT service, a detailed explanation of how it is
administered and all governance policies related to the application. The
document also details the licensing model for the application and the
methods deployed to tackle outstanding issues.

2
Problem Statement

The BrowserStack “Live” solution is required as currently no easy method

exists within the bank for testing browser/operating system combinations
for websites. BrowserStack is an automated and intuitive solution that
allows users/developers to test websites on different browsers by simply
changing the configuration for the Operating System and Browser
type/version.

Licensing

The licensing model that has been put in place is as follows:

 A purchase order of a total of 80 concurrent licenses on a 12-month

subscription basis.
 A maximum of 240 users can be registered to use the application at
any given point of time.

Issues

During the implementation of BrowserStack, it had been observed that it was

possible for users to navigate to websites restricted by the firm’s
firewall e.g. Dropbox, Gmail, Outlook Mail etc. This issue had been
escalated to the BrowserStack support team as a matter of urgency.

The cause of this issue was that the application allows two different forms
of testing:

 Testing of public URLs

 Testing through the local proxy

On accessing public URLs, it was observed that instead of using the firm’s
proxy gateway, the websites were being accessed through BrowserStack’s
remote proxy gateway. This resulted in users being able to access public
websites that are restricted by the firm’s firewall.

Issue Handling

The team at BrowserStack have been able to implement a mechanism that

restricts access to any public website i.e. any website that is not hosted
within Barclays. The resolution has been carried out by disabling the
feature that allows access to public URLs.

Once a connection is established with BrowserStack’s remote browser,

navigation is allowed only to websites hosted within Barclays’ domain and
those allowed via Barclays’ web proxy. The BrowserStack application blocks
navigation to all other publicly hosted websites.

Governance (inc JML)

The access to the BrowserStack application is wholly controlled by the

DevTools Service Delivery Team. Users from all Barclays domains will go
through Request for a BrowserStack account. When a user places a request
for a BrowserStack account, the request would first need to be approved by
his/her line manager. Once the line manager has approved the request, a
designated administrator from the DevTools team would need to approve this

3
request. Once this has been done, an account for the user will be created
on BrowserStack. User accounts are created through an administration
console accessible through the application, which are then added to
teams/sub-teams. User accounts can only be created, modified or deleted by
a DevTools administrator. The account for the requestor is created using
his/her Barclays email address. The requestor is then notified to join
BrowserStack via email where they must set up a password.
While requesting for a BrowserStack account, users will need to attest that
they will use BrowserStack in accordance with Barclays’ IT Security
Policies and Standards. A link to the security policies will be made
available as part of the request.

Once access has been granted, all users will access the BrowserStack login
page to connect. Once connected, inactivity of 5 minutes will lead to a
teardown of the connection (see Fig 4) and the user must re-connect.

On learning that a user has left the organisation or no longer requires use
of the BrowserStack application, a DevTools administrator will remove the
user’s account on the BrowserStack application through the user management
page within 24 hours. Users who haven’t been using the application over the
period of a month will also be removed from the system on the basis that
access to the application is no longer required. This will also be managed
by a DevTools administrator. As part of the request process, users will be
notified that access permissions will be recycled on a monthly basis, and
inactive user accounts will be removed as part of this process.

The DevTools administration team will work closely with the BrowserStack
team to ensure that user actions are correctly logged and audited at all
times. This includes user sign in information e.g. the date and time that a
user last logged in to the system etc.

4
Architecture
Internal Architecture

The Barclays team by default will be forced to use a local testing

connection. This will be enforced from the BrowserStack back-end and hard
coded specially for Barclays users. Thus, any user within the Barclays team
will not be able to access publicly available websites. The only way to
test in BrowserStack will be via a local testing connection.

On accessing the BrowserStack application, users will have to log in using

their username and password. This will take the user to the main page where
he/she will be able to set up a local testing connection with a specific
operating system and web browser version, from a menu on the left hand side
of the page. Once this has been established, users will then be able to run
the test on the address specified by them, and the BrowserStack application
will establish a remote connection to the web browser and operating system
specified.

The remote connection that is made on the BrowserStack application will

then be routed through the Barclays proxy, which will thereby block access
to all restricted websites.

BrowserStack Architecture

Figure 1: BrowserStack Architecture

The BrowserStack Local Testing Setup has three main modules:

 The Connection Manager: Responsible for authenticating the user using

their access key and establishing a secure connection to the
repeater.

5
  TCP Level Proxy: This enables a TCP level connection between the
remote browser and local servers. This allows for testing of HTTPS
websites and technologies such as WebSockets.
 HTTP Server: This applies to local folder testing only. When the user
wishes to test local HTML design files, BrowserStack Local starts an
HTTP Server within the app on a random unprivileged (>40000) port.
This HTTP server has read-only access to the folder mentioned by the
user.

Connection Setup Process

Figure 2: Connection Setup

 BrowserStack Local makes a REST call using the user’s access key to
BrowserStack.com.
 BrowserStack.com chooses a repeater for establishing a secure
connection for Local Testing. This repeater exists within the
BrowserStack Architecture.
 BrowserStack.com supplies BrowserStack Local with the information
necessary to establish a connection to the repeater.
 BrowserStack Local initiates a connection to the repeater on port
443, using our custom SSL-encrypted protocol.
 A secure bi-directional and persistent connection is established
between the end user machine and the repeater. Secure WebSockets are
used as part of the communication framework.

The repeater cannot directly initiate a connection to BrowserStack Local.

The secure connection is only established up to the user’s machine. Neither
the repeater not any BrowserStack machine can directly access any local or
internal servers. Only the servers specified for establishing a Local
Testing connection, can be accessed through the app.

Data Flow Process

6
 Figure 3: Data Flow

 The user sends a request to BrowserStack.com to start the remote

browsing session.
 BrowserStack.com identifies a virtual machine from the cloud, and
allocates it to the user.
 BrowserStack.com instructs the repeater to connect to the virtual
machine in the cloud.
 The repeater sets up a secure, SSL-encrypted bi-directional
connection with the virtual machine.
 Requests from the remote browser are first routed to BrowserStack
Local, through the secure connections described in the previous step.
 BrowserStack Local then forwards these requests to the local server.
All responses are sent back via the same channel.

Teardown Process (Stopping Remote Browsing Session)

Figure 4: Stopping Remote Browsing Session

 The user sends a request to BrowserStack.com to end the remote

browsing session.
 BrowserStack.com instructs the repeater to sever the secure
connection to the virtual machine in the cloud.
 The repeater then severs the connection to and from the virtual
machine.
 BrowserStack.com takes the virtual machine offline, to securely erase
all user information. This ensures that the virtual machine does not
retain absolutely any information pertaining to the user’s session.

7
  BrowserStack.com confirms to BrowserStack Local that the virtual
machine has been disconnected.
 BrowserStack Local closes any open connections it had established to
the local servers, ending the local testing session.

Teardown Process (Stopping Local Testing Connection)

Figure 5: Stopping Local Testing Connection

 The user requests a teardown of the Local Testing connection.

Immediately, BrowserStack Local severs the secure connection with the
repeater. It also deletes all the information it had about the
repeater. Thus it cannot set up another connection unless the user
initiates it.
 BrowserStack Local informs BrowserStack.com about the disconnect
request.
 BrowserStack.com makes sure the repeater also closes the connection
from its end and deletes any information about the concluded Local
Testing Session.

Recommended Setup

Figure 6: Setup

BrowserStack Local is capable of establishing the Local Testing connection

through most enterprise proxy servers and firewalls. The app makes two
types of outgoing connections which may require special rules in the
enterprise proxy and firewall:

8
  Type 1: HTTP(S) requests to BrowserStack.com in the form of web
requests (when the website is opened in the user’s browser) and AJAX
calls (for setting up Local Testing) at port 80 and 443.
 Type 2: Secure WebSocket (WSS) connections to the repeater
(*.BrowserStack.com) at port 443.

The proxy server should support WebSockets and the CONNECT method to allow
TSL/SSL connections.