Hi Patrick,
On 10/07/2010 02:09 PM, Patrick Ohly wrote:
There still is confusion around Accounts&SSO and what it does.
Specifically, storing plain text passwords in it is under dispute.
Alberto closed a corresponding feature request in the MeeGo 1.0 time
frame, saying that it works and gave some example code:
http://bugs.meego.com/show_bug.cgi?id=5017
But now Sateesh disagrees and says that "retrieving the credentials is
something that is not officially supported or is going to be removed and
is not going to be supported in
future." (http://bugs.meego.com/show_bug.cgi?id=8027#c4)
Retrieving the plain credentials is something we are discouraging, because of
security reasons.
On the other hand, we are aware that migrating an existing application to use
the SSO authentication methods (and not use the password directly) can take time
and in some cases involve some heavy redesign. For this reasons, we provide a
"password" authentication method that allows the client to directly get the
credentials; this would allow all the client applications to migrate to SSO in a
shorter time, while not forcing them to major architectural changes.
We won't remove the password plugin; even if we did, someone else could easily
write their own authentication plugins which could do the same things. So, this
method is going to stay.
On the other hand, the application which creates the credentials record in the
SSO DB (typically, the accounts UI) can specify the allowed authentication
methods, and that's where the "password" method might be blocked. But it would
be a per-account decision, taken by the account plugin writer and not by the
framework.
We also don't have a UI for it, nor any of the plugins which presumably
are needed for each online account that is meant to show up in
Accounts&SSO. Someone needs to add that sooner or later, but at least I
have no idea how to do that.
So let's discuss one specific example: Google. The same
username/password combination works in the web browser when accessing
pages and in the SyncML server offered by Google for contact access.
There are several open issues. Please correct/amend...
* Define "Google" account. Done by writing a
accounts-provider-plugin. Where is that API defined? How is such
a plugin installed? Is there an example?
The API is defined in libaccounts-ui, which is still stuck in the Nokia internal
legal processes to be open-sourced, we are all waiting. :-/
In some cases the plugin could be just an XML file that describes various
parameters of the account creation process; and actually it will be the very
same file as the libaccounts-{qt,glib} provider files.
In other cases, one might want to write his own plugin as a binary object, which
will be run by the accounts UI when creating/editing an account.
So, typically, the installation package for a provider plugin will consist of an
XML provider file and optionally of a binary executable.
* Define services offered by "Google". Done by writing one or more
accounts-service-plugins. Same as before - API and example? Are
service plugins optional if applications provide different ways
of activating services?
For the first question, same answer as before. :-(
About the second question: service plugins can be written as
libaccounts-qt-glib} XML service file extended with some extra elements needed
by the accounts UI, and if needed they can also by a binary loadable object.
And yes, they are optional. If for example I create my own social web service in
example.com and I don't want it to be integrated with the pre-installed MeeGo
applications and instead I want it to be only usable via my own ExampleApp
application, I don't need to write any service plugins. I would only write an
account provider plugin, if I want the example.com account to be created with
the MeeGo accounts UI; or if I don't even want to have it in the accounts UI but
have it all inside my ExampleApp, then I can avoid writing any plugins at all
(but I can still use libaccounts-{qt,glib} for storage, if I want to).
* Request account credentials. API is libsignon-qt/glib? User
enters them in a dialog opened by signon-ui daemon, they get
verified by accounts-provider-plugin. Are they returned to
requesting app as explained in
http://bugs.meego.com/show_bug.cgi?id=5017#c8 ? Does the
accounts-provider-plugin have to do something for this to work?
No. Notice that account-{provider,service}-plugins are only relevant in the
context of the accounts UI; that is, they are only involved when creating or
editing an account, and not when an account is used.
You probably meant "authentication plugin": this is a plugin for the SSO deamon
(signond). When a client wants to authenticate on an account using the method
<examplemethod>, signond loads the signon-<examplemethod>-plugin (actually now I
don't remember the exact name, but what's important is that there is a 1-1
correspondence between methods and SSO plugins).
Now, back to your questions: the client app uses libsignon-{qt,glib} to
authenticate. Depending on the authentication method it wants to use, it will
get a different response; if it uses SASL it will get the SASL response that it
will need to forward to the server, if it uses some web authentication method it
will probably get a token to be used in some REST API, for example, or if it
uses the "password" plugin it will get the password.
The user will not be involved in all this, if the credentials are stored in the
SSO DB.
* Implement signon-ui daemon. API definition, skeleton example?
TODO. Our internal implementation in Nokia will not be opened; instead, we'll
work on a completely open one for MeeGo.
* Adapt web browser. How does it know that pages under
http://www.google.com (or some other domain!) match the account
and/or services define before?
We need one mapping from web address/action URL to account provider/service.
This info is rather static, so I think one could even use the filesystem for
that. For instance, we could have a directory /usr/share/browser/services/ which
contains files named after the domain name, for instance google.com, flickr.com,
and the google.com could contain this XML:
<domain id="google.com">
<mapping url="http://google.com/account"; provider="google">
<mapping url="http://google.com/mail"; provider="google" service="gmail">
</domain>
(even if I'm not sure that the "service" attribute will ever be needed, as
account credentials are rarely stored per service, but rather per account)
* Adapt Buteo, as suggested in #5017. If it runs in the
background, it probably should not pop up a dialog. SessionData
has flags that control that.
I looked at the available material. I found the *signon/account*-doc
packages in MeeGo (kudos to the packager who was diligent enough to
prepare them!) and libsignon-exampleplugin, libsignon-passwordplugin.
Does libsignon-exampleplugin correspond
to /usr/share/doc/signon-plugins-dev/example from libsignon-doc? What
*kind* of plugin is it? There are very few comments in the source.
I'm not sure about the packaging. As I wrote before, this is a signond plugin
(authentication plugin).
What does libsignon-passwordplugin do?
It simply gets the password from signond (as do all other authentication
plugins) but instead of using it to compute some response, it just uses the
password as response, therefore exposing it to the client.
In #5017, one line says:
/* the response() slot will be invoked, and there you can do: */
QString password = sessionData.Secret();
But SessionData in SignOn/SessionData of libsignon-devel-2.0-4.1.i586
does not contain such a Secret() method?
Authentication plugins can come with a -devel package containing some additional
headers which subclass the SessionData and extend it with some additional
fields, specific to the authentication method. The password plugin has this
extra Secret field.
HTH,
Alberto
--
http://blog.mardy.it <-- geek in un lingua international!
_______________________________________________
MeeGo-dev mailing list
[email protected]
http://lists.meego.com/listinfo/meego-dev
