On Fri, 2010-10-08 at 08:28 +0100, Alberto Mardegan wrote:
> 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. [...]
Okay, so that is probably what Sateesh was thinking of in his statement.
For SyncML, the plain text password may be needed (basic auth method).
For the MD5 hash method, an Accounts&SSO plugin might be able to do the
necessary hashing. But given the time frames and that not all servers
necessarily support the second method, we should focus on retrieving the
password. Same applies to other apps, as you said.
> > 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. :-/
So we have Accounts&SSO in MeeGo 1.1, but we cannot use it? That can't
have been the intention. Please confirm and I'll escalate this :-/
How is the API specific to the UI? I understand that advanced use cases
(drawing your own widgets, for example) may have to depend on some UI
specific extensions, but isn't the common functionality UI independent?
> In some cases the plugin could be just an XML file that describes various
> parameters of the account creation process;
This is the part which I would expect to work regardless whether a MTF,
Qt, or <whatever> implementation of the UI is used.
> and actually it will be the very
> same file as the libaccounts-{qt,glib} provider files.
Do we have examples of those or documentation for them?
> 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).
Let's focus on this aspect, as it seems to be what might already work in
MeeGo 1.1. Coming back to our example, if multiple apps want to share a
Google account, could each app simply create that account using the
libaccounts-{qt,glib} if it doesn't exist yet at the time when the app
settings need it? Then the second app to run can reuse the account and
the credentials entered earlier?
They would need to agree on some common parameters I suppose (like
account name), allow the "password" method and make that account
available to others, right?
Is there some example code, or can you point out the relevant methods?
> > * 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.
So if method "password" is used, the client of libsignon will get the
password entered by the user directly, without any verification whether
it is valid?
Would it be possible to extend the "password" plugin (or write a
derivative) which takes the username/password and tries to use it in a
GET with a specific URL, as specified in the account settings? If there
is a page which uses HTTP authentication and returns an HTTP error
status when that fails, then such an extension would be fairly easy to
write and might apply to multiple different web sites. Not sure whether
Google has such a page, though.
Is the framework already handling incorrectly type passwords, for
example by invoking signon-ui again?
> > * 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.
This becomes off-topic for MeeGo-dev, but do you have a schedule for
this? We probably can live without the account UI, but for the use case
described above we need a password dialog.
One question that I kept wondering about in the context of actually
securing the system against hostile apps: how do we prevent an app from
popping up a dialog which mimics the one used by signon-ui?
The user could easily be spoofed into entering his credentials thinking
that they'll be stored securely, which in fact he is handing them to an
app which might not even be allowed to use the account, much less get
the password as plain text.
> > * 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)
Maintaining this mapping as part of the MeeGo system installation sounds
like a maintenance problem to me. Certainly some predefined URLs will be
useful, but I can imagine that a browser user might want to extend the
list by associating additional URLs with existing accounts. Just my 2
cents.
> > 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.
This doesn't seem to be packaged in MeeGo at this time:
# zypper search signon | grep password
i | libsignon-passwordplugin | Plain Password plugin for Single Sign On |
package
# rpm -q -l libsignon-passwordplugin
/usr/lib/signon/libpasswordplugin.so
No surprise that I haven't found 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.
_______________________________________________
MeeGo-dev mailing list
[email protected]
http://lists.meego.com/listinfo/meego-dev
