Expand my Community achievements bar.

Guidelines for the Responsible Use of Generative AI in the Experience Cloud Community.
SOLVED

Assets: Granular permissions to protect source content

Avatar

Level 1

Hi,

I have a client use case where Rights Managed content will be in Assets.  The client wants to flag the content with a Boolean metadata, when has rights =YES, they want to restrict users from accessing the source(originally uploaded file like a PSD), will display a "request asset" button that will trigger a workflow to fulfill the request. But still be able to download a watermarked FPO version. As far as I can tell if you have access to the node you have access to everything in it. This permission overall would be based on user groups. so Admins, librarians would not have this restriction.

This is one of a number of workflows that I see being able to leverage permissions within a node, as this Assets implementation will house master/production ready sources, that have rights and other restrictions like date based usage. Anyone out there have a solution?

Thanks!

1 Accepted Solution

Avatar

Correct answer by
Employee Advisor

So if we translate this requirement into technical terms, would it be sufficient to say that "the ability to read the original rendition should be based on a specific boolean property on the asset metadata"?

I haven't implemented it, but for me it seems, that you can build something along this requirement based on the example of the custom Oak restriction provider [1]. It's not a perfect 100% match, but it comes close enough to justify a test.

[1] https://jackrabbit.apache.org/oak/docs/security/authorization/restriction.html

View solution in original post

1 Reply

Avatar

Correct answer by
Employee Advisor

So if we translate this requirement into technical terms, would it be sufficient to say that "the ability to read the original rendition should be based on a specific boolean property on the asset metadata"?

I haven't implemented it, but for me it seems, that you can build something along this requirement based on the example of the custom Oak restriction provider [1]. It's not a perfect 100% match, but it comes close enough to justify a test.

[1] https://jackrabbit.apache.org/oak/docs/security/authorization/restriction.html