Assigning a user to a certain "ROLE_GROUP_<name>" role does not really put the user in such group

Steps to reproduce

Steps to reproduce:

1. Create a new group "My Group" with the following roles:




    2. Create a new user and assign the role "ROLE_GROUP_MY_GROUP" to it.
    3. Log out and try to log in as the user created.

Actual Results:
The user is redirected to the engage UI, indicating that it does not have the roles assigned to the group "My Group". However, the "ROLE_GROUP_MY_GROUP" should be equivalent to belong to the group "My Group"

Expected Results:
Either the group should be updated to reflect that the user now belongs to it or the "group roles" like "ROLE_GROUP_<groupname>" should not be selectable in the admin UI. In the latter case, an alternative mechanism should be provided to assign a certain user to a certain group while it's being created.

Workaround (if any):
Include the user in the group "My Group" from the "Edit Group" section in the admin UI


Sven Stauber
January 24, 2017, 10:37 PM

Maybe we have to define what Opencast groups are used for since there are two different aspects how groups are used for authorization:

a) Authorization in means of access to content (involving ACLs)
b) Authorization in means of access to functionality (not involving ACLs, involving role-base visibility & Sprint Security)

a) means that all members of the group get the group role (ROLE_GROUP_*) so that this role can be set in ACLs and will affect both members of the group and everybody else that has this role.
This works well with external authorization systems (e.g. LDAP) since those can assign the group role directly to the user externally (without the need of being part of any group).

b) means that group membership implies that ownership of roles not relevant for content access but relevant for access to functionality (e.g. ROLE_UI_, ROLE_API_)
This currently does not work with external authorization systems (e.g. LDAP) since Opencast groups are supposed to be an internal authorization mechanism involving internal data structures.
This could, however, be solved easily be delegating b) to the LDAPUserRoleProvider (that's the LDAP-attribute-to-Opencast-roles-mapper idea).

My key argument is that if an external authorization system is in place, it should handle both a) authorization to content and b) authorization to functionality.
Otherwise, you will start to mix up external and internal authorization which is somewhat crazy since some parts of the information relevant for authorization will be only known by the external system while others are only known by the internal system.

> Currently, a user belongs to a group if, and only if, it is registered in a certain table in the database. My proposal is: a user belongs to a group XXX if, and only if, it contains the ROLE_GROUP_XXX.

I have to admit that we heavily rely on the "internal authorization" that makes use of the database table in our whole setup including its external dependencies (ILIAS, Moodle and soon OLAT).

Sven Stauber
January 24, 2017, 10:45 PM

Discussion on list makes more sense... waiting on the post of Stephen.

Rubén Pérez
January 25, 2017, 1:36 AM

Hi Sven, (again )

I agree that we could discuss this further by email, but I had already written half this response, and I wouldn't like to simply delete it. Sorry!
(It's also shorter than it looks... including quotes to Sven's original message makes it look longer than it really is)

> Considering the rudimentary LDAP support Opencast currently has and assuming that LDAP can provide authorization information relevant for Opencast, I would probably first write a LDAP-attribute-to-Opencast-role-mapper. This would look like:
> # LDAP attribute = Comma-separated list of Opencast roles
> The LDAP UserProvider would then do the mapping of LDAP attributes to Opencast roles.
> This mechanism would already be enough to also assign whatever ROLE_UI_* a given LDAP-user needs without the need of Opencast groups.
> Advantages:
> - Mapper would likely be useful anyway (assuming there are LDAP attributes relevant for Opencast but not specifically designed for Opencast)
> - Trivial to implement
> - Useful for all LDAP Adopters
> - Does not mix up external authorization with internal authorization (e.g. groups)
> Disadvanges:
> - Can not leverage the Opencast UI components, e.g. cannot put users into existing groups

What you are describing is what already happens in Opencast since the first LDAP adaptor was implemented: the person configuring the service must indicate which LDAP attributes are relevant for Opencast (you read a user with potentially tens or hundreds of attributes, but most of them are irrelevant to you). Then, the LDAP adaptor reads the contents of such attributes and transforms them by (optionally) adding a prefix and (optionally) making their names uppercase.

The only difference from which is already there is that you propose that each role read from LDAP will be mapped into several roles in Opencast. So, basically, having a certain role is equivalent to having a number of extra roles. Does that not sound a little familiar? You are basically proposing a basic, parallel "group system", similar to the groups that already exist in Opencast (I would say that is basic, but perhaps more effective than the Opencast groups).

You suggestion is not different from what I am asking for. I want to the users to have access to pre-defined sets of roles, same as you. The only difference is that your "grouping" is specific to LDAP, and I suggest using Opencast groups.

> If you would want to make use of the Opencast groups, things get a bit more complicated: If LDAP says user Alice is member of the group Students, the UI should also display Alice in the group users, but what is Opencast supposed to do if you use the group editor and remove Alice from the group Students? Finally, it is an external system (LDAP) which manages this relation. Unless you can convince you campus LDAP admin to allow Opencast to interface with LDAP (which I'm quite sure you can't), this is not easy to solve

*If* belonging to a group was defined by a user having a certain "ROLE_GROUP_XXX" role, then the issue solves itself. Belonging to a group is equivalent to having the group role (ROLE_GROUP_XXX), which means that you need to edit the user roles in order to remove the user from that group. Since the users coming from external providers can be marked as "non manageable", then the users can not be removed from their groups from the Opencast UI.

> One way would be...
> - LDAP UserProvider puts Alice into mh_user_ref table. Such "external" users do work with correctly with Opencast groups. But.... this also implies that Opencast does the user authorization up to some degree, e.g. LDAP won't know that Alice is in some groups in Opencast.

As I said, user references are a fancy way of having all your users in the database (including the external uses) without actually admitting that you have all your users in the database. The references will remain there even if the user is removed from the external user provider, because there are no mechanism in place (say callbacks or something similiar) to keep the reference up-to-date and in synch with the external provider.

Besides, if you need to register all your users in the database (as a reference or else), what's the point of having external user providers? In my eyes, the mechanism is clumse and prone to leave "rubbish" behind (i.e. the references will never be automatically removed, etc).

> This way works well if you use an external system for user authentication only (e.g. Shibboleth authentication)... but once you start to put external users into internal groups (e.g. LDAP says "Alice is member of Students"), Opencast currently would show this relation in the group editor of the Admin UI although this relationship cannot be edited.

Is that bad? I should say that the purpose of a federated authentication schema is the fact that the users are users regardless of where they come from.

> I think that a clean solution would need to be aware of "externally authorized users". In that case, the group editor could show Alice in color grey in the group editor to indicate that Alice cannot be removed from the group Students using the group editor (since LDAP says she is a Student).

Naturally. The concept of "manageable" and "unmanageable", of which you have written above, is perfect for this situation.

>> And a further question, *if* a user provider (such as LDAP) can add external users to groups, and being in a group implies to have all its roles including the group role... what's the point of having a group role in the first place?
> The group role is essentially just convenience (as groups are): Without the automatically generated group role, you would need to create a new role and assign that role to the groups (this is automatically done with the group role) to achieve the finally same thing as the group role does.
> If Opencast would not support groups, a very similar thing to "groups" could be achieved by just assigning a set of roles to a set of users.
> The subtle difference here is that if user Alice and user Bob have the same set of roles, they do not necessarily belong to the same group. Subtle because this difference only becomes relevant if you change the roles of a group - as long they are the same, there is no difference.

I was not clear enough before. What I meant was: a group stores a list of its members in a database table. Therefore, a user belongs to a group if the users is on the member list, regardless of the fact that the user has the group role or not. I mean, in the current implementation, when a user belongs to a group, it is included in the member list AND the are assigned the group role. But then, the group role is superfluous: in order to know whether or not a user belongs to a group, one can only check whether or not the user is in the group's member list, regardless of the roles the user have. In other words, the group role is irrelevant in such case, and therefore can be completely removed.

In this scenario, the only situation where a "group role" would be needed is to "translate" the idea of groups into the ACLs. The ACLs only understand roles, and therefore, in order to grant permissions to groups as a whole, there should be a way to translate between a group and a role. But such "group roles" need not be visible by the end users. These "group roles" would only be an implementation detail, but should not be freely assignable to users. The "ROLE_GROUP_XXX" roles would never be visible in the admin UI or elsewhere, nor would any user have such a role assigned. The user would have its own roles, and would belong to a series of groups (according to the database tables), and that's it.

My argument here was that there is no point to having special "ROLE_GROUP_XXX" roles that can be assigned to a user independently, even when a user does not belong to the group XXX. If belonging to a group is expressed in terms of having an entry in a certain database table, then the group roles are redundant and should be removed or reduced to a mere "representation of a group within an ACL". If belonging to a group is, however, expressed in terms of having or not a certain role, then the whole database table thing is redundant and should be removed instead.

Sven Stauber
January 25, 2017, 3:04 AM

Hi Ruben,

As for Shibboleth authentication, note that the only thing this does is providing user identity at login time (incl. some Shibboleth attributes that are based on a specification on top of Shibboleth, e.g. SWITCHaai or DFNaai). With other words: Shibboleth is an identity provider mechanism - not an external user management system. That's why Shibboleth users are made persistent in databases of Shibboleth service providers ("web apps") and the service provider is supposed to take care of user authorization (incl. removing access).

So while the database table might be redundant in case of LDAP, it very much has its justification for institutions that use Shibboleth authentication.

Rubén Pérez
January 25, 2017, 4:33 AM

I do not mind that a user provider uses the database for whichever reason, as long as it is well funded. My criticism is exclusively against the seemingly redundant (and clumsy) mechanism used by the Opencast groups.

Fixed and reviewed


Stephen Marquard


Rubén Pérez


Incorrectly Functioning With Workaround

Tags (folksonomy)



Fix versions

Affects versions