I wanted to see if I am missing something in terms of configuration and learn how the following situation is handled at CERN:
We are considering to give community members event creation access to a category in our indico instance. This makes them a manager for the event. When they go to the event protection settings, they are able to search for users or groups in the protection settings.
In doing so, they have access to the full name and email of every indico user on the platform. This is pretty broad access which is less concerning when the event managers are internal staff, but could pose a risk when event managers are from the community.
Given the CERN indico has hundreds of thousands of events, I would imagine you’ve solved this somehow? I would imagine some access restriction so that e.g. only users are returned that have registered for the event, making them an active participant who may have consented.
First of all it’s important to distinguish between registered participants and Indico users.
Registered participants (ie those who sign up for an event using a registration form) are local to each event - only people with management access to the event (or a parent category since management access is inherited) can see those. They also never show up when searching for users.
Indico users (those who can log in to Indico) are a different topic though. And the problem is that there simply isn’t a good solution. At least in our field people expect that they can search for people from the same field (High Energy Physics in case of CERN) in order to add them let’s say as authors or speakers in their events. They expect to find them either directly in Indico or via their LDAP/SSO account (“Search users with no Indico account” option). Same if an instance is completely internal to your employees. People have the same expectation there.
Limiting the results to registered participants would not work at all, because very often events are organized before the registration opens, or you organize a meeting for which you do not even have a registration form. But you still need/want the ability to add those people to your event ACLs, or add them as speakers (without entering their data again and again).
FWIW, there’s a pull request which I hope to revive for 3.3 which would add a new setting to prevent users who have an Indico account but no management access whatsoever from searching users.
I also opened this issue some time ago with the idea of introducing different user roles. This could possibly help as well to limit the global user search to a more limited set of people.
Ah yes sorry, I oversimplified. Agree only event managers will see registrants unless participation list settings expose them. That is fine. Indeed the focus I have is on Indico users, and ways to search them.
There are different needs, so there is probably not a one-size-fits-all solution. In our case we have different levels of access (not technically, but thinking in categories of trust). I’d trust that a staff member with event management access can search users without restrictions, as they can today. They can also add arbitrary other managers, knowing where our limits are.
Then we have trusted community members, we have some sort of relationship with them and believe they will be reasonable when dealing with the data they have access to, so we’d be more comfortable giving them event management access knowing they can access the data.
The final group is community members that are organizing events more locally. We don’t always know each of these people, and they may change over time, but we’d still like to enable them to be successful.
We can handle the first two groups with what we have, but the third group is interesting. If there was a per-category setting like “allow event managers to search for users/groups not registered for the event” or something like that, we could disable this for the general community member category. In that case they would not be able to pre-register anyone. For that category we might also have a plugin that forced a “disclaimer” field into the registration form. User accepts disclaimer, community member has access to the registrations, and can see the users. They are then also able to add them as event managers by searching for them. They would still not have access to all other Indico users.
Alternatively, the setting you mention to prevent users from searching at all might be more simple and work out quite nicely. If people want to add other event managers, they’d have to reach out to admins to get that person added as well, which is a great side-effect. Am I understanding correctly that user roles would be e.g. “can search for users”, and we could define at the identity provider level which roles which users would have?
Would love if you could pick up that pull request for 3.3. – when is that due btw?
Probaly no later than the middle of this year. It’s not a huge release (see the roadmap) since we ended up putting so much stuff in 3.2.x point releases.
And the guy who created the original PR (@omegak) is still active in the Indicoverse, so it might be best to check with him directly if he plans to update it (I think it’s nearly ready, except maybe for some smaller edge cases). I can ping him on Matrix and point him towards this thread in case he doesn’t see the ping here.
Anything more in-depth such as category-level settings (if the global system-wide setting is enabled) should ideally be a separate PR after that one is merged - it’s already big enough to make it not particularly review-friendly.
At least in that PR event managers (and anyone with management-like privileges) can still search as much as they want there. So managing ACLs would not be affected at all.
Understood, for some reason I was thinking the PR also limited access for event managers. It is still a good start though, I didn’t realize that lookup was available more broadly. It does seem like what I’m aiming for loosely fits into the theme of GDPR/privacy improvements, though I acknowledge that it might take more than just a few PRs to get there.
I think for the internal/company use case it is certainly fine that people can look up accounts and add them as speakers or authors. They could look them up via the staff directory, so it should be possible in indico as well.
For more publicly used instances, or those shared between staff and community, I do think we should find out an acceptable solution. Maybe we can gather the different use cases and find more specific solutions. Some examples under the premise we have a global/category setting to restrict account visibility:
Adding someone as a manager to an ACL you can do by entering the email, it wouldn’t expose they already have an indico account. Potentially add an opt-in so that users need to accept before they really become ACL managers.
Adding someone as a speaker works either if they have already registered to the event (or maybe any event in the category?), or they are already a speaker for another talk.
Some other API endpoints and UI might just not indicate that a person is an indico user, but would use the account in the backend.
I know this will get tricky quickly, but I do see some privacy concerns here that would make it difficult for us to allow our community members to use indico for managing their events, short of having one indico instance per community.
Indeed, you could describe it as multi-tenancy. I think with categories, per-category managers, and being able to accommodate a large number of events, Indico has the basics necessary. From there we should figure out what it takes to lean towards multi-tenancy, and how this might fit into the general concept.
