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. > 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. SSO would be the ultimate goal, but let's get something that works first, we can build on that later. Ross > > 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 >>>> >>> >
