AuthZ - Add/Edit without Delete

[whikloj]

Title	Provide add/edit permissions while restricting delete capabilities
Primary Actor	repository manager, repository admin
Scope	access, interface, authorization
Level	Low
Story	As a repository manager, I want to allow groups to add/edit objects to certain collections in the repository but not delete/purge them.

---

Glossary Used

• Repository admin: a highly skilled Islandora user in charge of supervising repository managers. Examples include Scholarly Communications Librarians, Digital Archivists & Repository Developers.
• Repository managers: less skilled users trained to do specialized tasks on behalf of repository admins. Examples of repository managers may include staff at external orgs (such as a graduate school), internal staff, graduate assistants & interns.
• Add: To add a new resource to the repository.
• Edit: To edit an existing resource already in the repository.
• Delete: To completely remove a resource from the repository.

Examples:

• As a repository admin, I can create new collections and resources.
• As a repository admin, I can allow a group to have only Add & Edit permissions on a collection.
• As a repository manager, pursuant to the above 2 points I can add/edit resources in the collection, but I can't delete a resource (even a resource I previously added).

[ajs6f]

This seems quite odd to me, but I certainly believe that it's based on real examples. Can you give an concrete example, just to help me think about this?

[ruebot]

@ajs6f student employees.

[ajs6f]

Thank @ruebot , but that doesn't quite get me there. Is the idea that a student employee will have to get someone to help if they put something in a collection by mistake? Is the idea that a student employee can make as many things as they want and delete them as they want, but has to have authorization to add them to a particular collection?

[ruebot]

Is the idea that a student employee can make as many things as they want and delete them as they want, but has to have authorization to add them to a particular collection?

No. My understanding, and the current functionality that I use is: a student worker can add objects to collections that they have permissions in. And, they are not allowed to delete or purge any objects in the repository.

[ajs6f]

Okay, so the inbuilt assumption is that everything in a repo belongs to a "collection"? (Putting quotes there to indicate that the definition of that term is crucial.)

[ruebot]

Ah, I see what you're getting at. This is the discussion we were having the other day in irc, right? For now, my opinion is that everything in the repository should should be a member of something.

[ajs6f]

Cool-- yeah, what I'm trying to get it is just that that question (the one you just asked) is bound up with this use case. It's actually bound up in a lot of authZ use cases, which often make similar assumptions.

[ruebot]

That's a good thing to tease out, and make explicit :smile:

[ajs6f]

CLAW is the most explicit repository framework ever. It's positively indecent!

[DiegoPino]

😄 nick

"for now, my opinion is that everything in the repository should should be a member of something.".

To make that happen, there will be at least something that is not a member of something(root). And that leads to a "root" construct can not have the same rules as all other RDF resources. That could be weird if it's really some type of content, and not just a virtual creation. That is the only way i can think of we can avoid cycles.
Or we can allow cycles: which is also possible. Another solution is to allow at least one thing that is parent of nothing, this "super, para-root" resource like in fedora. Could be just and JSON-LD response on an arbitrary URL in Drupal that can be made the default parent for anything. Not a resource really, just a fictional URI with fixed RDF properties.

Now i'm confused and i guess it will confuse others 😄

[ruebot]

@DiegoPino right. there has to be one exception to it, or we hang everthing off of fcrepo root.

[ajs6f]

Or you allow cycles. Personally, I have no problem with cycles.

[whikloj]

So I don't want to get too hung up on the "everything in collections" side discussion.

I understand that a malicious user with "edit" permissions could erase all the data in an object, but this limitation is more to act as a safe guard against these student or temporary workers who may or may not get extensive training.

There are ways to restrict this type of behaviour from the Drupal side, but we will not be able to restrict it on the Fedora side.

So I guess this comes back to the limitations of WebAC. If I want to allow a user to edit a resource but not delete that resource, there is currently no way to deal with that level of granularity.

This is mostly important because if I say to my boss that everyone will now have delete permissions on anything they can edit, she may not be happy.

[ajs6f]

Has CLAW officially engaged with the people working on WebAC (not the Fedora people, the W3C people) to raise this issue?

[whikloj]

No and I'm not sure that there a) is anybody to engage with or b) whether I have a viable solution in mind.

When implementing WebAC in Fedora, the discussion was around how to map a WebAC permission to a repository permission. We (and by we I mean others) were able to attach them to the Modeshape permissions. Perhaps a refactoring could be done, but I remember that the issues around how to enforce these permissions across all the checks done within Fedora lead to this solution.

[ajs6f]

https://www.w3.org/wiki/index.php?title=WebAccessControl&action=history

Looks like mostly Henry Story and looks like he hasn't done much since January. Maybe we should check in with him?