Project

General

Profile

Task #1585

single sign-on (SSO)

Added by Michael Meeks about 2 years ago. Updated 22 days ago.

Status:
In Progress
Priority:
High
Category:
-
Target version:
Team - Q4/2017
Start date:
Due date:
% Done:

0%

Estimated time:
Tags:
URL:

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 SSOClosed

History

#1 Updated by Bjoern Michaelsen about 2 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)

#2 Updated by Bjoern Michaelsen about 2 years ago

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

services missing from above:

#3 Updated by Florian Effenberger about 2 years ago

  • Project changed from Foundation 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)

#4 Updated by Dennis Roczek about 2 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 )

#5 Updated by Alexander Werner almost 2 years ago

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

#6 Updated by Florian Effenberger almost 2 years ago

  • Status changed from New to In Progress

#8 Updated by Norbert Thiebaud almost 2 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.

#9 Updated by Florian Effenberger almost 2 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?

#10 Updated by Michael Meeks almost 2 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.

#11 Updated by Florian Effenberger over 1 year 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 :-)

#13 Updated by Florian Effenberger over 1 year ago

  • Target version changed from Q2/2016 to Qlater

Shifting to later due to the infra changes

#14 Updated by Florian Effenberger about 1 year 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

#15 Updated by Florian Effenberger 11 months ago

  • Target version changed from Q4/2016 to Q1/2017

#17 Updated by Florian Effenberger 10 months ago

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

#18 Updated by Florian Effenberger 8 months ago

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

#19 Updated by Florian Effenberger 7 months 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?

#20 Updated by Guilhem Moulin 7 months 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

#22 Updated by Florian Effenberger 5 months 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

#23 Updated by Jean Spiteri 5 months ago

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

#24 Updated by Florian Effenberger 5 months 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!

#25 Updated by Florian Effenberger about 1 month ago

  • Target version changed from Q3/2017 to Q4/2017

#26 Updated by Thorsten Behrens about 1 month ago

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

#28 Updated by Guilhem Moulin about 1 month 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.

#29 Updated by Guilhem Moulin 22 days 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.

Also available in: Atom PDF