Hi Robinson, Jean, Alexander, and everybody else interested in SSO, Am 24.07.2014 um 16:41 schrieb Robinson Tryon: > On Thu, Jul 24, 2014 at 6:10 AM, Alexander Werner > <a...@documentfoundation.org> wrote: >> thats great to hear that you are interested in working on this! I have CC’ed >> Philipp, how already offered to set up an LDAP server for us. You two might >> want to get in touch to talk about the details of SSO and OpenID and if it >> makes sense to deploy not only SSO via LDAP but also run an OpenID server. > Woot! This sounds great! > > OpenID and LDAP both would be worthy of our investigations. I've > opened a few todo bugs about moving towards SSO[1], but haven't had > time to move forward, so it's nice to hear that others are making > strides!
Am 21.07.2014 um 20:46 schrieb Jean Spiteri: > I am writing this post to inform the community I am interested in taking over > a number of Redmine issues which relate to a uniting of the present > different user systems used by each TDF service. I did some research and > came up with a solution to either use an Single Sign-on system (SSO) or use > OpenID to handle the different accounts [...] OK, so everybody feels that reducing the amount of identity databases is worthwhile, so how do we go about it. I'd hate to have a huge discussion about the pro's and cons of each here; I think we'll need to decide based on available volunteer experience. Could everybody who has set up and run in production one of the below please write a short paragraph about the thing they are familiar with, and their experiences ? --- snip --- Quick Terminology recap: LDAP: lightweight directory access protocol, stores user credentials and can be used as SSSO OpenID: solution for authentication delegation, web-based SSO, "RADIUS / SASL for web sites" OAuth: similar thing for web services, out of scope here (related to OpenID Connect) SSO: single sign-on, log in once and use multiple services SSSO: single source of sign-on, use the same credentials for multiple services --- snap --- My background here is mostly with LDAP (in the context of a directory, and as SSSO), with a little bit of kerberos thrown in (which can be used to make the whole thing SSO, but that doesn't work well in the web beyond intranets). Most of my experience is in running an OpenLDAP server, though I'm willing to investigate 389DS for DocFound, if we feel a more modern self-service web interface is needed. (Does anybody have experience running Gosa² or similar ?) Connecting services to the directory is a pain in each individual instance, so I'd like to see a list of services that actually should use this shared user database. I'll start: - libo machines' admin users - redmine [2] (shouldn't be much harder than trac, which I've done) The report in [2] also talks about bugzilla, which I think will be a major pain in either case, so I'm not listing it here as realistic. [2] https://redmine.documentfoundation.org/issues/308 On the topic of SSO via OpenID, I'd like to point to a similar discussion happening in Gnome currently. [3] [4] [3] https://www.dragonsreach.it/2014/08/05/back-from-guadec-2014/ [4] http://patrick.uiterwijk.org/2014/07/28/gnome-authentication/ [5] https://id.gnome.org/ If we go for web-based SSO, I like the interface that canonical is running (login.ubuntu.com / login.launchpad.net) - two seperate login pages using the same credentials database, which is a horrible hack for legacy reasons. But the interface seems well-integrated, and I can ask my browser to keep cookies from a single site. On the backend side: most of these "let's deploy a web-SSO" solutions run on a relational database in the backend, which I'm not too keen on for security reasons. The admins would need to make sure there's a dedicated, well-secured database server. If anybody knows one that can use LDAP as a credentials store, please point it out. still quoting Jean: > with the ultimate aim to reduce the > burden which comes from having an additional user account (needing to > remember credentials, etc.). I'd explicitly name reducing administrator / moderator burden as well. If this creates more work, we'll not establish a solution that will be maintained and used long-term. Cheers Philipp -- Philipp Kaluza Ghostroute IT Consulting -- To unsubscribe e-mail to: website+unsubscr...@global.libreoffice.org Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette List archive: http://listarchives.libreoffice.org/global/website/ All messages sent to this list will be publicly archived and cannot be deleted