RBAC / ABAC for managed accounts

[aaronleopold]

Users should have control over what collections / reading lists other users have access to. E.g. User A can't access X library or media with the tag X.

- [ ] A user can control access of their reading lists / collections using tags and/or explicit sharing
- [ ] A server owner can control access of libraries, series

Update 10/01/2023

Very basic RBAC should be added for more top-level, server actions. See this comment for additional context.

[aaronleopold]

A coworker showed me https://www.osohq.com/docs today that I think is really promising for some of these kinds of fine-grained, access control features

[aaronleopold]

I've decided against oso, mostly because using it would enforce a pattern akin to query first THEN check RBAC, and I would much rather implement this in a way that allows me to apply RBAC rules to a query.

I have a rough pattern implemented in the reading list API that I feel is likely to get carried over to others as it applies:

/// Generates a single RBAC condition for a reading list query
pub(crate) fn reading_list_rbac_for_user(
	user_id: String,
	minimum_role: i32,
) -> reading_list::WhereParam {
	// A common condition that asserts there is a RBAC entry for the user that has a role
	// greater than or equal to the minimum role:
	// 0 for no access, 1 for reader, 2 for collaborator, 3 for creator
	let base_rbac = reading_list::access_control::some(vec![and![
		reading_list_rbac::user_id::equals(user_id.clone()),
		reading_list_rbac::role::gte(minimum_role),
	]]);

	or![
		// creator always has access
		reading_list::creating_user_id::equals(user_id.clone()),
		// condition where visibility is PUBLIC:
		and![
			reading_list::visibility::equals("PUBLIC".to_string()),
			// This asserts the reader RBAC is present OR there is no RBAC present
			or![
				base_rbac.clone(),
				// This asserts there is no RBAC present
				reading_list::access_control::none(vec![
					reading_list_rbac::user_id::equals(user_id.clone())
				])
			]
		],
		// condition where visibility is SHARED:
		and![
			reading_list::visibility::equals("SHARED".to_string()),
			base_rbac
		],
		// condition where visibility is PRIVATE:
		and![
			reading_list::visibility::equals("PRIVATE".to_string()),
			reading_list::creating_user_id::equals(user_id)
		]
	]
}

Effectively what I am doing is defining 4 roles and 3 permissions for reading lists:

roles: excluded, reader, collaborator and creator
permissions: read, read+update, read+update+delete

It get's a little more convoluted in this particular instance because of the visibility field, but overall this sort of pattern I think is good enough for other entities. Roles are represented as numbers, so comparisons can be done really easily. And roles for pretty much all entites stack, so each permission associated with lower-level role gets bundled with a higher-level role.

[aaronleopold]

I feel that, at least for the time being, the original intent for this feature can be superseded by the following:

1. Tag-based management and access Tag-based management system #151
2. Age restrictions (added in filter and sort feature branch https://github.com/stumpapp/stump/tree/al/filter-and-sort)

With those upcoming/recently added (respectively) features, I think the access control options are good enough for an initial release candidate. I’ll reserve RBAC for user generated content, like reading lists, book clubs, etc. I think expanding upon the two user roles (server owner and server member) could be good future work, as well.

[aaronleopold]

Reopening issue, I decided for the first release I want very basic roles and to not just solely rely on the access control methods I outlined in the previous comment.

I don't think I need to add something like Oso to the mix, I feel really basic server-level roles is acceptable. Resource-level roles would be a LARGE effort, and not something I personally want to implement. At least, not for the first release. If that is something that is really highly requested, I would reconsider at that point. The original description for this issue has been updated to reflect the current desired functionality.

[aaronleopold]

Development for this started with #120

[aaronleopold]

Foundation for this implemented in #186