Hello Jaehwa,
I'm in the team that has developed gSSO and I would like to provide some
clarifications and corrections, please see below.
On 11/25/2013 05:26 PM, 신재화 wrote:
1. plug-in system
- Although gSSO's plug-in system allows us to extend features easily, it
has a critical drawback that
we cannot trust the plugins from 3rd-parties. Because the plug-ins are
loaded and executed by gSSO daemon(gsignond)
malicious plug-ins can harm the system stability.
I'm sure that we should not allow 3rd party plug-ins to be installed on
the device.
gSSO runs the authentication plugins in separate processes, and
communicates with those processes over pipes. This is the code in gSSO
that starts the plugin process:
http://code.google.com/p/accounts-sso/source/browse/src/daemon/plugins/gsignond-plugin-remote.c?repo=gsignond
(look especially for the gsignond_plugin_remote_new() function)
And this is the code that implements the plugin process, loads the
plugin and communicates with the gSSO daemon:
http://code.google.com/p/accounts-sso/source/browse/?repo=gsignond#git%2Fsrc%2Fdaemon%2Fplugins%2Fplugind
So malicious plugins do not have access to gSSO daemon's memory space,
and they cannot crash the gSSO daemon process. We also kill a plugin
process with SIGKILL if it doesn't respond to SIGTERM within a short
time (gets stuck).
2. Integration with account
- Tizen already have account implementation while gSSO has its own.
But it is not necessary to use gSSO's account for gSSO's SSO.
So instead of replacing current account impl with gSSO's, I'm going to
keep the current account impl.
- I will not provide Native gSSO client library wrapper but extend
account module to support SSO.
gSSO will be created by system when creating an account if the account
supports SSO. The accounts which supports SSO will
have one connected gSSO identity.
The details of this should be up to you, but for interfacing to gSSO you
should be using the libgsignon-glib library - that's the only official,
supported API.
3. Support of storing different tokens for the same account
- Some account might have multiple access tokens for the same account. But
there is no way to store multiple access tokens
for the same identity.
Actually there is, and the OAuth2 plugin is making use of it to store
multiple access tokens per identity, indexed by their scopes.
Each identity-method entry in the gSSO database has an opaque binary
data field, which is passed to the plugin and received from it. It's
entirely up to the plugin what to store in that field and in what format.
The OAuth2 plugin is using it to store a dictionary of access tokens,
indexed by scope. It also makes sure to handle the scopes correctly, for
example if an application requests a token with scope "music" and there
is a token with "music videos photos", the plugin simply returns that
token. Similarly, if a token with "music videos photos" is received from
the server, it will replace all tokens with more narrow scopes, such as
"music photos".
The code for this logic is here:
http://code.google.com/p/accounts-sso/source/browse/src/gsignond-oauth-plugin-oauth2.c?repo=gsignond-plugin-oa
(look for _find_token_in_cache and _insert_token_in_cache functions)
Thanks in advance for your feedback.
Thanks for your feedback too, let us know if anything is still unclear,
or if there is something that gSSO should do differently.
Regards,
Alexander
_______________________________________________
Dev mailing list
[email protected]
https://lists.tizen.org/listinfo/dev
