freedesktop.org single sign-on project

[Robert Knight]

> Personally I think having a common daemon should be the way to go

I think that makes sense too, as long as application developers don't
have to talk
C/Glib.  The thing is, security and reliability are pretty important
with something like this and
have two different daemons which implement the exact same
functionality just increases the
amount of code to test and inspect.

I suspect that the distributors would much rather we went down this route too.

Regards,
Robert.

2008/10/2 Michael Leupold <lemma at confuego.org>:
> Hi,
>
> I finally got around gathering some information for planning said fd.o project
> and wanted to share some insights and also gather some information and
> opinions.
>
> The goal of the project is to allow a user to authenticate once to a central
> authority (eg. a daemon) without having to reenter authentication information
> again during the session (if he wishes so).
>
> Part of such a daemon is currently provided by kwalletd which stores passwords
> in a symmetrically encrypted file on disk that's decrypted using a password
> entered by the user. Any application can then use the wallet to retrieve and
> store authentication information. Thus a part of the specification will be
> about how communication between the daemon and client applications works. This
> will enable any application (regardless if GNOME, KDE, Mozilla or whatever) to
> use a secure storage for passwords with having the user authenticate ONCE to
> the daemon (and not 3 times to 3 daemons).
>
> However there's more to it. Authentication can also be done using client
> certificates, popular examples being SSH or SSL. As those secret keys are
> stored encrypted on disk as well, the user has to unlock each of them if he
> wants to use it (eg. by using ssh-add or entering the password in a
> webbrowser). Ideally a single sign-on daemon would provide means to "unlock"
> client keys automatically.
>
> I think it would also be possible to support external SSO mechanisms like
> Kerberos or various shared sign-on techniques. However as I don't know about
> those (yet) I don't know what "supporting" them would consist of.
>
>
> Now on to implementational details. There could be different levels of
> integration between the currently existing projects:
> 1) A common specification of the communication protocol(s) used and about how
> information is stored on disk (so you could swap daemons)
> 2) Additionally a common library for accessing/encrypting/decrypting on-disk
> information
> 3) Additionally a common daemon
>
> I don't have to tell you that the higher the number, the less code :) But it
> would also mean less KDE-ish and probably less control.
>
> I had a look at keyring which is the current daemon GNOME uses for this
> purpose. It's basically kwalletd with quite some additional features. For
> example it already offers unlocking client keys by having the possibility to
> act as a PKCS#11 provider. This means that applications like Firefox can
> already use client certificates provided by keyring. After having a (quick)
> look at the keyring code I think it could serve as a basis for a common daemon
> as it's well structured and the GUI dependant code is separate from the
> background stuff.
>
> What do you think about the general itinerary I should take? Do you think
> adopting keyring is a "no-go" or a valid option once certain circumstances are
> met?
>
> Personally I think having a common daemon should be the way to go. I wouldn't
> object to keyring and I'd even help working on it and getting it to where we
> need it. I am however concerned about the hit-by-a-bus factor (KDE-wise) and
> the fact that it might be hard to gather people to code on it in KDE as it's
> written in C/glib and unrelated to Qt.
> I wouldn't object to just specifying protocols either and building our own
> KDE-only daemon. I'd also contribute to that but as it's quite a lot more work
> we'd probably need more manpower.
>
> Well, I hope I didn't bore you and hope for some good input.
>
> Regards,
> Michael
>