Project

General

Profile

Actions

Task #1585

open

single sign-on (SSO)

Added by Michael Meeks about 9 years ago. Updated 11 months ago.

Status:
In Progress
Priority:
Normal
Category:
-
Target version:
Team - Q2/2021
Start date:
Due date:
% Done:

0%

Tags:

Description

Having to remember, and manage a slew of different credentials for different pieces of infrastructure: from bugzilla, to redmine, to SilverStrip etc. is a royal pain.

Surely we can use a consistent credential store for all of these.


Related issues

Related to Infrastructure - Task #989: Setup public LDAP server for SSOClosedGuilhem Moulin

Actions
Actions #1

Updated by Bjoern Michaelsen about 9 years ago

So to revamp the discussion on this one: The key questions was if we should use OpenID or a TDF-wide LDAP. Norbert suggested setting up our own LDAP instead. Questions/Comments on that from my side:
  • 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)
Actions #2

Updated by Bjoern Michaelsen about 9 years ago

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

services missing from above:
Actions #3

Updated by Florian Effenberger about 9 years ago

  • Project changed from 30 to Infrastructure
  • Assignee set to Alexander Werner
  • Target version set to Q1/2016

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)

Actions #4

Updated by Dennis Roczek about 9 years ago

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 )

Actions #5

Updated by Alexander Werner almost 9 years ago

  • Subject changed from Single Sign On to Creating a Proof of Concept for SSO
Actions #6

Updated by Florian Effenberger almost 9 years ago

  • Status changed from New to In Progress
Actions #8

Updated by Norbert Thiebaud almost 9 years ago

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.

Actions #9

Updated by Florian Effenberger over 8 years ago

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?

Actions #10

Updated by Michael Meeks over 8 years ago

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.
Actions #11

Updated by Florian Effenberger over 8 years ago

  • Target version changed from Q1/2016 to Q2/2016

Some good news on that
During CeBIT, the idea has grown that we could have a look at UCS (Univention Corporate Server) which nowadays is completely free of charge, and could provide a nice LDAP solution out of the box
Plan IIRC is to set that up in a VM and give it a try - if that works, the LDAP mystery would have been solved in parts
Let's see how this turns out, but it sounds quite promising to me
In parallel, Alex is in contact with a local FLOSS supporting company who might help us out as well with getting knowledge and up to speed

Also talked to Norbert that investing into getting the knowledge if need be (rather than investing into services and creating bus external factors) sounds sensible

All in all, finally some progress :-)

Actions #13

Updated by Florian Effenberger over 8 years ago

  • Target version changed from Q2/2016 to Qlater

Shifting to later due to the infra changes

Actions #14

Updated by Florian Effenberger about 8 years ago

  • Subject changed from Creating a Proof of Concept for SSO to single sign-on (SSO)
  • Assignee changed from Alexander Werner to Guilhem Moulin
  • Target version changed from Qlater to Q4/2016

Re-assigning to Guilhem, who is working on this now
Guilhem, the ticket contains a lot of previous (and maybe legacy) thoughts, I don't want to confuse you :-)
Feel free to update as you see fit and check with Norbert, with whom you've been talking about that item in some detail I guess

Actions #15

Updated by Florian Effenberger almost 8 years ago

  • Target version changed from Q4/2016 to Q1/2017
Actions #17

Updated by Florian Effenberger almost 8 years ago

  • Related to Task #989: Setup public LDAP server for SSO added
Actions #18

Updated by Florian Effenberger over 7 years ago

  • Target version changed from Q1/2017 to Q2/2017
Actions #19

Updated by Florian Effenberger over 7 years ago

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?

Actions #20

Updated by Guilhem Moulin over 7 years ago

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

Actions #22

Updated by Florian Effenberger over 7 years ago

  • Priority changed from Normal to High
  • Target version changed from Q2/2017 to Q3/2017

Some status update:

  • LDAP self-signup service in place
  • LibreOffice online instance connected to it
  • TestLink connected to it as well
  • gathering further experience and then rolling out to further services like wiki others
  • Getting testers is crucial! In the past, people were reluctant to migrate their accounts over, and to get some real-life data, we need a critical mass to actually use it
Actions #23

Updated by Jean Spiteri over 7 years ago

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

Actions #24

Updated by Florian Effenberger over 7 years ago

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!

Actions #25

Updated by Florian Effenberger about 7 years ago

  • Target version changed from Q3/2017 to Q4/2017
Actions #26

Updated by Thorsten Behrens about 7 years ago

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

Actions #28

Updated by Guilhem Moulin about 7 years ago

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.

Actions #29

Updated by Guilhem Moulin about 7 years ago

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.

Actions #30

Updated by Florian Effenberger over 6 years ago

  • Target version changed from Q4/2017 to Q2/2018

Users are slow with getting their accounts created
Next set of services we can deploy are Wiki, Silverstripe and Redmine
The plan is to enforce SSO with some heads-up time
In theory, we can disable again if we miss a critical mass, but unless there's really an urgency, this sounds like the way to go to get users migrated to this so they have a need to create their LDAP account

Plan is around early June for the next services to be deployed with SSO

Actions #31

Updated by Florian Effenberger over 5 years ago

  • Priority changed from High to Normal
  • Target version changed from Q2/2018 to Q3/2019

Wiki, Silverstripe and Redmine are connected in the meantime
Connected is also LimeSurvey, Nextcloud

Pending are WordPress, Jitsi (no auth at all for the moment), Piwik, Bugzilla, AskBot
Weblate will have SSO enabled from the beginning, so will the TSP

Actions #32

Updated by Florian Effenberger almost 5 years ago

  • Target version changed from Q3/2019 to Q1/2020

Gerrit done as well

Actions #33

Updated by Florian Effenberger over 4 years ago

  • Target version changed from Q1/2020 to Q4/2020
  • next smaller services, one by one, starting in Q4: Jitsi, maybe Riot, TSP
  • next big service: Bugzilla - needs transition period
  • not a priority right now, need to plan this in
  • Bugzilla 6.0 might provide SSO out of the box, but this has no ETA
Actions #34

Updated by Guilhem Moulin almost 4 years ago

  • Target version changed from Q4/2020 to Q2/2021

Florian Effenberger wrote:

  • next smaller services, one by one, starting in Q4: Jitsi, maybe Riot, TSP

Didn't get to this, but OTOH two new services are hooked in: Discourse and Moodle. Preparing Bugzilla for SSO auth is delayed to after the migration from AskBot to Discourse.

Actions #35

Updated by Thorsten Behrens over 2 years ago

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

Actions #36

Updated by Guilhem Moulin over 1 year ago

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.

Actions #37

Updated by Uwe Altmann over 1 year ago

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 :-)

Actions #38

Updated by Thorsten Behrens over 1 year ago

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.

Actions #39

Updated by Thorsten Behrens 11 months ago

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)

Actions

Also available in: Atom PDF