Infrastructure

• For OpenID the concern is if all services support it:
• Redmine (internal), Silverstripe (https://github.com/BetterBrief/silverstripe-opauth), mediawiki (https://www.mediawiki.org/wiki/Extension:OpenID) all supporting it, would probably just need some config tweaks
• Bugzilla proved problematic in the past (at least at freedesktop it wasnt easily implemented)
• askbot and gerrit: we are already using OpenID
• other services: (do we miss any here?)

• do all services support LDAP? Redmine, Silverstripe, mediawiki, Bugzilla, askbot, gerrit, (missing services)?
• how do we bootstrap new accounts? impact on onramping? (e.g. to get a freedesktop account, you needed to file a bug on bugzilla, for which you needed yet another account)
• LDAP would be a new SPOF for ~all infra. It would require us to provide LDAP as a HA service, make sure that routing between LDAP and all other services are HA too (e.g. ability to push patches would be depending on three SPOFs: gerrit itself, connection between gerrit and LDAP, LDAP itself)

Found: https://wiki.documentfoundation.org/Infra/Services

• Plone (extensions, templates, conference website) https://pypi.python.org/pypi/plone.openid
• Pootle (Django) http://django-openid-provider.readthedocs.org/en/latest/
• ownCloud (according to https://en.wikipedia.org/wiki/OwnCloud native open-id support)
• moztrap (done as per https://bugs.documentfoundation.org/show_bug.cgi?id=47658)

Florian Effenberger wrote:

SSO was a topic during the last in-person admin meeting, adding this to Alex' pile to watch out for progress
The current plan - Alex, correct my if I'm wrong - is that Robert and AlexV will evaluate Samba for LDAP directory services
Alex, can you get some status update and see where we are, and if LDAP based on Samba is a likely scenario?
Based on that, current (and realistic future) services need to be evaluated whether LDAP works with them, and/or if a OpenID gateway exists (if such thing exists at all)

Just to write it down:
HELPWIKI and OwnCloud should be test services to see how proper the Samba service is working. HELPWIKI and TDFWIKI then would be my part. ;-)

(@björn: you missed all three services :-D )

no, no, no, no, no...
We have to stop this 'I like to have ponny but no-one care to do it so let's buy it' trend.

For infra we have some people on payroll, and we have volunteers... we have to make do with that.
If SSO is not making progress then so be it.. either people can live without it, or they can step in and help make it happen.

no, no, no, no, no...
We have to stop this 'I like to have ponny but no-one care to do it so
let's buy it' trend.

For infra we have some people on payroll, and we have volunteers... we
have to make do with that.
If SSO is not making progress then so be it.. either people can live
without it, or they can step in and help make it happen.

Fine for me, of course, but my remembering is that there are a few board
members who would like to have this, which is why I turned into a budget
item that the board then can vote on.

What would be your proposal then how to handle the request?

It seems to me entirely appropriate to have the board make the budget
prioritization decision on this one in the normal budgeting sheet.

But of course, Norbert has a great point wrt. existing staff time and
trying to use this to build community input into sysadmin.

Where do we stand wrt. this ticket?
From the top of my head, the system is running, with a small user portal to create accounts, change and recover passwords, and is used in production by a LibO Online instance.
Next step is to give it a test drive with more of our production systems. IIRC Norbert volunteered to try it out with Gerrit.
The wiki might also be a nice testbed.
Now that we moved most services to more modern software, LDAP integration should be easier to handle than before.

Can you give a quick status update, so we can outline the next steps?

Florian Effenberger wrote:

From the top of my head, the system is running, with a small user portal to create accounts, change and recover passwords, and is used in production by a LibO Online instance.

Correct

Next step is to give it a test drive with more of our production systems. IIRC Norbert volunteered to try it out with Gerrit.
The wiki might also be a nice testbed.
Now that we moved most services to more modern software, LDAP integration should be easier to handle than before.

Yeah; unfortunately the migrations took most of my time and I had very little time to work on that the last 2-3 months :-/ I hope it'll be a little bit smoother now

TestLink also supports it: https://github.com/TestLinkOpenSourceTRMS/testlink-code/search?utf8=%E2%9C%93&q=ldap

What is needed to be tested? Can there be any further explanation on how someone can help here?

What is needed to be tested? Can there be any further explanation on how
someone can help here?

So far it's rolled out for TestLink and a LibreOffice online instance.
For testing, it'd be great if you could create yourself an account at
https://user.documentfoundation.org and see how TestLink works with
that, as this is the recent service we've added to SSO.

Thanks a lot!

Just added some more email addresses, wondering where we are with this? Which services are supposed to work?

Oh, and something else - having 2FA available at least if we enable this for gerrit would be good.

• https://github.com/privacyidea/privacyidea
• for yubikey client-side support, see https://developers.yubico.com/U2F/Libraries/Using_a_library.html and https://stackoverflow.com/questions/26637660/how-do-i-use-fido-u2f-to-allow-users-to-authenticate-with-my-website

Thorsten Behrens wrote:

Just added some more email addresses, wondering where we are with this? Which services are supposed to work?

Tried to give a comprehensive update during my LibCon17 talk (and also to the reports to BoD). In a nutshell, the “Linked Account” section of the frontend is purely informational, it's there for users to help us with account merging by adding the list addresses they use on all TDF services (the address is verified by the service and also by the SSO frontend so we can tie the profile to the SSO account). We use it to measure adoption among active contributors.

Few services have been entirely migrated to a “real” WebSSO yet (where unauthenticated users are redirected to a central authentication portal, then back to the service after successful authentication). Only LimeSurvey (SAML 2.0), YOURLS, and Etherpad (sub-HTTP requests).

Some services (TDF & Collabora NextCloud, Silverstripe, TestLink) support dual auth method (LDAP binding + internal database) and I'm manually changing changing auth method to LDAP for accounts the email address of which I can find in the LDAP DIT. Not a real SSO solution since users need to authenticate to each service individually (with the same set of credentials from LDAP), and the attack surface is not ideal since a compromise of any service can lead to compromise of SSO credentials. But all accounts need to migrated before we can implement a proper solution using SAML or similar.

Unfortunately we're still in the poking phase (and finding the thin line between gentle reminders and harassment). The DIT is slowly populating but for instance we still have ⅓ of addresses subscribed to the tdf-members list which are not in LDAP (either as primary or secondary address). I'd like to work on the wiki next; I deployed SAML 2.0 to the testwiki and demo-ed it during my LibOCon17 talk, but last time I checked, of the 400-ish contributors of the past 90 days only 50 or so have a verified address in LDAP. So the critical point at which we can lock out users is not quite reached yet.

Guilhem Moulin wrote:

last time I checked, of the 400-ish contributors of the past 90 days only 50 or so have a verified address in LDAP. So the critical point at which we can lock out users is not quite reached yet.

After the last infra call Dennis pointed out that we should only count contributors which also made edits (that weren't deleted afterwards), otherwise end up counting spammers. I count 138 unique such contributors in the last 90 days:

SELECT DISTINCT user_email
      FROM user JOIN recentchanges ON user_id = rc_user
      WHERE rc_source = "mw.edit" 
        AND rc_bot = 0
        AND rc_deleted = 0
        AND user_email_authenticated IS NOT NULL;

of which 60% (83) are not known to LDAP yet. We'll add a banner to the login page before poking users individually.

Bringing up 2FA again - according to this https://lemonldap-ng.org/documentation/2.0/secondfactor.html page, it's mostly installing/enabling a plugin?

Thorsten Behrens wrote in #note-35:

Bringing up 2FA again

That should have warranted a separate ticket (thanks Florian for the reminder). TOTP is now available as opt-in, tested with FreeOTP+. This can be made mandatory for a subset of users (for instance infra team members or BoD), or for a subset of application consumers (for instance gerrit or nextcloud). But before getting there we'll need an adaptation period.

Also, it a bit moot right now since user.documentfoundation.org is a (homemade) separate service which uses the same password store but has no 2FA. Want to convert it to a LL::NG plugin at some point to make it available at auth.documentfoundation.org, but haven't got that far yet.

Guilhem Moulin wrote in #note-36:

... TOTP is now available as opt-in, tested with FreeOTP+.

From a dumb user (=mine) perspective, I'd love to see a FIDO2 oriented setup rather than TOTP, especially passkeys would be great :-)

Same request as Uwe - and there seems to be this:

Would in any case be super nice, to additionally have WebAuthn added (so I can add my YubiKey as a fallback 2nd factor):

https://lemonldap-ng.org/documentation/latest/webauthn2f.html

Additionally, a problem with the current setup is, that there seems to be no fallback like recovery codes or anything, in case the one second factor gets somehow MIA.

Quick poke on status here - I've re-checked, still no recovery codes when enabling TOTP. Of course, getting a physical token to work with this would be even better (and then I suppose recovery codes are less of an urgent need, with 2 independent factors available)