This the conclusion I would draw is that we need to build around the notion of 'widget session', that would distinguish between two environments accessing the same widget instance. Do we agree on this? We'll then take it as a starting point to elaborate further
Cheers --- Jean-Noël On 11 Apr 2011, at 11:10, Scott Wilson wrote: > > On 11 Apr 2011, at 09:45, Ross Gardler wrote: > >> On 11 Apr 2011, at 08:06, Jean-Noël Colin <[email protected]> >> wrote: >> >>> I guess we all agree that making a widget accessibility dependent on the >>> idkey only can lead to security problems, in case the widget is used to >>> access somewhat protected data and someone malicious gets access to the >>> idkey. >> >> Yes. > > Yes... > >> >>> The widget session could be a solution, but in that case, accessing the >>> same widget instance from a different environment would require >>> establishing a new session, thus some authentication. Unless we can think >>> of some form of SSO from the environment to the service served by the shell. >> >> I'd say requiring a login from each environment is fine. Ideally we'd trust >> the host environment login, with a default to individual widget login (if >> host is not trusted or has no login). > > >> Let's start with the simplest case first and have individual widget logins >> that allows an "instance" to be hosted in two separate locations (with >> separate logins). >> >> Once that's in place we can look into extending the connector framework to >> hook into the host authentication system. > > We should definitely use host assertions where available, and then have a > simple mechanism that can be used when embedding widgets in other > environments. > > We may also want to define cases where no-auth embedding is allowed, or can > be enabled by users. For example, there is no real risk involved in embedding > the Weather widget on a netvibes page. > >> >> SSO would be the ultimate goal, but let's get something that works first, we >> can build on that later. > > +1 > >> >> Ross >> >>> >>> We'll look into this further, but don't hesitate to share your >>> comments/ideas. > > Thanks! > >>> >>> Best regards >>> >>> --- >>> Jean-Noël >>> >>> On 08 Apr 2011, at 09:45, Ross Gardler wrote: >>> >>>> Sent from my mobile device. >>>> >>>> On 8 Apr 2011, at 08:22, Scott Wilson <[email protected]> >>>> wrote: >>>> >>>>> On 8 Apr 2011, at 07:40, Jean-Noël Colin wrote: >>>>> >>>>>> Hi Scott, >>>>>> >>>>>> We're together with Tien wondering about the notion of widget instance >>>>>> and that of a session. >>>>>> >>>>>> A widget instance is identified by the idkey, which is specific for an >>>>>> api key, shared data key, widget id, user id. This means that if I can >>>>>> get hold of the idkey, I can access the widget instance, even from >>>>>> outside the original environment. >>>>>> >>>>>> If we think of widgets that give access to privileged services, like >>>>>> access to the iTec registries, this becomes a security problem, because >>>>>> if my idkey gets stolen, someone else could pretend being me. >>>>> >>>>> To be honest I'm torn between thinking of this as a bug or a feature. >>>> >>>> Its a feature. >>>> >>>> I want to be able to have the same widget instance in multiple locations. >>>> Not different users, but same user different locations. >>>> >>>> Any solution needs to accommodate this feature, not break it. >>>> >>>>> >>>>>> One way to solve this would be to go beyond the widget instance, and >>>>>> have a notion of session, which means that even if someone else gets my >>>>>> idkey, he would still appear as a different session; if oauth tokens are >>>>>> managed on the basis of a session, then, stealing my idkey would not >>>>>> compromise access to the services. >>>>> >>>>>> >>>>>> Of course, this poses the issue of token management. >>>>>> >>>>>> We are thinking of different solutions: one would be to use one-time >>>>>> idkey, rather than permanent one, so that if an idkey gets stolen, >>>>>> nothing gets compromised. So basically, the idea is to integrate the >>>>>> notion of session or to have a one-time handle to widget instances, >>>>>> renewed on every request. >>>>>> >>>>>> What do you think about this? Does it make sense? >>>>> >>>>> I think these sound like interesting ideas - however can we have the best >>>>> of both worlds? Widgets that are simple to embed outside their original >>>>> context, but still protect user's privileged service access? >>>> >>>> Session alone is no good for this because If I close one session all keys >>>> get invalidated. That is unless we think of a session as being a widget >>>> session rather than browser session. >>>> >>>> Ross >>>> >>>>> >>>>>> >>>>>> Cheers >>>>>> >>>>>> --- >>>>>> Jean-Noël >>>>>> >>>>> >>> >
