LDAP group after installation


Currently my indico didn’t get groups from ldap, I only have very few groups in indico.

I would like to know how indico will react if I configure my current indico with ldap group.

If a group is created in the ldap, I’m guessing it will be «copied» inside indico, but what append next, can some one add a indico’s user inside a group from the ldap (like a user who’s not inside our ldap), or the ldap_group in indico are sync regularly with the LDAP ?

How a ldap_group in indico deal with someone authenticated with oauth2 ?


There are no copies of groups whatsoever. All that indico stores for groups is the name and provider (IDENTITY_PROVIDERS dict key) when adding it to an ACL.

And there must be an IDENTITY_PROVIDER configured that can check the group membership of users, regardless of how they log in. When using oauth for login you need to get a proper identifier for the user which you can then lookup in LDAP. We did that for a long time at CERN: oauth-based login, and then getting the user data from ldap.

Ok, in that case what append if a indico_group already exist and someone create a ldap_group with the same name ? Which one will be «keep» by indico ?

Ok. And the user are identified by their login or their email ?

They are completely separate. You can have two groups with the same name from different sources/providers.

Anything the auth provider gives you can be used (note that in case of oauth). It depends on your environment what you (can) use for this purpose.

Just one last question (not really related to the topics, but a consequence :wink: ) Currently I don’t have a IDENTITY_PROVIDER other than my oauth2, so I can add one but is they are anyway to hidden it on the login page ?


NB: Thanks for your crazy quick answer as usual

You could disable the oauth identity provider (and configure the endpoint that returns user data as the auth provider’s userinfo endpoint instead), and then let the ldap one get the details for the user that indico uses. This of course assumes that any user who can do oauth also exists in ldap.

Otherwise I think you can add a second one that’s “internal only” for groups. But I haven’t tested that, not sure if we have some check that any provider needs to have an auth provider linked or not…

I just wanted to mention that one the last point raised by @ThiefMaster (user doing oauth must also be in LDAP) that I think it is similar to an issue we have been fighting with using eduGAIN as the auth provider (in our config with have one auth provider of shibboleth type, and one identity provider of LDAP (AD) type). After tweaking the code for a few years, we discussed with @ThiefMaster and found a solution to relax this requirement properly in Flask_Multipass that will be integrated in next release. See LDAP identity provider: fix support of an associated Shibboleth auth provider by jouvin · Pull Request #42 · indico/flask-multipass · GitHub (in a finalization stage).