Difference between revisions of "Security and Privacy Architectural Research"

From wiki.gpii
Jump to: navigation, search
(The Basic Use Case)
m (The Preference Set is Our Primary Resource)
Line 50: Line 50:
 
==== The Preference Set is Our Primary Resource ====
 
==== The Preference Set is Our Primary Resource ====
  
Given the nature of the Cloud4all architecture, we have a small number of resources that need to protected. Really, it's just one&emdash;the user's preference set. From there, we have substantial tools for transforming and filtering data built into the Cloud4all framework, which are being used throughout most of the other components including the Matchmakers. We need to ensure that any security/privacy/authorization system is compatible the rest of this framework. We'd like to ensure that we can choose to deploy the security/privacy/authorization infrastructure either as a Node.js library that can be directly linked to the Prefs Server runtime or optionally deployed as a standalone gateway server.
+
Given the nature of the Cloud4all architecture, we have a small number of resources that need to protected. Really, it's just one—the user's preference set. From there, we have substantial tools for transforming and filtering data built into the Cloud4all framework, which are being used throughout most of the other components including the Matchmakers. We need to ensure that any security/privacy/authorization system is compatible with the rest of this framework. We'd like to ensure that we can choose to deploy the security/privacy/authorization infrastructure either as a Node.js library that can be directly linked to the Prefs Server runtime or optionally deployed as a standalone gateway server.

Revision as of 09:59, 26 June 2013

Overview

We're currently in the midst of designing an architecture to support security and privacy within the Cloud4all/GPII framework. This page is the place where we're documenting notes, ideas, resources, and code along the way.

An Iterative Process

Our goals for security and privacy within Cloud4all/GPII are large and ambitious; we want to provide users with an environment that:

  1. is understandable, safe, and secure
  2. will not share preference sets with applications and services that are not authorized to access them
  3. does not inadvertently leak information about the user
  4. protects the anonymity of the user if desired
  5. gives users autonomy over their information; users should have control over who has access to their preference set
  6. meets the user where they are, enabling them to connect with a wide variety of applications and services

The Basic Use Case

Todd is an avid user of Fazebuch, a social networking site where he can connect with family and friends, sharing pictures, links, and his daily status. Fazebuch offers a variety of user interface personalization options, including support for high contrast, large print, simplified pages, and a built-in reader.

From the technical perspective, Fazebuch has already been registered as an official "GPII application consumer," and possess a secure application token that identifies it to the GPII. This is used by the web-based Flow Manager to recognize Fazebuch's capabilities and match them with Todd's needs and preferences.

Todd has recently set up a preference set with the GPII using the Discovery Tool. He now wants to connect his Fazebuch account up with the GPII so that will automatically display simplified pages and include the reading tool every time he logs in. Via his settings page, Todd agrees to allow Fazebuch access the "easier to read" portion of his preference set.

Technically-speaking, the GPII will provide Fazebuch with a unique user token that it can use to retrieve Todd's preference set via the Preference Server's RESTful user interface. The Preference Server will automatically recognize that Todd has only granted access to a portion of his preference set, and will share only that portion with Fazebuch.

Resources and Research

OAuth 2.0

Alternatives to OAuth

Eron Hammer's Oz

Policy Formats and Tools

JSON Web Token

Questions, Concerns, and Things to Learn

OAuth 2.0 Interoperability

Through our research, it's becoming clear that OAuth 2.0, in itself, is insufficiently specific for real interoperability. So we will have to define a "profile" of OAuth 2.0 that we will implement. To start, our goal is to enable a simple workflow where applications can register themselves as consumers, and users can authorize a consumer to access their preference set from the Preference Server.

The Role of Policy Frameworks

We do not yet know exactly what approach to take when it comes to defining access to subsets of the preference set. While XACML, SAML, and JWT (JSON Web Tokens) may provide options for us to use when defining and sharing policies, we also need to harmonize this with the GPII framework's Model Transformation library. The key question we still need to answer is, "why do we need a public and visible policy format," as opposed to doing this within a system of "views" within the Preference Server?

The Preference Set is Our Primary Resource

Given the nature of the Cloud4all architecture, we have a small number of resources that need to protected. Really, it's just one—the user's preference set. From there, we have substantial tools for transforming and filtering data built into the Cloud4all framework, which are being used throughout most of the other components including the Matchmakers. We need to ensure that any security/privacy/authorization system is compatible with the rest of this framework. We'd like to ensure that we can choose to deploy the security/privacy/authorization infrastructure either as a Node.js library that can be directly linked to the Prefs Server runtime or optionally deployed as a standalone gateway server.