On Fri, 2010-10-08 at 11:03 +0200, Patrick Ohly wrote:
> On Fri, 2010-10-08 at 08:28 +0100, Alberto Mardegan wrote:
> > 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?
I've looked around a bit, trying to figure it out by myself. The main
documentation is packaged in libsignon-doc.
Secrets are attached to instances of class Identity, which are in turn
created initially by creating an IdentityInfo (Identity::newIdentity()).
The initial IdentityInfo defines access rights. Applications are
identified by strings (IdentityInfo::setAccessControlList()). Who
defines these strings? The security framework isn't working in MeeGo
yet, so how is this access control enforced at the moment in MeeGo?
Is it possible to grant access to arbitrary apps? Without a working
enforcement mechanism, the need to declare apps is just a maintenance
problem without any gain.
My next question is about IdentityInfo::setMethod(const MethodName
&method, const MechanismsList &mechanismsList). Methods and mechanisms
are identified by strings. "Method" is something like the "password"
method, but what are the mechanisms?
We've talked about account handling. But from looking at the signon API,
nothing seems to depend on an Account instance. So can we ignore that
part and use just SSO without Accounts?
FWIW, the Account class has setCredentialsId()/credentialsId() methods.
Are the identities created automatically for each account?
> > > * 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.
Or perhaps not. If every app is able to pop up its own dialog and
allowed to store that password, then no signon-ui dialog should ever be
needed - right?
--
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
