Let's start discuss oeb security issues
As you all know (or should know), current OpenEBench security is thought to be defined by the data itself as can be found: https://github.com/inab/benchmarking-data-model/tree/1.0.x/json-schemas/1.0.x
It defines a list (collection) of Communities, Contacts and Challenges.
Datasets may have its visibility "public" - accessed by everyone. "challenge" - accessed by people involved in a challenge. "community" - by all community members. "participant" - by the 'owners' of the dataset. // (dataset_contact_ids?)
This indeed may be implemented by the REST API.
Another possibility is to use UMA2 authorization protocol supported by Keycloak. UMA2 architecture is based around the concept of "resource". Being radical puritan, this would mean every document is a resource and must have an associated policy configured to it. The REST API in this way do nothing for the authorization, as it is authorization server that decides about permissions. For instance: https://openebench.bsc.es/api/scientific/access/Dataset/OEBD0010000003 there will be some resource with correspondent associated URL and some policies applied. The REST server just wont get a call if not authorized by the KC. The problem may be a big overhead for the authorization server (KC) especially if number of Datasets is very big.
Alternative would be to provide some mix system.
I started to play around defining "Community" as a usual KC user group and assigning KC users (contacts) to those groups. So we can remove "participants" & "communities" from mongo. Associated data like "community_id", "participant_id", are mapped as attributes (openid claims).
Ideally, there could be MongoDB KC module to read this from Mongodb and put it back into OpenID.
I am not sure whether it make sense at all.