Documentation Index

Work in Progress

Statement of mechanisms to protect data that are stored on the application server and transmitted to and from it.

• AS Application Server. The server that runs our application.
• PS Platform Server. The server running the learning environment that launches the application.
• AuthS The authorisation server. The server that holds asymmetric key pairs which it uses to secure connections between AS and PS by signing data blocks.
• LaunchP The 'Launch' protocol defined in the LTI 1.3 specification.

The HTTP protocol is implemented as requests from nodes on the Internet to other nodes on the internet which generate responses. The HTTPS protocol adds to that authentication of the nodes that respond and encryption of the data in both requests and responses while in transit. In this page the types of request are categorised as follows:

• Browser request - a request originating in the user's web browser targetted at a server.
• Automated browser request - as above but triggered by Javascript in a previous response or by a forwarding instruction in a previous response.
• Backchannel - a series of requests originating from a server targetted at another server.

Of the various ways data is transferred these are the ones relevant to this application

• Query string The data is placed into the URL of the request following a query symbol '?'. Although the whole URL is passed between client and server through an encrypted network socket it has a disadvantage because URLs are sometimes logged by web servers and cached in browsers. Data is stored in a additional locations potentially adding vulnerability. In this application no user or course related data is sent in query strings.
• Request Body For HTTP methods such as POST and PUT data is passed in the request body. The data is passed through an encrypted socket but is safer because it is not logged to a storage medium.
• Response Body The same security advantages as for request bodies. This is the only way that user and course data is returned in a response to a request.

A full list of network protocols used by the applications. (Does not reference network protocols that might be used by system adminisrators to manage the AS.)

Not used by this application.

All request - response communication uses HTTPS. To protect the security of communications the private keys paired with the public keys in the server certificates need to be kept securely on those servers. It also means that the copies of CA certificates stored on all servers and on user browsers need to be safe from tampering. I.e. standard security measures for web services and clients.

As a Java Web Applicaton this application accepts requests from HTTPS from browsers (both user initiated and automated browser requests) and from servers via backchannels.

The Application also acts as an HTTPS client in order to make backchannel connections to PS and AuthS servers.

This application can be configured to send email messages to users with CC to an administrator account via SMTP. This is for the purposes of record keeping and will not be used to transfer sensitive information. Currently the application does not implement authentication or encryption for SMTP and it is intended that the target SMTP server be on the same network and to be configured to accept incoming connections based on network topology. If the connection cannot be properly secured by configuring the SMTP server this feature should be disabled.

Official Specification

For a full description of the way data flow is secured consult the specification. Here is an abbreviated summary. The first step is the user navigating to a URI on the PS which is an LTI launch URI - a manual browser request. This is followed by a sequence of automated browser requests. When a server responds it can specify or otherwise arrange for data to be included in the next automated response and this enables server to server communication without the need for a backchannel.

• User requests LTI resource launch by selecting link in browser to URL on PS.
  • PS generates URL to AS containing information about the launch 'login'. Information about the requested resource and the application that provides it are encoded in a query string. This query string contains absolutely NO information about the user, or user account.
• User's browser automatically requests login page on AS.
  • AS generates a 'cookie check' page for the user. This page contains Javascript that checks that the user's browser support session only cookies. If the test fails an error message is displayed. Otherwise the browser is automatically instructed to load the same URL again but with an additional field in the query string indicating that the cookie check passed. Note The application currently doesn't use cookies at all but other applications typically do and this one might in the future.
• User's browser automatically requests the AS login page again.
  • AS creates a launch session data structure locally and assigns it a unique ID (a random UUID many bits long). It then generates a URL pointing at the AuthS with the same information provided by the PS with the addition of the AS's unique session ID and other fields that are needed to improve security. (For example a random nonce many bits long that is used to prevent replay attacks.)
• User's browser auto-forwards to the AuthS URL.
  • AuthS validates the information provided to establish that the PS is entitled to launch a resource on the AS and that both those other servers are genuine. Then it constructs a URL that will forward the user's browser back to the PS. This includes a query string that will help the PS associate this message with the correct user resource launch request.
• User's browser auto-forwards to PS URL
  • PS verifies the AuthS 'go ahead' message and if successful constructs a web page for the user. This page contains Javascript that constructs a URL to the AS's launch functionality and then auto-requests that URL. The request method is POST and data is sent in the body of the request concerning the resource that is requested, the user who needs access to the resource and how to open LTI backchannels to the PS (if any have been enabled by PS sysadmin.) Putting this data in the body of a POST request means that data will not appear in web logs and should not be visible to web proxies.
• User's browser auto-requests launch URL on AS
  • AS receives request and identifies the login session from the session ID provided. It also examines the data in the body of the request. This data is only accepted if it is digitally signed and the signature is verified using the configured public key for the AuthS. The session is marked as verified and a URL to the resource on the AS is constructed.
• User's browser auto-forwards to the resource on AS
  • The session ID is checked against a cache of active sessions and the resource is delivered if the session is marked as successfully launched. Session data will affect the presentation and functionality of the resource.
• User will make further requests on the AS to access its functionality.

This application complies with the specification. Three servers are involved in the launch process - the PS, AuthS and AS. If the PS is any installation of Blackboard Learn then the AuthS must be developer.blackboard.com. This is enforced by Blackboard software.

Currently the application has only been tested with Blackboard Learn as the PS which means that the AuthS will always be developer.blackboard.com. That server holds current asymmetric key pairs specifically for use with this application. Our application stores a copy of the public key set and the AuthS users the private key to digitally sign certain important blocks of data used in the launch process.

This application verifies the signatures on signed data using the public key obtained from developer.blackboard.com.

It is possible to manually add public keys originating from AuthS to the AS configuration for use in the LTI launch process. It is also possible to fetch them automatically with an HTTPS request. The IP number will be resolved using the AS's configured DNS service and the digital certificate of the AuthS will be verified - meaning that a reputable server certificate supplier must have supplied a valid certificate with the correct domain name.

In LTI 1.3 the "Advantage" specification defines how a PS can declare to an AS at launch time that it offers REST-like functionality and provides some specific URLs as entry points.

There are a limited number of 'standard' services with specifications defined on the IMS web site. This application makes use of one of these services to obtain a list of students enrolled on a course from which a peer group assessment tool was launched.

This application complies with the specification for authentication. This involves opening a backchannel to the AuthS to obtain a one time use authorization token followed by accessing a backchannel on the PS to actually exchange data as defined by the service.

The PS will also open a backchannel to the AS to access a set of its public keys for data signing. It will obtain the correct URI of for this backchannel from the AuthS and will check the server certificate before completing the download.

BB Rest API Specification

This is not defined by LTI but is rather a proprietory API provided by Anthology for their Blackboard Learn product. It is implemented as a set of URIs on the PS. The AS initiates a backchannel connection to first obtain an authentication token. Then, subsequent requests to the API include the token in request headers.

The PS system administrators have to enable this backchannel and can configure a user account which will be used to determine in fine detail which facets of the API can be accessed. A list of required permissions are detailed in a later section of this page.

All URLs presented to users will use the HTTPS protocol. All hosts must present server certificates that will be successfully verified by popular browser software using the standard supplied set of CA certificates.

When the AS connects directly to DTPs it will use its configured DNS service to resolve the IP number. It will only trust that IP number if the server certificate presented contains the correct server name and verifies using the standard CAs bundled with the Java runtime that is used to run the AS software.

Further development could add further restrictions if deemed necessary. For example, a shorter list of CA certificates could be selected.

To implement some functionality the AS connects to the PS using the Blackboard Learn REST API. The PS system administrator sets up a user account and associates that account with the application ID. When the AS connects it operates on the REST API with the permissions settings of the assigned user account. There are 479 available permissions. Of these the permissions required for this application are:

To see certain privileged fields in course search results.

To see certain privileged fields in organization search results.

To find enrolments for a particular user ID.

To make it possible to enrol user in role other than �student�.

To create new enrolments.

A detailed report on how they are transmitted between PS, AS and AuthS and whether they are stored by the AS.

• Name

  • From PS
  • Mechanism LTI Launch (the user) AND LTI Backchannel (students in course)
  • Encryption HTTPS including browser (LTI launch); HTTPS server to server (backchannel)
  • Authenticity Assured by CA verification of source server.
  • Storage Yes - within web app secure directory on AS file system.
  • Displayed to Users Yes
  • Sent to Servers No

• UUID (Generated by PS uniquely for each created user. Many bits long, extremely hard to guess.)

  • From PS
  • Mechanism LTI Launch (the user) AND LTI Backchannel (students in course)
  • Encryption HTTPS including browser (LTI launch); HTTPS server to server (backchannel)
  • Authenticity Assured by CA verification of source server.
  • Storage Yes - within web app secure directory on AS file system.
  • Displayed to Users No
  • Sent to Servers Yes. Sent to PS backchannels to implement functionality, e.g. enrol user on course.

• Login Name (Username)

  • From PS
  • Mechanism LTI Launch - it may presented by PS but is not requested or needed by AS
  • Encryption HTTPS via browser
  • Authenticity N/A
  • Storage No - neither in Java heap nor file system.
  • Displayed to Users No
  • Sent to Servers No

• Password

  • From Never requested, offered or stored.
  • Mechanism N/A
  • Encryption N/A
  • Authenticity N/A
  • Storage No
  • Displayed to Users No
  • Sent to Servers No