Role and permissions model

Hi @vsoch,

in the recent past we had some discussion about roles and permissions. I would like to use this thread to collect all related posts.

I think this is related with #57 and #73 (and maybe some more issues or PR)

This is a collection of thoughts I have about roles and end user management. As I don’t have a clear view of django permissions model, It’s not a direct mapping with django roles, only some suggestions based on my vision of this amazing tool.

First of all, I would like to enumerate the roles I would like to be provided from SRegistry (top to bottom approach):

1. Web admin
2. Content admin
3. Collection admin
4. Visitor

Then, some use cases for each role:

1. Web admin: (what I think is currently a superuser more or less)
   • He/she can provide content admin or superuser permission to other users
   • He/she can manage all collections/containers, push, pull and remove (like a super-Content admin involves all other roles)
2. Content admin:
   • He/she can create new collections
   • He/she can assign (or remove) Collection admin privileges for owned collections to other existing users
   • He/she can manage his/her owned collection as a collection admin
   • He/she cannot manage not owned collections
   • He/she cannot assign or remove superuser privileges
3. Collection admin
   • He/she can push containers to owned collections
   • He/she can pull private containers from owned collections
   • He/she cannot create new collections
   • He/she cannot pull private images from not owned collections
   • He/she cannot push images to not owned collections
4. Visitor
   • He/she can only pull public images

It also would be great if those things related with assign or remove actions could be done from the web interface from some settings buttons:

1. Web admin: The top-right menu shows a settings button. Clicking on it shows the whole list of users and he/she can assign or remove them Web admin or Content admin permission
2. Content admin: Each owned collection has a settings button. Clicking on it shows the list of Collection admins. He/she can remove permission graphically or can assign typing a valid username
3. Collection admin: can query his/her secret token
4. Visitor: can only navigate and see public collections from the web interface

This is a kind of a draft without not too much level of detail … What do you think about it?? Do you have something similar in mind?? Is someone else requiring this kind of roles?? I should directly use the issue-garbage-collector and move this issue to trash? 😃

Let me know your thoughts!

[vsoch]

Not yet, I’ll let you know (definitely within the next day or so!)

[vsoch]

I think what we want to do is think of permissions on a granular level, and then decide the groupings that go into each role.

• superuser: Is the easiest, because it’s just going to be the admin/web person that sets up the entire registry. They are god, have all the permissions, and can do anything. We can leave it at that.

For different objects in Django, each is associated with a permission to delete, create, etc. and it’s also the case that Django let’s us create “Groups” to handle different groups of permissions. So a good strategy would be to define permissions on a grandular level, put them into logical groups, and then assign users to one or more groups.

To be clear, permissions and authentication / authorization are separate. Authentication / authorization is largely handled by the superuser’s choice of what login backend to use.

Permissions

• assign permission (global)
• revoke permission (global)
• assign pull permission (specific or global)
• revoke pull permission (specific or global)

This first group of permissions is about managing permissions. The typical flow will be that when a new user is added, they are assigned a permission set (and no single superuser needs to assign or delete specific permissions), however if needed, the superuser should be able to do this.

Content

This second group I would assign to a group called “Content Admin” It’s what you get after you have been allowed to have an account, and you are allowed to create collections and containers. This would map nicely to Django idea of “staff.” A content admin is akin to a collection owner, as if a content admin creates a collection, that means he/she can create/delete/update both the collection and containers in it.

• create collection
• delete collection (specific or global)
• update collection (specific or global)
• create container (specific or global)
• delete container (specific or global)
• update container (specific or global)

Where “global” means “the user can perform the action for even other objects he didn’t create,” and “specific” refers to the collections that a user has been given permission to control. This means "the user can perform the action for only the objects he created.

Usage

Finally, we have permissions that aren’t about creating, deleting, or updating, but just using. If a container is public, then the pull does not need a token.

• pull container (global public)

I see no circumstances under which a non-authenticated user should be able to push. If it’s private, then it needs a token, and the token must be associated with a user who has been added to the group of users who are allowed to push or pull. This means that an authenticated user has the ability to do:

• generate token

When a user has permission to generate (and use) a token, then any collection owner can assign these permissions to the user:

• pull container (global publci)
• pull container (specific private)
• push container (specific public and private)

Groups

Now I’ll do akin to what @victorsndvg did, and talk about the Groups we would create (and assign people to) based on these permissions.

Superuser

has all permissions, can do anything, this maps to the Django superuser role. If we had to type it out

• generate token
• change collection privacy (global)
• assign permission
• delete permission
• assign any Group
• revoke any Group
• pull container (global)
• push container (global)
• create collection
• delete collection (global)
• update collection (global)
• create container (global)
• delete container (global)
• update container (global)

Content Admin

A content admin can generate collections and containers as well as interact with them, and can additionally grant content user’s the permission to be a Collection Admin.

• generate token
• assign Collection Admin Group
• revoke Collection Admin Group
• change collection privacy (specific)
• pull container (specific)
• push container (specific)
• create collection
• delete collection (specific)
• update collection (specific)
• create container (specific)
• delete container (specific)
• update container (specific)

Collection Admin

A collection admin can generate collections and containers as well as interact with them, but only can control those that he creates.

• generate token
• change collection privacy (specific)
• pull container (global public, specific private)
• push container (specific)
• create collection
• delete collection (specific)
• update collection (specific)
• create container (specific)
• delete container (specific)
• update container (specific)

Content User

A content user is primarily concerned with pulling or using containers. A content user has an account, and has a token to use the Registry. A token is not required for public images, and a token is required for private images.

• pull container (global public, specific private)

Visitor

And finally, NOT having any permissions we call a Visitor. The visitor can browse the registry (if the portal is web accessible to everyone) and view public collections. Public collections can be pulled, and that’s it.

• pull container (global public)

Discussion

The points outlined in the original post above look good, but I’m not sure about the idea that a Collection Admin (or anyone with a role greater than Content User) should not be able to create new collections. I don’t see harm in a user that is able to manage his/her collections also being able to create new ones. It would be a burden for the superuser / Content Admin to have to go out of his/her way to just create an empty collection.

Questions

• Should a token always be required for pulling, even public collections?
• If the interface is web accessible, should anyone be able to make an account to be a content user?
• For management, I think the Django default admin panel has a nice interface, but I need to check.

Thoughts? @dctrud pinging you in too, because I think you’ve done this before!