Difference between revisions of "Security Gateway"

From wiki.gpii
Jump to: navigation, search
(How Will it Work?)
(Local Components)
Line 23: Line 23:
 
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.
 
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.
  
=== Local Components ===
+
=== Guarding against Privilege Escalation Attacks for Local Components ===
Local components of the system will be issued a shared secret when they are launched (by the Flow Manager). They will be required to provide this secrete on all subsequent calls to the Flow Manager. In order to address [http://en.wikipedia.org/wiki/Privilege_escalation privilege escalation attacks], components such as the User Listeners will be required to prove that they have equal or greater permissions than the currently logged in user.
+
Without further precautions, the communications bus used to coordinate local components of the GPII is vulnerable to [http://en.wikipedia.org/wiki/Privilege_escalation 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 might adopt 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 which they must provide on each communication with 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 scheme 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.

Revision as of 03:07, 23 April 2014

Note: This page documents the Integral Security Gateway. 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 integral modules (i.e. closely connected and running in the same runtime space) connected 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 contrast to the initial Prototype Security Gateway Overview that was sketched out in Cloud4all, the Security Gateway will consist of components that can be integrated with the real-time framework component that require these security features.

How Will it Work?

OAuth

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 might adopt 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 which they must provide on each communication with 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 scheme 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.