Hi

re: 1 and 4, 
SSO extension utilizes appid returned from extension framework, which I hope 
uniquely identifies the webapp and is consistent. This appid is then passed on 
as appcontext to the SSO backend via its APIs. 
code snippet for getting appid in extension: using std::string id_str = 
common::Extension::GetRuntimeVariable("app_id", 64);
I guess we dont need to design SSO per frame as per app is enough.

BR
imran

________________________________________
From: Huo, Halton
Sent: 24 June 2014 10:13
To: Laako, Jussi; Balestrieri, Francesco; Zaman, Imran; 
[email protected]; Santos, Thiago
Subject: RE: [Crosswalk-dev] Intent to implement (RE: WebAPI needed for Single  
Sign on)

Much clear now. Some follow-up questions:

1.       Since webapp are start with xwalk-launcher (same binary name), how 
does gsigonnd identify a webapp then?

2.       Is the webapp developer decide whether the identity can be shared? If 
so, how?

3.       Continued with question 2, Can the target be specified? If yes, HOW?

4.       How the multi-frame cases considered? Background: extensions for 
multi-frames cases are isolated to each other. Should be the SSON be designed 
per app? Not per frame?

Thanks,
Halton.
From: Laako, Jussi
Sent: Tuesday, June 24, 2014 1:12 PM
To: Huo, Halton; Balestrieri, Francesco; Zaman, Imran; 
[email protected]; Santos, Thiago
Subject: RE: [Crosswalk-dev] Intent to implement (RE: WebAPI needed for Single 
Sign on)

ACL is a list allowed methods and mechanisms, like
({method1:[mechanism1, mechanism2]},{method2:[mechanism3, mechanism4]},…)
and allowed security contexts, like
({sysctx1:appctx1},{sysctx2:appctx2},…}

It is part of the gsignond database structure. Applications can be native or 
non-native. The security context was extended to a pair specifically to better 
support runtimes.

For example if Accounts UI stores Identity for your email, it can specify that 
only Email application can access it and only using SASL method. Overall idea 
is that 1) application developer doesn’t need to implement the authentication 
protocol, 2) application doesn’t need to ever see the user’s credential 
(username+password) while it can still perform authentication with it.

The overall flow is described here:
https://01.org/gsso/documentation/functional-view



From: Huo, Halton
Sent: Monday, June 23, 2014 7:24 PM
To: Laako, Jussi; Balestrieri, Francesco; Zaman, Imran; 
[email protected]<mailto:[email protected]>;
 Santos, Thiago
Subject: RE: [Crosswalk-dev] Intent to implement (RE: WebAPI needed for Single 
Sign on)

> 3)      It depends on the used authentication method. The stored item can be 
> shared between applications, based on the ACL defined by the entity who owns 
> it.
How does the ACL looks like? And where the ACL is? Here the “applications” are 
native app or web app or everything? An specific example would help me 
understand.

Thanks,
Halton.
From: Laako, Jussi
Sent: Monday, June 23, 2014 9:21 PM
To: Huo, Halton; Balestrieri, Francesco; Zaman, Imran; 
[email protected]<mailto:[email protected]>;
 Santos, Thiago
Subject: RE: [Crosswalk-dev] Intent to implement (RE: WebAPI needed for Single 
Sign on)

Hi,


1)      libgsignon-glib which in turn has dbus dependency on gsignond (other 
low level dependencies are glib and sqlite3)

2)      At native code level, there’s per-stored-item ACL specifying WHO can 
access the item and HOW

3)      It depends on the used authentication method. The stored item can be 
shared between applications, based on the ACL defined by the entity who owns it.

4)      gSSO, so gsignond, libgsignon-glib and signon-ui-efl or signon-ui-gtk. 
xwalk/HTML5 variant of signon-ui is under construction at the moment.

For the additional questions:

1)      API spec is draft and we are now doing initial implementation for it

2)      Depends on the used signon-ui component, it is some kind of native 
dialog (efl, gtk or xwalk). Usually system modal, but it depends on the 
particular UI component design and environment (desktop, mobile, etc).

3)      State change has self and enum of the current state. onsignedout and 
onremoved only pass the self instance.


Best regards,


-          Jussi



From: Huo, Halton
Sent: Thursday, June 19, 2014 5:34 AM
To: Balestrieri, Francesco; Zaman, Imran; 
[email protected]<mailto:[email protected]>;
 Santos, Thiago
Cc: Laako, Jussi
Subject: RE: [Crosswalk-dev] Intent to implement (RE: WebAPI needed for Single 
Sign on)


Hi Imran,



Sorry for late response, as Franceso said, this intent is very simple, I do not 
see much design para for this API.  I do have some questions for this API:

1. What the dependencies? Are the dependencies are ready on Tizen?

2. What is security concern? For eg Cross-origin scenario.

3. How the SSO on cross app are achieved?

4. What the test environment need setup?



And questions for the spec: 
https://code.google.com/p/accounts-sso/source/browse/widl/signon.widl?repo=libgsignon-glib&name=devel

1. I saw it is on devel branch? What the stage of this spec? Any other vendor 
implement it?

2. 
UserPromptPolicy<https://code.google.com/p/accounts-sso/source/browse/widl/signon.widl?repo=libgsignon-glib&name=devel#22>,
 is the dialog pop up as web prompt or native dialog? Model or non-model?

3. 
AuthSession<https://code.google.com/p/accounts-sso/source/browse/widl/signon.widl?repo=libgsignon-glib&name=devel#66>:
 What the data when statechanged fired? Same question for onsignedout and 
onremoved in interface Identity.



Thanks,

Halton.

> -----Original Message-----

> From: Balestrieri, Francesco

> Sent: Wednesday, June 18, 2014 10:53 PM

> To: Balestrieri, Francesco; Zaman, Imran;

> [email protected]<mailto:[email protected]>;
>  Santos, Thiago; Huo, Halton

> Cc: Laako, Jussi

> Subject: RE: [Crosswalk-dev] Intent to implement (RE: WebAPI needed for

> Single Sign on)

>

> Thiago, Halton, can you LGTM this if OK? Or raise your objections if you

> have them.

>

> Same applies to other owners.

>

> Francesco

>

> > -----Original Message-----

> > From: Crosswalk-dev [mailto:[email protected]

> > project.org] On Behalf Of Balestrieri, Francesco

> > Sent: Tuesday, June 10, 2014 1:44 PM

> > To: Zaman, Imran; 
> > [email protected]<mailto:[email protected]>

> > Cc: Laako, Jussi

> > Subject: [Crosswalk-dev] Intent to implement (RE: WebAPI needed for

> > Single Sign on)

> >

> > Hi,

> >

> > this counts as an Intent to implement, Thiago, Halton and others

> > please comment.

> >

> > Please follow the proper format in the future: https://crosswalk-

> > project.org/#contribute/contributing-code/Declare-your-%22intent-to-

> > implement%22

> >

> > Francesco

> >

> > > -----Original Message-----

> > > From: Crosswalk-dev [mailto:[email protected]

> > > project.org] On Behalf Of Zaman, Imran

> > > Sent: Monday, June 09, 2014 11:05 AM

> > > To: 
> > > [email protected]<mailto:[email protected]>

> > > Cc: Laako, Jussi

> > > Subject: [Crosswalk-dev] WebAPI needed for Single Sign on

> > >

> > > Hei!

> > >

> > > I have started implementation of WebAPI extension on crosswalk for

> gSSO.

> > > Use case is to have support for OAuth and other authentication

> > > methods for web applications. gSSO would also bridge/unify

> > > authentication between native and web applications. More details can

> be found at:

> > >

> > > Crosswalk jira bug is reported at: https://crosswalk-

> > > project.org/jira/browse/XWALK-1877

> > > Tizen jira bug is documented at:

> > > https://bugs.tizen.org/jira/browse/TIVI-

> > > 2718

> > >

> > > Widl file can be accessed at:

> > > http://code.google.com/p/accounts-

> > >

> sso/source/browse/widl/signon.widl?repo=libgsignon-glib&name=devel

> > >

> > > BR

> > > imran

> > > --------------------------------------------------------------------

> > > -

> > > Intel Finland Oy

> > > Registered Address: PL 281, 00181 Helsinki Business Identity Code:

> > > 0357606 -

> > > 4 Domiciled in Helsinki

> > >

> > > This e-mail and any attachments may contain confidential material

> > > for the sole use of the intended recipient(s). Any review or

> > > distribution by others is strictly prohibited. If you are not the

> > > intended recipient, please contact the sender and delete all copies.

> > >

> > > _______________________________________________

> > > Crosswalk-dev mailing list

> > > [email protected]<mailto:[email protected]>

> > > https://lists.crosswalk-project.org/mailman/listinfo/crosswalk-dev

> > ---------------------------------------------------------------------

> > Intel Finland Oy

> > Registered Address: PL 281, 00181 Helsinki Business Identity Code:

> > 0357606 - 4 Domiciled in Helsinki

> >

> > This e-mail and any attachments may contain confidential material for

> > the sole use of the intended recipient(s). Any review or distribution

> > by others is strictly prohibited. If you are not the intended

> > recipient, please contact the sender and delete all copies.

> >

> > _______________________________________________

> > Crosswalk-dev mailing list

> > [email protected]<mailto:[email protected]>

> > https://lists.crosswalk-project.org/mailman/listinfo/crosswalk-dev
---------------------------------------------------------------------
Intel Finland Oy
Registered Address: PL 281, 00181 Helsinki 
Business Identity Code: 0357606 - 4 
Domiciled in Helsinki 

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

_______________________________________________
Crosswalk-dev mailing list
[email protected]
https://lists.crosswalk-project.org/mailman/listinfo/crosswalk-dev

Reply via email to