You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@wookie.apache.org by Jean-Noël Colin <je...@fundp.ac.be> on 2011/04/08 08:40:18 UTC
Question about widget instance/session
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.
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?
Cheers
---
Jean-Noël
Re: Question about widget instance/session
Posted by Scott Wilson <sc...@gmail.com>.
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 <je...@fundp.ac.be> 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 <sc...@gmail.com> 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
>>>>>>>
>>>>>>
>>>>
>>
>
Re: Question about widget instance/session
Posted by Jean-Noël Colin <je...@fundp.ac.be>.
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 <je...@fundp.ac.be> 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 <sc...@gmail.com> 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
>>>>>>
>>>>>
>>>
>
Re: Question about widget instance/session
Posted by Scott Wilson <sc...@gmail.com>.
On 11 Apr 2011, at 09:45, Ross Gardler wrote:
> On 11 Apr 2011, at 08:06, Jean-Noël Colin <je...@fundp.ac.be> 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 <sc...@gmail.com> 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
>>>>>
>>>>
>>
Re: Question about widget instance/session
Posted by Ross Gardler <rg...@apache.org>.
On 11 Apr 2011, at 08:06, Jean-Noël Colin <je...@fundp.ac.be> 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 <sc...@gmail.com> 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
>>>>
>>>
>
Re: Question about widget instance/session
Posted by Jean-Noël Colin <je...@fundp.ac.be>.
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 <sc...@gmail.com> 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
>>>
>>
Re: Question about widget instance/session
Posted by Ross Gardler <rg...@apache.org>.
Sent from my mobile device.
On 8 Apr 2011, at 08:22, Scott Wilson <sc...@gmail.com> 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
>>
>
Re: Question about widget instance/session
Posted by Scott Wilson <sc...@gmail.com>.
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.
> 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?
>
> Cheers
>
> ---
> Jean-Noël
>