Security and Privacy Architectural Research
- 1 Overview
- 2 An Iterative Process
- 3 The Basic Use Case
- 4 Authorization
- 5 Monitoring
- 6 Resources and Research
- 6.1 OAuth 2.0
- 6.2 Alternatives to OAuth
- 6.3 Policy Formats and Tools
- 6.4 Questions, Concerns, and Things to Learn
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:
- is understandable, safe, and secure
- will not share preference sets with applications and services that are not authorized to access them
- does not inadvertently leak information about the user
- protects the anonymity of the user if desired
- gives users autonomy over their information; users should have control over who has access to their preference set
- 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.
The solution has to follow this schema:
There is a requesting party managing a client, for instance, any web application in the Cloud4all project. This web application wants access to a resource server, for instance a Preferences Server in the Cloud4all architecture. This server contains user preferences, and these preferences are managed by their owners. At the same time, the resource server (Preferences Server) is protected by an Authorization server or, in Cloud4all terms, the future Security Gateway.
(Marcel, can you elaborate on why the solution has to follow this schema? If you are proposing a particular approach, it's important to outline the motivations and advantages of it so the rest of the team understands your ideas.)
In computer security, specifically in Access Control systems, we have the concept AAA (Authentication, Authorization, and Auditing or Accounting). So, any access control system should have a monitoring system. The gateway has to monitor how many requests, how many "permits" or "denies" deliver, etc...
So, we have to consider customizable monitoring systems for access control apart from ordinary system performance (workloads etc..).
Resources and Research
- node-oauth2 library
- The OAuth 2.0 IETF Specification
- A Real World Explanation of OAuth
- OAuth 2.0 and the Road to Hell
Alternatives to OAuth
Policy Formats and Tools
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.
Speculations about simplifying the workflow inherited from OAuth 2.0
Certain aspects of our problem, as well as parts of the overall GPII architecture that are already solved by our existing work, may lead to a much simpler workflow and usage of the underlying protocols we may need to adopt. As observed in the previous section ("The Preference Set is our Primary Resource"), we only expose to 3rd parties such as "Fazebuch" one single resource, which is the portion of the relevant user's preference set which is authorized to be shown to them. This suggests a number of special points -
- That we might well bypass the entire "access token" stage of the OAuth protocol entirely - in terms of "ACT 2" of the "OAuth dialog" on the page linked above, "How does OAuth 2.0 work in the real world", as soon as the App presents the Authorization Server with the Authorization grant, it could be DIRECTLY presented with the user's preference set, already suitably filtered, rather than going through any of the further rounds involving the access token. This would seem to bypass an annoying and widely vilified part of the OAuth spec, the system of "refresh tokens", "bearer tokens" etc. by which Apps are granted time-limited access to resources, potentially verifiable in a way that doesn't require access to persistence on the part of the Auth server. Presenting the preference set itself rather than the access token in response to the auth grant presentation could be a helpful simplification, if we could persuade ourselves we understand all the implications (whether for interoperability or security etc.)
- It would seem we are positively hostile to the concept of an external policy framework (whether communicating with XACML, JWT or the like) since in our use case, we would like the 3rd party (requesting party, Fazebuch) to be positively ignorant of what access the user has granted to their preferences - since any information about policy other than that which is already implicit in the filtered preferences document could only represent a further leakage of information about what other preferences exist. It appears that the entire "policy framework" system is intended to convey some kind of intelligible model for what the user's policy has been toward the protected resource, either so that the requesting party can present some kind of UI summarising this policy, or else can operate logic in its own application code performing processing with respect to this policy. However, given we view this kind of "policy escape" as unnecessary and possibly even dangerous towards the security goals of the GPII, it would seem we have no place in our architecture for such an "externalised policy document" - all policy would be operated internal to the GPII "realtime framework" by means of the existing "Model Transformation System" which would filter the user's preferences document before forwarding to the requesting party. All UI and processing logic dedicated to this function would be on the inside (protected side) of the Authorization Server.
We should consider whether these points are either realistic or indeed correct, and evaluate what savings in infrastructure and implementation cost they could realise. Given OAuth 2.0 itself offers poor expectations of interoperability in any case, it seems that these modifications to its workflow could be accommodated without compromising the interoperability one would naturaly expect from an "OAuth 2.0 profile".