Auth0 FLAC user stories

[kozbo]

Investigate

• Create user stories
• What is our MVP?

As an admin I would like to restrict access to files and or bundles or projects to a particular group or individual As a user I would expect to be able to access data that I have permission to, and not data that I am restricted from

[chmreid]

As an admin, I woud like to restrict public access to a resource (project/bundle/file).

As an admin, I would like to explicitly grant permission to access a resource (project/bundle/file) to a principal (user/group).

As an admin, I would like to be able to grant specific principal (user/group) access to all versions of a resource.

OPTIONAL: DISCUSS

As an admin, I would like to be able to grant specific principal (user/group) access to a particular version of a resource (project/bundle/file), while leaving other versions protected.

[chmreid]

As a user, I would like to be able to access any data that is public.

As a user, I would like to be granted access to data I have permission to access.

As a user, I would like to be denied access to data I do not have permission to access.

[chmreid]

To digest this into an MVP, the FLAC mechanism should do the following:

• Should allow admins to specify what resource to protect, by specifying a UUID (and optionally a version - DISCUSS)

• Should take at least three, possibly more, arguments:

  • UUID of resource to protect
  • version of resource to protect (DISCUSS)
  • name or ID of principal to grant access to (principal ID, common to users and groups)
  • type of principal to grant access to (user or group?)

[chmreid]

To discuss at next standup:

• should we provide FLAC using UUID only (easier/less time-consuming) or should access control include version numbers/FQID too (more comprehensive/more time-consuming)

• can we use UUIDs to identify groups/users, and if not, how to grant permission to groups vs users

• is this ticket ready to close so we can start working on implementation

[kozbo]

yes, let's discuss. Is there a priority to these use cases?

[chmreid]

@kozbo IMO - yes, there is, the top priority should be providing FLAC based on UUIDs only. This keeps the FLAC implementation as simple as possible.

Version-specific FLAC would be a little more complicated to implement, and we don't have a specific customer asking for that requirement. Since any new customers would force us to revisit auth anyway, we can expand the FLAC system as needed at that time.

[chmreid]

Based on discussion at 2020-02-14 architecture meeting, here are the amendments we made to the above user stories:

• Above user stories left off a few important operations (write operations); reframe things in terms of CRUD operations
• FLAC database: keys are UUIDs (only, no versions) and values are package containing three fields: allowed users, allowed groups, allowed roles
• Including users, instead of just groups + roles, is important for create/update/delete operations ("owners" of data)
• Focus on making the user stories match the implementation, so that the implementation does not become overcomplicated

[chmreid]

Create:

• Any member of an organization can upload/create data

Read:

• Resources/data are public by default
• Resources/data can be restricted access by adding them to FLAC table

Update:

• Need read and create access to update a bundle
• Admins can update bundles

Delete:

• Only admins can delete bundles

[chmreid]

API endpoints that we are protecting (from swagger_auth.py script):

default_auth = {"/files/{uuid}": ["put"],
                "/subscriptions": ["get", "put"],
                "/subscriptions/{uuid}": ["get", "delete"],
                "/collections": ["get", "put"],
                "/collections/{uuid}": ["get", "patch", "delete"],
                "/bundles/{uuid}": ["put", "patch", "delete"]
               }