Re: Online Accounts panel for 3.2

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.


-- <-- geek in un lingua international!

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]