Task #1585
opensingle sign-on (SSO)
0%
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
Updated by Bjoern Michaelsen about 9 years ago
- 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)
Updated by Bjoern Michaelsen about 9 years ago
Found: https://wiki.documentfoundation.org/Infra/Services
services missing from above:- 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)
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)
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 )
Updated by Alexander Werner almost 9 years ago
- Subject changed from Single Sign On to Creating a Proof of Concept for SSO
Updated by Florian Effenberger almost 9 years ago
- Status changed from New to In Progress
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.
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?
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.
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 :-)
Updated by Florian Effenberger over 8 years ago
- Target version changed from Q2/2016 to Qlater
Shifting to later due to the infra changes
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
Updated by Florian Effenberger almost 8 years ago
- Target version changed from Q4/2016 to Q1/2017
Updated by Florian Effenberger almost 8 years ago
- Related to Task #989: Setup public LDAP server for SSO added
Updated by Florian Effenberger over 7 years ago
- Target version changed from Q1/2017 to Q2/2017
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?
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
Updated by Beluga Beluga over 7 years ago
TestLink also supports it: https://github.com/TestLinkOpenSourceTRMS/testlink-code/search?utf8=%E2%9C%93&q=ldap
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
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?
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!
Updated by Florian Effenberger about 7 years ago
- Target version changed from Q3/2017 to Q4/2017
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?
Updated by Thorsten Behrens about 7 years ago
Oh, and something else - having 2FA available at least if we enable this for gerrit would be good.
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.
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.
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
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
Updated by Florian Effenberger almost 5 years ago
- Target version changed from Q3/2019 to Q1/2020
Gerrit done as well
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
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.
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?
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.
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 :-)
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.
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)