webapps team mailing list archive

[Alberto Mardegan <alberto.mardegan@xxxxxxxxxxxxx>]

Hi all!
  I'd like us to discuss a bit about how to handle the webapps which
need authentication. Let's have an explorative chat here, and then
hopefully capture the action points into a blueprint.

What follows is some "thinking aloud" of mine; you are very welcome to
correct any mistakes and integrate with your thoughts.

The question is about the user authentication in webapps. We'd like to
be able to confine each webapp to a limited set of domains: from a
Facebook webapp, for example, it shouldn't be possible to follow a link
to an external domain and load it onto the webapp container (which
exposes some Ubuntu APIs which might get abused by malicious websites);
external links should either be blocked altogether, or be loaded into
the default browser, where the Ubuntu specific APIs are not exposed (or
they are exposed only after the user's confirmation).

This shouldn't be very difficult to achieve most of the times, however
there are several cases where this might be impossible. In the case of
OpenId authentication (and also Google Apps), the user might get
redirected to an external website in order to perform the
authentication. Given that we cannot predict what is the website which
will be loaded, we would need to give up webapps domain confinement
altogether.

There are a few ways to address this issue; I will list only the two on
the top of my head (though they are not originally mine, to be honest):
1) Until the authentication has completed, act like an ordinary web browser.
2) Delegate the authentication to Online Accounts.

Option #1 means that the webapp starts unconfined, and with no Ubuntu
APIs available. It basically starts as an ordinary web view. Only once
the authentication has been completed (which can be detected by locating
certain elements on the DOM), the webapp gets confined to its usual
domains and the Ubuntu APIs become available to it.

Option #2 is a bit more difficult (that's why I'm opening up the
discussion), but could bring greater benefits. Before the website is
opened in the webapp, the webapp container asks Online Accounts for an
account to be used with this webapp (this implies that the webapp's
manifest file contains the name of the account provider, so to inform
Online Accounts about which account type is needed). If Online Accounts
doesn't have an account yet, the user will be prompted to create one. If
Online Accounts has more than one account, the webapp container should
probably prompt the user about which accounts to use.
We might also want the account to be remembered by the webapp, so that
the user could have the same webapp installed twice (one for his
personal account, one for the work one). This needs some design discussion.

The Online Accounts will very soon offer all the required functionality.
However, when the webapp container will authenticate with Online
Accounts, it will get only an access token; while this is what native
applications need, it's useless for the website itself (it might be
useful if we knew more about the website internals, but we generally
don't -- and don't want to depend on internal behaviours).
What we really would need, is to obtain access to the website session
which was opened in Online Accounts. And here comes the sweet part of
the plan: the cookies. :-)

Online Accounts uses an ordinary web view to authenticate, but the
website cookies get stored in a different place for each account. And
the cookies are stored on disk, in order to minimize the number of times
we ask the user to authenticate himself.
So, the idea is to share with the webapp the cookies which OA has stored
for this account.

The main question I have is: should the webapp container have only read
access to the cookies, or should we let it update them? In other words:
should we simply copy all the cookies over from OA to the webapp when it
starts (let's call this option #1), or should we also have a way for the
webapp to modify the OA cookies (option #2)?

I can see potential problems with either approach:

With option #1, the website might do some smart stuff with the cookies
and prevent us from reusing the same cookies more than once: that is,
the first time that you open the webapp it will work, but the second one
(which reuses the same old cookies from OA, not the new ones which might
have been written during the first execution of the webapp) it might fail.

With option #2, the user can click on the logout button from within the
website (running in the webapp), which would cause the logout in OA as
well. This might not be such a serious issue, depending on how long is
the expiration time of the access tokens granted to by apps using OA and
whether they get invalidated with a logout or not.

As for the implementation, it seems to me that option #1 should be
easier to implement, unless we grant read/write access to all the OA
cookies to the webapp container (I'm not sure about the security risks
here; will we offer some APIs through which the website itself can
access the filesystem in an arbitrary location?).


Another issue to address with the OA integration is the expiration of
the session: suppose that the session expires while the user is actively
using the webapp; the user will be asked to login again, but at that
point the webapp is confined to its usual domains, so Openid (or Google
Apps) authentications will be blocked (or redirected to the default
browser), which sounds like a terrible user experience.
Any ideas for solving this? DOM tricks again? :-)

Let your thoughts flow. :-)

Ciao,
  Alberto