0016844: [Core] Afscherming op asset nivo mogelijk maken

[admin]

---

0016844: [Core] Afscherming op asset nivo mogelijk maken
 http://mantis.kennisnet.nl/view.php?id=16844

Momenteel kunnen alleen mediafiles afgeschermd worden en geen stills of assets.
Ook is het in de EGA instellingen mogelijk om in te stellen dat een EGA geen OAI informatie publiek geeft, maar graag zien we ook de mogelijkheid om assets af te schermen.

[Frans]

Parked at MediaMosa X.X

[Frans]

Check with MM 2.1

[Michiel.Schok]

I thought this was already implemented for assets:
the GET /asset/{id}/acl call is documented at http://mediamosa.org/node/218116, and there is also a POST call..
I have not done checking on the working of these ACLs.

For stills it's also possible to set and retrieve ACLs, but nowhere is code in MediaMosa that checks the ACL to see if a user has rights to the still: it is always returned.

[forgacs]

Related ticket: http://mediamosa.org/trac/ticket/515 (Master / slaving assets)

[forgacs]

Other related ticket: http://mediamosa.org/trac/ticket/39 ([Still] Geen still tonen wanneer asset is afgeschermd en je geen toegang hebt)

[forgacs]

Needs later discussion.
Postponed till MediaMosa 3.1.

[MC-arjen]

Not postphoned, but needs some discussion...

[Frans]

Needs some discussion indeed...

When there is an ACL on an asset it reflects all of the mediafiles, stills and metadata of the asset. In that way you could hide the asset metadata when an user doesn't match the ACL.

So also the METADATA itself is included in this issue.

[robert]

If we are going to hide the asset metadata and use ACL for 'hiding' the asset, then its a very heavy call on the MySQL database. I rather see a 'hidden' flag on the asset than solve it with ACL to hide the asset, deny access to the metadata, stills etc.

The discussion is needed is that we are reaching the threshold on performance on current ACL design. Although the ACL layer has been developed with Asset ACL in mind, we will have lots of performance issues with the new ACL extension. This is performance issue is now apparent when we where testing the code. The performance is still 'acceptable', but we are pushing the design and its limits. However, it will become faster if we don't use MediaFile? ACL and use Asset ACL instead when we are protecting all MediaFiles? anyway. That kind of ACL will not work if asset ACL will also prevent access to Metadata.

Solr will not have any extra performance issues as this ACL layer is completely different than MySQLs version.

[Frans]

The hidden flag will work fine and will keep the performance good, so agreed with this solution.
In the case where all of the mediafiles in an asset are protected, the asset ACL should be used to boost performance.

This will mean that the current dataset on VP-core should be changed to use this new design, but that would be a simple migration.

[Michiel.Schok]

This will mean that the current dataset on VP-core should be changed to use this new > design, but that would be a simple migration.

Well, I think the migration has to be performed when an EGA (as SURFmedia) is ready for the transition.

SURFmedia has to be changed to use /asset/acl call instead of /mediafile/acl call when reading or setting the ACL. When reading the ACL, we now use /mediafile/{id}/acl call on the original mediafile. When setting the ACL, we set the ACL on all mediafiles.

[MC-arjen]

 https://cacoo.com/diagrams/S4wZd5PQngiQruta

Some highlights from the third tab:

If an asset is protected: the still is also protected.

If an asset is protected: the metadata is also protected. In case of sensitive data this would make good sense. In this case the /asset [GET] call will give very limited asset details: (asset_id + created?), which will result in a grid view with very little to show. These assets can be hidden with the granted=true parameter as usual though.

extra parameter propossal : 'show_metadata' to show the metadata even if the asset is protected. In combination with the "granted_metadata" will give the choice to the application frontend what to do here.

[Frans]

Is not implemented yet.
Do we all agree with the choosen solution?

Frans: Ok
Marc:
Michiel:

Please hand in your votes.

[Michiel.Schok]

Michiel: I agree on the choosen solution with some minor remarks:

1. On the third tab at cacoo Arjen proposed an /asset?granted=true with the meaning of 'only return assets which are granted'. That is logical, but the opposite of the current implementation of MediaMosa. The /asset?granted=true is default (see API at http://mediamosa.org/content/search-assets-based-input-parameters-and-return-list-found-assets-0 ) . When granted=false is given as parameter it hides all assets where the user has no access to. All returned assets do have <granted>true</granted> in them. SURFmedia uses this call.
Think we have to create another parameter to cover all use-cases, and deprecate 'granted'

2. Robert sees huge impact on performance of /asset calls when implementing extra ACL possibilities. I'm not yet convinced that the new situation is better performance-wise: I see it as a risk.

[Marc Pluijmaekers]

Het gebruik van een flag lijkt ons by far de beste optie. Algemeen bekend is dat wanneer ACL’s gebruikt worden, de performance duidelijk minder wordt. Dit heeft er alles mee te maken dat er veel SQL JOINs gedaan moeten worden en MySQL is er berucht om dit bij een grote hoeveelheid niet efficiënt te doen. Het zetten van een flag is qua implementatie m.i. niet meer dan een extra metadataveld binnen dezelfde asset tabel. Performance impact nihil dus.
Wij (Kennisnet) zullen wel moeten inventariseren welke calls er op dit moment door voornamelijk Teleblik gedaan worden en dit houden tegen het nieuwe asset call ontwerp. Ik ga dit nu inplannen, maar een definitieve GO kan ik waarschijnlijk volgende week pas geven.

[forgacs]

Hi All,

I would like to continue the conversation of ticket #39 ("0016828: 4 [Still] Geen still tonen wanneer asset is afgeschermd en je geen toegang hebt") here, because that ticket is involved here too.

The current situation:
* At this moment we have a half ready asset protection layer.
* We have a well working mediafile protection layer (with performance issues).
* We have an idea from Arjen, that the asset is protected, if all the original mediafile is protected under that.
* And we have an another idea from Robert to use a "hidden" flag to hide the protected assets.

Possible developments:
* We can fix the asset ACL, but it is not performance friendly solution.
* We can use Arjen's solution, and the asset is protected, if all the original mediafile is protected. We can set (migrate) a "hidden" flag and take care of it. So it will always show the correct value.

We can introduce new parameters too: granted, granted_metadata, granted_thumbnail (default TRUE). If they are true, then the result will include assets (metadata, still images) where no access is available.
I see problem, when all the original mediafile are protected ("hidden" flag is TRUE) and when the users use granted fields (granted, granted_metadata or granted_thumbnail) with FALSE value. Because the mediafile protection can be different (domain, realm, group, user), then the users may have access to one of the original mediafiles, but not all of them. Then the application must check the user access on all the original mediafiles (till it finds one original mediafile with access). I think this is not performance friendly solution.

I think it would be the best to develop both solution for testing, but it would be a bigger development.
If I had to vote, then I think fixing the asset protection layer would be the better solution.

[forgacs]

Frans, Paul asked me to write here the current status of this ticket (and ticket #39), and reassing the ticket to you: The asset protection layer is prepared in the code, but it has known issues. It still needs additional development. Hiding metadata and stills images, hidden flag, granted parameters (eg. granted_metadata), show_metadata and show_still parameters etc. haven't been ready yet and the way we want to solve this ticket needs further discussion.

[Frans]

Moved to MediaMosa X.X, since this will need more discussion and development.