Re: Online Accounts panel for 3.2

[Alberto Mardegan <mardy users sourceforge net>]

On 04/20/2011 11:51 AM, Stef Walter wrote:
[...]
> It seems to me the architecture of Meego SSO is very security focused.

Indeed it is.

[...]
> However I think that this could get in the way of broader adoption. In
> order to succeed, you would need patch every GNOME application and
> library to not do its own authentication (DIGEST, NTLM, OAuth, CRAM,
> GSSAPI, and so on...) but have them call out to the daemon. This is not
> impossible but requires a large amount of commitment and time by someone
> (probably you). It's not something that will likely happen by the
> various projects on their own.

True, but it's also totally optional. I mean, of course the goal would be to 
have a centralized point for accounts configuration, but it's clear that this 
will happen in steps. And I don't believe that this problem is specific to the 
MeeGo SSO: even if you go for another (less secure) implementation, you'll still 
have to modify all client applications/libraries.
We add some more stress on the security, but directly providing the token and 
handling of failing authentications should be an advantage for applications; 
they would actually have some code *removed*. But even if this shouldn't happen, 
it's again optional: SSO provides also a plain password method, so applications 
won't have to change much.

> If the goal is to have this work with the entire desktop (not just
> GNOME) then certain applications (think Mozilla) would be very
> challenging to refactor in this way.

Yes. We actually wrote an extension to Mozilla to reimplement the LoginStorage 
by means of the accounts/SSO framework. It's not open source, but I can grant 
you that it was not a huge amount of code.

> The amount of work that this involves brings me to question the
> practical value of hiding the secrets from the applications. Here are
> some thoughts:
[...]

You raised a few valid points here. But IMHO, the biggest advantage of the SSO 
is not the increased security (which is also important of course), but 
especially the fact that adopting the framework will make applications' code 
smaller and more flexible.
Once, you adopt the SSO framework, your application can change from an 
authentication method to the other by just changing a few lines of code (or even 
none, if the authentication method and its parameters are read from a 
configuration file). It's especially good for frameworks and applications 
supporting different accounts, such as Telepathy, pidgin, Evolution, F-Spot, etc.
Also the handling of failed authentications would be moving to SSO (+ the 
missing SSO UI), so we'd have a consistent experience on all apps.

I think that even if we disabled all kinds of security in the SSO daemon, it 
would still make a lot of sense to use it.

BTW, back to security: one thing you mentioned was about OAuth secrets: yes, 
applications would get them, but usually they are time-bound, so they expire 
after some time -- while passwords usually don't.

Ciao,
  Alberto

--
http://blog.mardy.it <-- geek in un lingua international!