Best Regards, Jaehwa Shin
On Tue, Nov 26, 2013 at 10:47 PM, Alexander Kanavin < [email protected]> wrote: > 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). > > Thanks for your corrections. I'd just read a few documents and thought the plug-ins run in gsignond process. It sounds great that plug-ins run in separate processes(I considered providing this model on Native SSO framework layer). I agree that my concerns about gSSO's plug-in system are not valid with the current gSSO plug-in system. And have some questions. What is the life-cycle of the plug-in processes? Are they created per session? or per plug-in? > > > 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. > > The reason for not providing Native gSSO wrapper is that we do not want to expose two similar concepts to application developers : account and (gSSO) identity Tizen already supports account management and there is a set of Native APIs for it. We want application developers to use SSO without knowing the concept of identity which can be confused with account, so we will provide SSO by extending the Tizen account module. Of course, we will use libgsignon-glib library to implement the SSO features in account management module. However we will provide Native gSSO plug-in library for Native gSSO plug-in developers. (Native means Tizen C++ 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 for your corrections. > > 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, Jaehwa
_______________________________________________ Dev mailing list [email protected] https://lists.tizen.org/listinfo/dev
