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.
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. We'll look into this further, but don't hesitate to share your comments/ideas. 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 >>> >>
