Security and privacy

Security and privacy are essential, cross-cutting concerns of the Cloud4all/GPII architecture. The primary responsibility for enforcing system security and user privacy rests with two components: the FM, which mediates the channels by which user information is transferred and manipulated, and the Authorization Server, which contains the necessary logic for granting and validating application and access credentials, limiting access to sensitive data stored within the system (such as the “raw” Preferences Server), and limiting access to a user’s N&P based on their personal privacy policies.

Orchestrating Security

The FM, as the central component responsible for integration and communication amongst all other components in the Cloud4all/GPII architecture, is responsible for maintaining system security and user privacy. It does so in cooperation with the Authorization Server and other key components of the security infrastructure. Specifically, the FM is responsible for:

  • Securing the REST end points that enable other components to retrieve or edit a user’s preference set
  • Delegating to the Authorization Server to apply user-defined privacy policies that prohibit access to certain parts of a preference set prior to sharing them with other components in the system
  • Challenging out-of-process, locally-installed components of the system (such as User Listeners) to provide shared secrets that will help prevent privilege escalation attacks (as described in (Cloud4all, 2015)).
  • Providing event-based APIs that can be used to monitor and log activity within the Cloud4all/GPII real-time framework

The Authorization Server

The Authorization Server is responsible for implementing an OAuth-based authentication and authorization workflow that includes:

  1. Confirming that the user has granted access to their N&P set by a particular requesting application
  2. Filtering the contents of the user’s N&P sets based on their privacy policy (using the Transformer APIs)
  3. Checking the user’s credentials prior to allowing access to view or edit critical parts of a user’s N&P set such as their privacy policies
  4. Registering, identifying and authorizing “Tier 1” applications (such as the local Flow Manager and PMT) prior to allowing access to secure parts of the architecture such as the Preferences Server
  5. Rendering easy-to-understand user interfaces that allow a user to approve or deny access to their preferences sets, and to specify privacy policies when they do so