On 12 Apr 2011, at 09:11, Jean-Noël Colin wrote: > 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?
+1 > 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 >>>>>>> >>>>>> >>>> >> >
