Board to vote on the mantra requirement

Regina Obe lr at pcorp.us
Mon Jun 15 10:27:27 PDT 2026


> > The main pain points I see with LDAP brought up:
> >
> > a) The MFA brought up in the motion - which I agree with that we need MFA
> for LDAP for the id.osgeo.org but I suspect that is not that hard to fix.
> 
> Note that some of our services already support multi-factor authentication
> locally, for example Gitea: https://gitea.osgeo.org/user/settings/security
> 
Yes so does our wordpress, which was brought up, but we don't have using it enforced.
We don't have enforced on gitea either.

We didn't do that to minimize friction but that would be the first thing.

I think though that id.osgeo.org should require MFA cause that's where people setup their passwords, emails, and put their public keys.
That has always bothered me it does not require MFA.


> To activate MFA we need a _second_ factor, so by definition something in
> addition to what we already have, which means you don't need to ditch LDAP
> in order to get MFA.
> 
> > b) What LDAP is used for that it may not need to be:
> >
> > 1) Signing up for code sprints on WIKI
> 
> I'm not familiar with the code sprints setup, I guess even an email would be ok
> to sign-up ?
> 

I know that a lot of OSGeo events create a page on the wiki and have people signup there.
I was thinking possibly https://talks.osgeo.org could be used for this but not sure cause that would be the most logical place to put it since the calendar of who's speaking is in there already and all the international and many of the local FOSS4Gs are already using it to accept speakers.

> > 2) The large number of QGIS plugin authors needing an OSGeo account
> 
> I think the QGIS Plugins Repository service could just accept whatever
> passport is provided by the companies QGIS PSC decides to trust, there's no
> need to change anything on the OSGeo infrastructure side for that, and
> definitely we don't need a centralized Keycloack for that (as long as I know).
> 
> I see the "accept other passports" as something we want to enable or disable
> on a per-service basis. Some services provide more protection against spam,
> some are weaker, we want stronger identity for the weaker ones, I think.
> 
> --strk;
> 
>   Libre GIS consultant/developer 🎺
>   https://strk.kbt.io/services.html



More information about the Sac mailing list