Security Gateway

From wiki.gpii
Jump to: navigation, search


This page documents the integral security gateway components. For more detail about the overall architectural approach for security and privacy in the GPII, see Security and Privacy. The GPII OAuth 2 API is documented in detail in the GPII OAuth 2 Guide. For information about the legacy, standalone security gateway prototype, see the Prototype Security Gateway Overview page.

What is the Security Gateway?

The security gateway is a series of integrated modules connected (in the same runtime space) to the Flow Manager, Preferences Server, and Solutions Registry components of the real-time framework. These security modules perform the following responsibilities:

  1. Registering clients of the real-time framework (e.g. third-party web applications that are consumers of user preferences/settings)
  2. Validating the identity of remote clients of the real-time framework (i.e. the applications above) at every request
  3. Validating a remote client's authorization to retrieve preferences/settings on behalf of a user
  4. Validating the identity of local components of the real-time framework (e.g. user listeners)
  5. Filtering a user's preference set based on declarative policies specified by the user (using a tool like the PMT)
  6. Integrating with third-party identity management tools and directories (e.g. a library's patron LDAP database)
  7. Logging requests throughout the system in the form of a security audit trail

In contrast to the initial Prototype Security Gateway Overview that was sketched out in Cloud4all, this security gateway will consist of components that can be integrated with the real-time framework component that require these security features.


The architecture delineates two different tiers in which components are located:

  1. Direct clients of the Preferences Server, which are restricted to components that have been reviewed and vetted by the GPII security and privacy working group
  2. Third-party applications and other components within the system, which always access a user's preferences and settings via the Flow Manager

To be clear, this means that most components and applications that want to access a user's preferences and settings must do so via the Flow Manager, not the Preferences Server directly. Currently, Tier 1 access is restricted to the Flow Manager, the Preferences Management Tool, and the Settings Snapshotter.

Both the Preferences Server and the Flow Manager will implement OAuth-based authentication. Client secrets for the Preferences Server will only be distributed to components that have been vetted and code reviewed by the GPII security and privacy working group. All remote (i.e. web or cloud-based) applications registered in the Solutions Registry will be given a client secret for the Flow Manager.

How Will it Work?


We will use OAuth to register and validate remote clients. All web-based solutions that are registered with the Solutions Registry will be issued an OAuth client secret. This secret must be provided with each request the application makes to the Flow Manager. OAuth will also be used to verify that an application is authorized to act on the user's behalf. When a user approves an application to access their needs and preferences set, the application will be given an access token for that user.

Preference Set Security Policies

A user will be able to approve or deny access to their preferences set by each application. They will be able to approve access to particular scopes. A scope in this context represents a collection of their user preferences (probably based on some hierarchical ontology, for example "screen reader settings" and so on). The user will be able to define "rules" about which aspects of their NP set an application can access using a UI such as the Preferences Management Tool. These rules will be structured as JSON-based Transformer rules, and will be enacted at the Preference Server's point of response.

Guarding against Privilege Escalation Attacks for Local Components

Without further precautions, the communications bus used to coordinate local components of the GPII is vulnerable to privilege escalation attacks. These components are mostly constituted by the user listeners which the Flow Manager uses to detect the presence of a particular user at or near the machine - e.g. the USB or RFID user listeners. There are two main approaches we are considering to guard against these:

Shared secret model

If we can arrange that all local components of the system are launched by the currently running Flow Manager, we can also arrange that they are provided with an initial secret at launch time. They must provide this secret on each subsequent request to the Flow Manager (or when initiating a session of the standard HTTP form). This model requires that i) the Flow Manager has a longer lifetime than the components which it executes, and ii) that the executed components are launched only from paths which are known to be trusted - that is, which could only be installed by a user with administrative privileges.

Demonstrated capabilities model

Another approach for guarding against these attacks is to require the local components to prove that they have permissions over the currently logged-on user's resources at an equal or greater level than the user themselves. One workflow would be for the Flow Manager to challenge the component when initiating a session with a randomly constructed secret together with a filename. The component would then create a file with the contents of a secret with the given name, in a directory which had previously been constructed to be writeable only by the currently logged-on user. On reading this file, it would then be proven to the Flow Manager that the initiator of the session had the appropriate privilege level.

How Will the Security Gateway be Implemented?

The Security Gateway will be comprised of a series of Node.js-based components written in JavaScript that can be directly linked via Inversion of Control configuration to the Flow Manager and Preferences Server.

The advantages of this approach include:

  1. Significantly reduced remote messaging overhead in comparison with the legacy, standalone security gateway prototype
  2. Simpler deployment and administration
  3. The ability to add tailored authentication support to any GPII-based component

Development Priorities

  1. Implement OAuth for the Flow Manager, integrating it with the Solutions Registry
  2. Implement OAuth for the Preferences Server and migrate all third-party applications to the Flow Manager
  3. Implement a transformation stage in the Preferences Server so that preferences sets are filtered by the user's security policies
  4. Define storage and a REST API for preference set security policies (closely integrated with the preferences server itself)
  5. Create a simple user interface for defining security policy rules, and integrate it into the PMT
  6. Implement an account creation and login system for the GPII, and integrate it with the PMT
  7. Implement a system for preventing local component privilege escalation attacks
  8. Implement token indirection so that users can deprovision physical login devices