Re: [libreoffice-website] TDF Accounts

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
> <alex@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+unsubscribe@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