Hello!
I've implemented the "id" credentials lookup mechanism and OAuth2
authentication for Google CalDAV/CardDAV, using gSSO. The code is
currently in the "for-master/signon" branch. Be warned, I will rebase
that branch to fix commits before including the code in the "master"
branch.
Right now it works well enough to access contacts and events in Google.
I have not tried to actual set up syncing - it might very well be that
the new Google services behave differently. Besides, Google CardDAV has
not been officially supported and tested before at all.
Running the regression tests also points also did its job and, well,
found regressions... normal syncing is probably broken at the moment.
More comments below.
On Thu, 2013-07-11 at 17:07 +0200, Patrick Ohly wrote:
Whatever we do about this, let's consider a few things:
* Some services, in particular SyncML, only work with
username/password, so SyncEvolution needs a way to retrieve
both.
Could be done via a the signon password plugin, not implemented and I
don't intend to add that. Patches welcome, of course.
* OAuth2 grants access to clients, which identify themselves
with
a key. Abuse of that key may lead to blacklisting that key and
thus preventing access to the service. Possibly the creator of
that key will also be banned such that he or she cannot create
new keys. For SyncEvolution that means that sharing the same key
with everyone is a bad idea. Whoever compiles SyncEvolution
should at least have to make a conscious choice about which key
he uses. For binaries that I publish on
syncevolution.org, a key
for Google needs to be included. There's no effective measure
for keeping that key secret, so I might as well publish it on
syncevolution.org and allow individuals to use it when compiling
SyncEvolution for themselves.
Attached the README from the new src/backeds/signon directory where I
explain how SyncEvolution handles that now.
* Some users therefore won't care that much where they
enter their
password. Quite the opposite, entering the password in advance
is useful in cases where such an interactive login is not
possible or difficult, for example on a server where X is not
running or which has no web browser installed.
Pre-seeding the password is not possible. The user has to run with a
signon UI connected to his display when accessing the services for the
first time.
* In some cases, a pop-up asking for OAuth2 confirmation is
desirable, sometimes it isn't. Need to define when to use it and
when (and how) to fail with a authentication error.
SyncEvolution currently doesn't do anything special in this regard. This
means that even background syncs, for example those triggered via the
auto sync mechanism, may trigger the login dialog.
I can think of five different such backends:
* gSSO = glib-Single-Sign-On -
https://01.org/gsso
Implemented.
Both not implemented.
* user = traditional username/password setting, only needed in
cases where the username happens to start with one of the
prefixes above
* id = a central identity managed by SyncEvolution
Both implemented.
"gSSO" and "uoa" use the same libaccounts-glib
client library and
different implementations on the server side. I've been told that some
of these server-side differences leak through the common client API, so
backends might be very similar, but not quite identical.
It would be good to have SyncEvolution .deb files that work on Ubuntu
(with Ubuntu Online Accounts) and on Debian (with gSSO installed by the
user or from the projects repo). Right now this is impossible:
* Even though backends are plugable and the "signon" code could be
compiled once for UOA and once for gSSO, the backends have to be
loaded to find out what they are, and that fails on systems
where both libsignon and libgsignon are installed, because the
libraries provide conflicting symbols.
* Installing accounts .provider and .service files directly
into /usr/share/accounts is difficult. SyncEvolution doesn't
know whether it needs to install for UOA or gSSO (they are
slightly different) and installing "google.provider" may
conflict with other packages.
Backends for "gSSO", "uoa" and will be expected
to map the <identity>,
a service identifier and a realm (or is it scope?) to a
username/password combination (for a traditional login mechanism,
similar to local password storage in GNOME keyring or KWallet) or the
OAuth2 access token.
This is done with libaccounts-glib and suitable config files for it.
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.