freedesktop.org single sign-on project

[Michael Leupold]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20081003/a8df061a/attachment.sig>