On 10/08/2010 09:43 PM, Patrick Ohly wrote:
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.
Without a working security framework, all apps can access any identity.
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?
Think of them as sub-methods. This makes most sense for the SASL plugin:
for the "sasl" method, mechanisms map to the SASL 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?
Yes. The two frameworks makes most sense when used them together, but
they are orthogonal: if you don't care about security and authentication
methods you can store the password in plain text into the accounts DB;
on the other hand if your application already has its own account
storage and you don't want to share the account with other apps, then
you could use SSO only.
FWIW, the Account class has setCredentialsId()/credentialsId() methods.
Are the identities created automatically for each account?
No. And these methods are just helper methods: if you look at the
implementation, you'll see that they simply access the value set in the
"CredentialsId" key.
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?
Well, the option to suggest is also possible, but not all apps can write
to the identity. Actually, IIRC, with a working security framework only
the application which created the identity is allowed to modify it (plus
signon and signon-ui).
Also note that some authentication plugins who directly authenticate
over the network with the service provider (this could be the case of
the advanced password plugin you suggested before) can detect that the
password is wrong, because they receive an error code from the server.
In such cases, before returning the response to the app, signond would
get signon-ui to show a password query to the user and attempt the
authentication once more (if the SessionData::UIPolicy allows that). And
if successful, the new password would be stored in the SSO DB.
So in some cases the application might not even know about this.
Ciao,
Alberto
--
http://blog.mardy.it <- geek in un lingua international!
_______________________________________________
MeeGo-dev mailing list
[email protected]
http://lists.meego.com/listinfo/meego-dev
