Distributed security: specification

[HerbCaudill]

When all data resides on a server, authentication and authorization are well-understood problems with lots of off-the-shelf solutions to choose from. The server acts as a gatekeeper between users and the data: If you don't have the correct credentials, the server just won't let you see data you're not allowed to see, or change it in unauthorized ways.

In a distributed architecture, where data is transmitted from peer to peer and there is no server acting as a central point of access, we'll need a different approach.

The purpose of this issue is to describe the problems of authentication and authorization in the context of Cevitxe's distributed collaboration framework, and specify the criteria that an acceptable solution must meet.

Scenario

Alice has created a Cevitxe repository: a staff database for an organization that does clandestine work.

Sample data

id	first	last	job_title	salary
123abc	Aldrich	Ames	Agent	88000
456qrs	Julius	Rosenberg	Agent	77000
789stu	Mata	Hari	Manager	99000
777xyz	Jonathan	Pollard	Mail Clerk	66000
666gwb	Valerie	Plame	Agent	101000
987qed	George	Smiley	Agent	77000

Roles

Each actor belongs to one of these roles:

Role	Read	Write*	Admin
hr	all	all	✔
it	all	all	✔
civilian-hr	all but agents	all
civilian-manager	all but agents	all but salaries
civilian	all but agents, salaries	all
auditor	all	none
connector	all	all

*An actor can only write data they can also read; in this column "all" really means "all visible".

Actors

Actor	Role	Notes
Alice	hr	created the repository
Bob	it
Carol	auditor
Dan	civilian
Eve	(none)	malicious external actor
Frank	civilian-hr
Gloria	civilian-manager
ImNotAServer	connector	always-on client

Requirements

Authentication

1. Authentication can be provided by a third party (e.g. OAuth2 via Google or GitHub).
2. An unknown actor like Eve should not be able to connect to the other actors at all.
3. For a new actor to access the dataset for the first time, they have to be online (obv).
4. Once an actor is authenticated, they can continue to use the same authentication token for N days, at which point it expires and they need to re-authenticate before they can synchronize with another actor.

Authorization

1. Administrative permissions: Only roles marked as admin can modify permissions, including designating other roles as admin.

2. Record-level permissions: Some people work in civilian support roles, some work as secret agents. Agents' identities are very sensitive information: Their records should only be visible to users with the appropriate clearance.

   For record-level permissions, not even the existence of the record should be divulged to actors that don't have read access to them. (For example, a civilian actor shouldn't even know how many agent records there are.)

3. Field-level permissions: Salary information is also sensitive, because the organization has not gone through the difficult but ultimately worthwhile process of salary transparency.

   For field-level permissions, it's OK for actors without read access to know of the existence of the field. (For example, a non-hr actor can still know that a salary field exists, even if they can't see any of the values.)

4. An actor's permissions must be enforced whether or not they're online.

5. An admin can update permissions for any role at any time, including adding, removing, or modifying any of its specific authorizations. The updated permissions will be replicated to all other peers (immediately or the next time they connect) and will be enforced as soon as they are received.

6. An admin can change an actor's role at any time. That change will be replicated to all other peers (immediately or the next time they connect). The affected actor's new permissions will be enforced as soon as they receive them.

Examples

Using the above sample data along with the given roles, here's what some specific actors should see.

• Read-only data looks like this
• Encrypted data looks like ☒☒☒☒☒☒

Carol

As an auditor, Carol can see all data but can't edit any of it.

id	first	last	job_title	salary
123abc	Aldrich	Ames	Agent	88,000
456qrs	Julius	Rosenberg	Agent	77,000
789stu	Mata	Hari	Manager	99,000
777xyz	Jonathan	Pollard	Mail Clerk	66,000
666gwb	Valerie	Plame	Agent	101,000
987qed	George	Smiley	Agent	77,000

Dan

As a civilian, Dan can't see anything about agents, and he can't see any salary information.

id	first	last	job_title	salary
789stu	Mata	Hari	Manager	☒☒☒☒☒☒
777xyz	Jonathan	Pollard	Mail Clerk	☒☒☒☒☒☒

Frank

As civilian HR, Frank can't see agents but can see and edit salary information.

id	first	last	job_title	salary
789stu	Mata	Hari	Manager	99,000
777xyz	Jonathan	Pollard	Mail Clerk	66,000

Gloria

As a civilian manager, Gloria can't see agents; she can see salaries but not change them.

id	first	last	job_title	salary
789stu	Mata	Hari	Manager	99,000
777xyz	Jonathan	Pollard	Mail Clerk	66,000

[nancyhawa]

I would add that it should be possible for an admin to revoke access that has been previously granted. (If someone leaves DevResults, they can no longer access our Asana or FreshDesk, including items they've already seen.)

[HerbCaudill]

yup that's a good point. I've added points 5 & 6 above.

[nancyhawa]

I'm also wondering about things like password reset flows. At the meeting, you talked about everyone having an encryption key. In most web apps I expect to have a password that is unique to me and that I can control.

[HerbCaudill]

including items they've already seen

Obviously there are limits to what you can do to retroactively conceal information from someone if you've already disclosed it to them!

[HerbCaudill]

I'm also wondering about things like password reset flows. At the meeting, you talked about everyone having an encryption key. In most web apps I expect to have a password that is unique to me and that I can control.

My thinking about authentication is that you'd have your identity verified by an OAuth2 provider - could be Google, or an organization's SSO, or whatever. Any keys you required would be derived by the software from your identity and used as needed - a user wouldn't normally see or know about their keys.

I'm drafting an outline of the solution I have in my head & I'll post that somewhere else for everyone to poke holes in it.

[brentkeller]

I realize that this is mostly a discussion for the specification of the situations that our authentication & authorization systems should cover but I'm wondering what research has been done in this arena. Surely there are papers or projects dedicated to authentication and authorization in distributed & peer-to-peer systems. I'll be very surprised if we're pioneering new ground here and I think that even bad examples/implementations should shed a lot of light on the possibilities of this working or not. I think it's worth spending some time trying to find existing evidence of this before we try to completely invent it.

Regardless of the authentication/authorization potential, my personal opinion is that there is an audience (even if it is not DevResults and we choose to just turn this over as a public OSS project) for a non-centralized system even if it only offers equal permissions for all members.

[HerbCaudill]

I've posted a draft approach in #38; to discuss.