Why is the role ROLE_ANONYMOUS mandatory for logging into Opencast ?

[Ruth Lang]

Hi,

we have defined groups for LDAP users to give them different access to certain parts of the adminUI.

But in all groups I have to add ROLE_ADMIN_UI (which makes more or less sense), but also ROLE_ANONYMOUS.

What is the reason for that in the adminUI ?

Even if this role is needed to "show" the login page (a fact which I as an adopter also do not understand),

this role could/should be removed after a successfully login into the adminUI.

After the migration many of our series and events are available to everybody in the adminUI, 

because they have attached the role ROLE_ANONYMOUS.

These media received this role to make them public in the engage node and 

to allow an integration in a web-page (otherwise Opencast player would not play them).

But it was never the intension to show each detail to everybody in the adminUI.

Regards

Ruth

_______________________________

Universität zu Köln

Regionales Rechenzentrum (RRZK)
Weyertal 121, Raum 4.08
D-50931 Köln

[Greg Logan]

Hi Ruth,

If I remember correctly, the security layer assumes that there is at least one role, and that role needed a name. ROLE_ANONYMOUS was chosen as a least-permissions setup. I don't think there's much that explicitly requires that role (/info/me.json comes to mind) by default so it should be safe to include everywhere. 

G

--
You received this message because you are subscribed to the Google Groups "Opencast Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to users+un...@opencast.org.

[jcande...@googlemail.com]

Hi,

same problem: ROLE_ANONYMOUS is attached to our events to be public available in the engage node and embedding codes. Now, our series and events are available to everybody in the adminUI...

A decent approach would be if the admin ui lists only events with write access for the current user, but this seems not to be possible....

We had the idea to replace the ROLE_ANONYMOUS in all access rules to /admin-ng/* with a AAI role (we use shibboleth) and remove the ROLE_ANONYMOUS from our users and its auto-assignment from the AAI loginhandler (patch for testing), so that the ROLE_ANONYMOUS can be kept attached to the events and our admin ui users simply do not have the ROLE_ANONYMOUS, thus won't have all the public recordings in their event view.

However, it does not seem to work as the anonymousFilter in mh_default_org.xml always injects ROLE_ANONYMOUS to each an every user. Disabling the filter for testing still does not work - another filter in chain or RoleProvider seems to do the same. 

So, what is the right approach to let editors see only their events but not all the events with ROLE_ANONYMOUS?

Any help is greatly appreciated!

br

Harald