Ticket #500 (assigned defect)
<aut_group> ACL in combination with master/slave
|Reported by:||Michiel.Schok||Owned by:||Frans|
|MoSCoW:||Must Have||Estimated time after impact analysis:|
|Related to project:||none||Tested:||no|
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
[get B] /asset/A?group=test
[get B] /asset/A/play?mediafile_id=M&group=test
But when we issue the same requests from application C we get:
[get C] /asset/A
[get C] /asset/A?group=test
[get C] /asset/A/play?mediafile_id=M&group=test
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.