<aut_group> ACL in combination with master/slave

[Michiel.Schok]

When an asset has an <aut_group> ACL and it is master-slaved using the <aut_app> ACL, we would like to use the group in the slave application.

so when we have
Asset A with mediafile M in app B, we set the ACL as
[post B] /mediafile/M/acl?aut_group=test&aut_app=C

When we do some requests from application B all is well:
[get B] /asset/A
...<granted>false

[get B] /asset/A?group=test
...<granted>true

[get B] /asset/A/play?mediafile_id=M&group=test
...success

But when we issue the same requests from application C we get:
[get C] /asset/A
...<granted>false

[get C] /asset/A?group=test
...<granted>false

[get C] /asset/A/play?mediafile_id=M&group=test
...no success

We do want master-slave to work in combination with groups, so when the calls from the slave are made, with the correct group, they result in correctly filled <granted> in search results and in playtickets instead of access denied errors.

Userstories for this ticket involve future use of the CSA (which uses master-slave) and Academia-material, where we now have an Identity Provider which cannot provide uniform emailadresses, which MediaMosa / VP-Core matches to the '@…' autorisation group.

[Frans]

Related to #32?

[robert]

Nee, #32 gaat over ACL op assets. Deze ticket gaat over dat ook usergroups via master-slave werken, dit is nu alleen via domain/realms mogelijk.

[peter]

Didn't make it to definitive set of must have issues for MM 3.0.

[Frans]

Peter,

this issue is very much relevant for us to be part of the 3.0 release.
Can you tell me what it needs to be a must have issue again?

[Michiel.Schok]

Is there any progress on this issue, can we expect this to be available in 3.0?

[forgacs]

I don't know why Peter changed this issue from "must have" to "should have". But the ticket is still "should have", and it wasn't implemented.

It is possible to fix this issue, but it still needs development.
The Acceptation server has got MediaMosa 3.0.0 (build 1698) already. We can implement this feature in the next MediaMosa release (build).

[Frans]

Peter,

We do need this issue to be in the 3.0 release, so I've promoted it again to a must have.
Can you give us an estimate on the fix?

[forgacs]

Michiel,

I have checked this ticket, and I have got a different result.

My test case:
Server: Acceptation

A: /asset/L1SjziNX6WXFe7RJhKSp7x1Y
M: /mediafile/oa9fNMDTEENThJlUPglKDHZo
B: app_id=1
C: app_id=10

[POST B] /mediafile/oa9fNMDTEENThJlUPglKDHZo/acl
aut_group=test&aut_app=10

[GET B] /asset/L1SjziNX6WXFe7RJhKSp7x1Y
=> FALSE

[GET B] /asset/L1SjziNX6WXFe7RJhKSp7x1Y?acl_group_id=test
=> TRUE

[GET B] /asset/L1SjziNX6WXFe7RJhKSp7x1Y/play?mediafile_id=oa9fNMDTEENThJlUPglKDHZo&aut_group_id=test
=> Success

[GET C] /asset/L1SjziNX6WXFe7RJhKSp7x1Y
=> TRUE (!)

[GET C] /asset/L1SjziNX6WXFe7RJhKSp7x1Y?acl_group_id=test
=> TRUE

[GET C] /asset/L1SjziNX6WXFe7RJhKSp7x1Y/play?mediafile_id=oa9fNMDTEENThJlUPglKDHZo&aut_group_id=test
=> Success

Would you confirm this behavior? If this wasn't a good test case, would you create a good one?
As I have checked production has the same behavior.

[Michiel.Schok]

Peter,

I couldn't find my notes on the exact asset_id for my experiment.
Probably I have used a 'real Academia' asset for it which also has the 'aut_domain=ACADEMIA.group', 'aut_realm=@…', 'aut_realm=@…', 'aut_app= 4, 5, 10x' ACLs defined on the mediafiles.

Therefore, in my experiment the base-access was denied (I didn't provide the correct realm or domain), which was OK, but when I presented myself as a member of the correct group, it stayed on access denied (which was not OK). The behaviour didn't change between calls. It denied calls *if the group ACL was present or not*.

In your case, only a group ACL was provided, and when checked from the slave, it granted access (providing group or not) as *if the group ACL was present or not*.

So, the similarity seems that aut_group ACLs don't go from master to slave, in your case and in mine.

I now have used (VP-Core acceptance) asset_id w2GfBM6jERAaiWObMLz1ATNi and mediafile_id v1KS4NKWVHBoKbUJOMZJZmPB for my experiments. Master is SURFmedia (app_id=5) and slave is NIBG (app_id=3). Better way is to turn it around, but I don't have the means to upload a 'real mediafile' to app_id=3, only to 5.

Have tried it first without the (@)ACADEMIA.group ACLs and got your behaviour, after that with (@)ACDEMIA.group ACLs, and got mine.

[forgacs]

Hour estimation (inclusive testing and bug fixing):

Creating new test for this issue: 3 hours
MySQL related development: 6 hours
Solr related development: 6 hours
Fixing the existing user-group with master-slave ACL tests: 3 hours

Sum: 18 hours

[forgacs]

Frans, We would like to close MediaMosa 3.
This ticket wasn't approved, and - because of this - we haven't developed the solution.
Would you change "Must have" to "Should have" for this ticket?