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 >>>>> >>>> >>
