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.
> * uoa = Ubuntu Online Accounts -
> http://developer.ubuntu.com/resources/technologies/online-accounts/
> * goa = GNOME Online Accounts -
> https://developer.gnome.org/goa/stable/
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.
Google CalDAV/CardDAV via OAuth2
================================
Setup
-----
SyncEvolution needs an active account for Google. Services for CardDAV
and CalDAV can be used, but are not required if the provider was
already configured to ask for CardDAV and CalDAV access.
SyncEvolution source code ships with example .provider, .service, and
.service-type files in the src/backends/signon/accounts
directory. These files work with gSSO.
When compiling, it is possible to insert valid client ID+secret into
these files using the --with-google-client-* configure options. The
example files then get installed into
$docdir/accounts/[providers|services|service_types].
SyncEvolution binaries from syncevolution.org are compiled with valid
client ID+secret. Distributions are encouraged to *not* reuse the same
credentials and register themselves with Google instead. That way,
abuse of the credentials affects less users and the quota available to
all users of the same credentials does not get exhausted as quickly.
Users of the syncevolution.org binaries need to install the
/usr/share/doc/syncevolution/accounts themselves, typically in their
home directory:
cp -a /usr/share/doc/syncevolution/accounts ~/.local/share/accounts
A "google" account needs to be created and enabled:
ag-tool create-account google google-for-syncevolution
ID=`ag-tool list-accounts | grep google-for-syncevolution | sed -e 's/ .*//'`
ag-tool enable-account $ID
Optionally, one can also enable the services:
ag-tool enable-service $ID google-carddav
ag-tool enable-service $ID google-caldav
It is not possible to create signond identities via command line
tools. SyncEvolution will create those automatically and store them
for the provider so that it can be reused in future operations.
Usage
-----
OAuth2 authentication with gSSO is enabled by setting username or
databaseUser to a string of the format
gsso:<numeric accountID>[,<service name>]
When used without service name, SyncEvolution will ask for access to
CalDAV and CardDAV only once. When used with service name, it will ask
for access to only CalDAV or CardDAV, but it will have to ask twice
(once for each service).
The base URL for each service currently needs to be given via syncURL:
syncevolution --print-databases \
backend=carddav \
username=gsso:$ID,google-carddav \
syncURL=https://www.googleapis.com/.well-known/carddav
src/syncevolution --print-databases \
backend=caldav \
username=gsso:$ID,google-caldav \
syncURL=https://apidata.googleusercontent.com/caldav/v2
Once that works, follow the "CalDAV and CardDAV" instructions from the
README with the different username and syncURL.
Debugging
---------
Add --daemon=no to the command line to prevent shifting the actual
command executing into syncevo-dbus-server and (from there)
syncevo-dbus-helper.
Warning: gsignond limits access to the identity to the executable which
created
it. One has to use different accounts for syncevolution with and without
--daemon=no and another account when using valgrind.
Set SYNCEVOLUTION_DEBUG=1 to see all debug messages and increase the
loglevel to see HTTP requests:
SYNCEVOLUTION_DEBUG=1 syncevolution --daemon=no \
loglevel=4 \
--print-databases \
...
_______________________________________________
SyncEvolution mailing list
[email protected]
https://lists.syncevolution.org/mailman/listinfo/syncevolution
