Security and Privacy Architectural Research
- 1 Overview
- 2 An Iterative Process
- 3 The Basic Use Case
- 4 User tokens
- 5 Provisioning/De-provisioning user tokens
- 6 Authorization
- 7 Monitoring
- 8 Resources and Research
- 8.1 OAuth 2.0
- 8.2 Alternatives to OAuth
- 8.3 Policy Formats and Tools
- 8.4 Questions, Concerns, and Things to Learn
- 9 Next Steps and Development Planning
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.
It's not a good idea to send always the same user token. We could "obfuscate" it. The idea is to add a passcode or an aleatory value to the original token, and once reach the preferences server get again the original token.
The idea is like Yubiko keys: http://www.yubico.com/products/yubikey-hardware/yubikey/technical-description/
Provisioning/De-provisioning user tokens
This is an issue not discussed. Who or What will deliver and revoke user tokens? The Security Gateway can deliver unique security tokens, and manage them as a central point.
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.
The figure above shows, in a very "artistic" way, what we have to do. It shows the scenario. First of all we have people with sensitive information (preferences) in a server (Preferences server). The user is the owner of this data (Resource owner), so he manage his data.
The user has to authorize what application or other users can access to his preferences (consent). This authorization can be a "binary" authorization (yes,no) or can be a more elaborated way. If the user wants a richer mechanisme, he can elaborate his own rules or policies in order to determine who or what can get access to his information. This rules are placed in the Authorization Server (or Gateway). These rules can have several paremeters, the app' name, user token, time, the device... in order to determine what application (client or consuemer) have access to his preferences and in what moment or context.
When a consumer app ( client) and the user using this app (relying party) want to get user preferences, this app (and the user) has to be authorized by the Authorization server based on the user rules or policies. The app negotiate with the Authorization server if it has authorization or not. The Auth server evaluate its policies and determine if the app has access or not, depending on the context established by the user the app will be authorized or not.
Here is another picture that shows the same thing in another way (and more Cloud4all-oriented):
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..).
We should have to monitor several information:
- The user
- From which applicaton
- From which network
- From which device
- The time
- GPS position?
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.
UMA (User Managed Access) is just such a profile of OAuth 2.0. The Scalable Privacy Project Accessibility team is exploring the suitability of an UMA approach for addressing GPII security and privacy requirements.
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 that the concept of an external policy framework (whether communicating with XACML, JWT or the like) is unhelpful 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 naturally expect from an "OAuth 2.0 profile".
Next Steps and Development Planning
Preferences Server Synchronization and Federation Goals
- we want to be able to support the use case where "private" Preferences Servers can be related to and synchronized with other Preferences Servers (e.g. the "global" or national instance)
- we need a means of defining a "hierarchy" or relationships between server instances, not unlike how Git allows us to define ad-hoc "upstream" and "downstream" relations between repositories
Identifying Consumers of Preferences Sets
- The "Preferences Server" will need to know who is making a request for a preference set on behalf of the user
- We assume that this will be accomplished using the OAuth idiom of consumers being issued a "secret" that will identify them securely to the Preferences Server
First Iteration of Solving the Security Problem
- We want to have a means by which "consumers" of the Preferences Server and Flow Manager are managed and explicitly granted access (instead of the current free-for-all)
- We want to enable users to create simple "policies" that will prevent applications from having access to portions of their preferences set
- The Flow Manager/Matchmaker infrastructure should be available as a web service in the cloud
- Web applications should be able to make a request for settings to this cloud Flow Manager and receive back only the information they're entitled to receive
Potential Technical Approach
- Refactor the Flow Manager to remove session state, etc.-- i.e. prepare it for cloud deployment
- Use an existing OAuth 2.0 library for Node.js (which one? are they any good?)
- (Keith) do sequence diagrams of the flows in "First Iteration" above
- Model solutions using the PUMA Python UMA/OAuth2 libraries to prove concepts
- (whole team) port Python based code to node.js and OAuth libraries