You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@rave.apache.org by Jasha Joachimsthal <j....@onehippo.com> on 2012/03/02 18:07:28 UTC
Managing OAuth tokens (RAVE-500)
For (3-legged) OAuth the consumer key and secret need to be stored inside
the database. At the moment it can only be done by hand, but that should be
moved to some admin interface. Our admin interface is a part of the portal,
but the OAuth model, service and repository is a part of Rave-Shindig.
If we move o.a.r.gadgets.oauth.model/repository/service to rave-core should
it remain in its current package?
Jasha Joachimsthal
Europe - Amsterdam - Oosteinde 11, 1017 WT Amsterdam - +31(0)20 522 4466
US - Boston - 1 Broadway, Cambridge, MA 02142 - +1 877 414 4776 (toll free)
www.onehippo.com
RE: Managing OAuth tokens (RAVE-500)
Posted by "Franklin, Matthew B." <mf...@mitre.org>.
>-----Original Message-----
>From: Ate Douma [mailto:ate@douma.nu]
>Sent: Tuesday, March 06, 2012 3:37 AM
>To: rave-dev@incubator.apache.org
>Subject: Re: Managing OAuth tokens (RAVE-500)
>
>On 03/06/2012 09:29 AM, Ate Douma wrote:
>> On 03/06/2012 08:36 AM, Jasha Joachimsthal wrote:
>>> On 6 March 2012 04:09, Ate Douma<at...@douma.nu> wrote:
>>>
>>>> On 03/05/2012 05:03 PM, Franklin, Matthew B. wrote:
>>>>
>>>>> -----Original Message-----
>>>>>> From: Ate Douma [mailto:ate@douma.nu]
>>>>>> Sent: Monday, March 05, 2012 10:35 AM
>>>>>> To: rave-dev@incubator.apache.org
>>>>>> Subject: Re: Managing OAuth tokens (RAVE-500)
>>>>>>
>>>>>> On 03/05/2012 04:00 PM, Franklin, Matthew B. wrote:
>>>>>>
>>>>>>> -----Original Message-----
>>>>>>>> From: Jasha Joachimsthal
>>>>>>>>
>[mailto:j.joachimsthal@**onehippo.com<j....@onehippo.com>
>>>>>>>> ]
>>>>>>>> Sent: Monday, March 05, 2012 9:56 AM
>>>>>>>> To: rave-dev@incubator.apache.org
>>>>>>>> Subject: Re: Managing OAuth tokens (RAVE-500)
>>>>>>>>
>>>>>>>> On 5 March 2012 15:35, Franklin, Matthew B.<mf...@mitre.org>
>>>>>>>>
>>>>>>> wrote:
>>>>>>
>>>>>>>
>>>>>>>> -----Original Message-----
>>>>>>>>>> From: Jasha Joachimsthal
>>>>>>>>>>
>[mailto:j.joachimsthal@**onehippo.com<j....@onehippo.com>
>>>>>>>>>> ]
>>>>>>>>>> Sent: Friday, March 02, 2012 12:07 PM
>>>>>>>>>> To: rave-dev@incubator.apache.org
>>>>>>>>>> Subject: Managing OAuth tokens (RAVE-500)
>>>>>>>>>>
>>>>>>>>>> For (3-legged) OAuth the consumer key and secret need to be
>stored
>>>>>>>>>>
>>>>>>>>> inside
>>>>>>>>
>>>>>>>>> the database. At the moment it can only be done by hand, but that
>>>>>>>>>>
>>>>>>>>> should
>>>>>>
>>>>>>> be
>>>>>>>>>
>>>>>>>>>> moved to some admin interface. Our admin interface is a part of
>the
>>>>>>>>>>
>>>>>>>>> portal,
>>>>>>>>>
>>>>>>>>>> but the OAuth model, service and repository is a part of
>>>>>>>>>> Rave-Shindig.
>>>>>>>>>> If we move o.a.r.gadgets.oauth.model/**repository/service to
>>>>>>>>>> rave-core
>>>>>>>>>>
>>>>>>>>> should
>>>>>>>>>
>>>>>>>>>> it remain in its current package?
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> I think that the consumer key& secret need to be read& writable
>>>>>>>>> from
>>>>>>>>> core Rave; but, the majority of the functionality you built for
>>>>>>>>> managing
>>>>>>>>> the authorization tokens etc IMHO doesn't belong in Rave.
>Thoughts?
>>>>>>>>>
>>>>>>>>>
>>>>>>>> The OAuth keys& secrets are not a part of the portal, so they should
>>>>>>>> be
>>>>>>>> managed by Rave-Shindig, but we don't have a manage UI for
>Shindig. We
>>>>>>>> could create a REST interface to manage the keys& secrets, but only
>>>>>>>> the
>>>>>>>> portal knows if someone has the admin privileges to actually
>manage
>>>>>>>>
>>>>>>> them.
>>>>>>
>>>>>>>
>>>>>>> The keys and secret are part of the gadget, which is managed by the
>>>>>>> portal;
>>>>>>>
>>>>>> albeit in a generic way. Could we tie them to the generic Widget
>object?
>>>>>>
>>>>>> Maybe we should consider to at least also support using an external
>OAuth
>>>>>> SP?
>>>>>>
>>>>>> There are several dedicated security/identity service providers and/or
>>>>>> engines
>>>>>> (supporting much more than just OAuth) which could be leveraged in.
>>>>>>
>>>>>> While having a default (simple) out-of-the-box implementation by
>Rave
>>>>>> makes
>>>>>> sense, for more enterprise level installments you can expect
>>>>>> requirements to
>>>>>> integrate with already existing security providers for this and other
>>>>>> purpose.
>>>>>>
>>>>>> I would think our default/embedded OAuth SP should be 'just' a
>pluggable
>>>>>> service, which can and should provide its own admin UI (widget-based
>or
>>>>>> otherwise).
>>>>>>
>>>>>> It might be useful to support 'revoking' individual OAuth tokens directly
>>>>>> through some Widget chrome action, but for general keys and secrets
>>>>>> management I
>>>>>> think we'll need to provide a separate UI (or delegate to external
>>>>>> tooling).
>>>>>>
>>>>>
>>>>> I completely agree with your approach when it comes to protecting Rave
>>>>> resources with OAuth, but in the case of OpenSocial gadget (I don't
>know
>>>>> enough about OAuth for other widget types to comment) keys&
>secrets, they
>>>>> are provided to the embedded Shindig OAuth SP for any real work. The
>only
>>>>> thing we do is implement a storage mechanism. Shindig also only keeps
>>>>> access tokens for use; but, doesn't manage their revocation or grants.
>>>>> That is the responsibility of the OAuth service they are accessing.
>>>>>
>>>> Right, I was taking about an OAuth authorization provider service with an
>>>> OAuth consumer (client in OAuth 2).
>>>> I should have better checked the topic of RAVE-500 which clearly is about
>>>> OAuth consumer requirements.
>>>>
>>>>
>>>>> Gadget developers typically register the gadget with a service endpoint
>>>>> to obtain the key/secret pair and need a way to simply store the
>>>>> information with the gadget such that it is retrievable by Shindig. Often,
>>>>> these services live outside of the firewall (Google, Twitter, etc) and
>>>>> really have nothing to do with the enterprise. That doesn't mean that
>>>>> there couldn't be some external keystore, but its job would be to blindly
>>>>> store consumer keys& secrets for a target entity, which seems to me to
>be
>>>>> of limited value.
>>>>>
>>>>>
>>>>> Given this is the case we are looking to solve at the moment, what
>>>>> approach would you recommend?
>>>>>
>>>>
>>>> Well, this is quite interesting.
>>>> I must confess I never actually manually setup/registered an OAuth
>>>> consumer key/secret myself, but although by the spec this process is
>>>> undefined, AFAIK typically this is something done based on the concrete
>>>> consumer/client domain, like if you use Google (see Rave oauth-
>consumer
>>>> documentation).
>>>> It which case it is not the Gadget *developer* but the portal/container
>>>> *manager* who is responsible for setting up these consumer/client
>>>> key/secrets...
>>>>
>>>> The Gadget URL is required and a key for the Shindig
>OAuthConsumerStore,
>>>> but that can be unrelated to and independent of the site/domain where
>the
>>>> Gadget is actually rendered.
>>>> And in the Google case these consumer key/secrets are indeed
>independent
>>>> of the actual Gadget used to access the secured resource (just not for
>>>> Shindig which doesn't know this).
>>>>
>>>> From Shindig perspective I agree then the consumer key/secret should
>be
>>>> regarded as part of the Gadget *definition* meta-data, but different
>from
>>>> user related and even Gadget *instance* (moduleId) related data like the
>>>> AppDataStore. And this is data which needs to be *seeded* upfront,
>before
>>>> first time rendering. These two aspects makes this different and kind of
>>>> weird from an SPI perspective as Shindig doesn't provide a service to
>>>> create and store these.
>>>>
>>>
>>>> Oh, and possibly an even further complicating aspect for again the Google
>>>> case: is the client domain you need to register with Google based on the
>>>> *portal* domain or the domain hosting the container (Shindig) itself?
>>>>
>>>
>>> Neither. I registered the domain that hosts the gadget definition, but I
>>> don't know if that is actually correct. It does work though..
>>
>> Ah, that is interesting.
>> But also seems weird as the Google documentation for OAuth registration
>says you
>> should register your webapp domain. And the domain hosting the gadget
>definition
>> really doesn't have to be your own webapp.
>>
>> However, if this is true (and the Google documentation is wrong?), *then*
>this
>> simplifies the discussion quite a lot. And of course this then also needs to
>> hold true for *all* OAuth Authorization Providers.
>> Because then this actually might be gadget URL based (not portal and/or
>instance
>> based).
>
>Giving this a bit more thought, I really don't belief this can work: an oauth
>consumer key/secret cannot be tied to the domain hosting the gadget
>definition
>as it may not be assumed that domain is 'owned' and controlled by the client
>(portal/container) at all. Nor representative for any and all clients using that
>gadget definition.
It is functional, but not optimal. AIUI, the consumer key is intended to be the actual application accessing the data. I know an argument could be made that the gadget is the application, but just imagine how difficult it gets to manage the security when 30 servers are connecting as the same consumer...
>
>>
>>>
>>>
>>>> I expect and do hope it is the portal domain otherwise you'll could end up
>>>> with requiring separate consumer key/secrets if you start clustering
>>>> multiple Shindig container nodes! For now I assume the first...
>>>>
>>>> From an administration POV then I think we need to add our own
>>>> rave-shindig SPI to maintain the OAuthConsumerStoreRepository. And/or
>start
>>>> discussing with Shindig team if that should be added to Shindig SPI too.
>>>>
>>>> On the other hand, the Shindig SPI is largely lacking in serious
>>>> administrative features anyway. Consider deleting a previously used
>gadget
>>>> definition from the portal. Or even only a Gadget instance
>>>> (siteId/modulId)? How should we efficiently cleanup the related AppData
>>>> across every user? The SPI doesn't provide the proper APIs for that
>either.
>>>>
>>>> Anyway, I think an administration UI for this and such services should
>>>> belong to the portal, especially as they are indeed tied to the Gadget
>>>> meta-data definition maintained by the portal already (and only).
>>>>
>>>
>>> Is it really a part of the portal? What if I replace Rave-Shindig with an
>>> externally hosted OpenSocial container? Shouldn't that container contain
>>> the OAuth keys and secrets? In the end it is Shindig (in our case) that
>>> handles OAuth, not the portal.
>> Well, handling OAuth concerns the handshake, not necessarily the
>ownership or
>> maintenance of the data. And as I said: Shindig doesn't provide an SPI for
>> maintenance of this consumer key/secret data, only read access.
>> Shindig also doesn't 'manage' the widget meta-data but expects that to be
>> transiently passed in. So it seems to me we can/should tread OAuth
>consumer
>> key/secets similar.
>>
>>>
>>>
>>>>
>>>> I also think this issue is helpful with the roadmap discussion today about
>>>> widget catalogs. IMO it clearly highlights (from an OpenSocial perspective
>>>> at least) that while external widget catalogs can be supported, the portal
>>>> will at least also need to maintain its own registry of widget definitions
>>>> (as well as instances thereof: siteId/moduleId). If only in a minimal
>>>> fashion to provide maintenance for portal specific data like OAuth
>consumer
>>>> key/secrets and AppData. And probably more.
>>>>
>>>> And all of this then brings up another question: how to handle 'shared'
>>>> data.
>>>> Which is yet another roadmap discussion IMO...
>>>>
>>>> @Jasha: terrific question :)
>>>>
>>>
>>> The issue seemed so trivial "create a admin page for consumer keys and
>>> secrets"...
>> Nothing really is trivial if you intend to create a platform or engine :)
>>
>>>
>>>
>>>>
>>>> Ate
>>>>
>>>>
>>>>
>>>>
>>>>>
>>>>>>
>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>>> Jasha Joachimsthal
>>>>>>>>>>
>>>>>>>>>> Europe - Amsterdam - Oosteinde 11, 1017 WT Amsterdam -
>+31(0)20 522
>>>>>>>>>>
>>>>>>>>> 4466
>>>>>>>>
>>>>>>>>> US - Boston - 1 Broadway, Cambridge, MA 02142 - +1 877 414 4776
>(toll
>>>>>>>>>>
>>>>>>>>> free)
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> www.onehippo.com
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>
>>>>
>>>
>>
Re: Managing OAuth tokens (RAVE-500)
Posted by Ate Douma <at...@douma.nu>.
On 03/06/2012 09:29 AM, Ate Douma wrote:
> On 03/06/2012 08:36 AM, Jasha Joachimsthal wrote:
>> On 6 March 2012 04:09, Ate Douma<at...@douma.nu> wrote:
>>
>>> On 03/05/2012 05:03 PM, Franklin, Matthew B. wrote:
>>>
>>>> -----Original Message-----
>>>>> From: Ate Douma [mailto:ate@douma.nu]
>>>>> Sent: Monday, March 05, 2012 10:35 AM
>>>>> To: rave-dev@incubator.apache.org
>>>>> Subject: Re: Managing OAuth tokens (RAVE-500)
>>>>>
>>>>> On 03/05/2012 04:00 PM, Franklin, Matthew B. wrote:
>>>>>
>>>>>> -----Original Message-----
>>>>>>> From: Jasha Joachimsthal
>>>>>>> [mailto:j.joachimsthal@**onehippo.com<j....@onehippo.com>
>>>>>>> ]
>>>>>>> Sent: Monday, March 05, 2012 9:56 AM
>>>>>>> To: rave-dev@incubator.apache.org
>>>>>>> Subject: Re: Managing OAuth tokens (RAVE-500)
>>>>>>>
>>>>>>> On 5 March 2012 15:35, Franklin, Matthew B.<mf...@mitre.org>
>>>>>>>
>>>>>> wrote:
>>>>>
>>>>>>
>>>>>>> -----Original Message-----
>>>>>>>>> From: Jasha Joachimsthal
>>>>>>>>> [mailto:j.joachimsthal@**onehippo.com<j....@onehippo.com>
>>>>>>>>> ]
>>>>>>>>> Sent: Friday, March 02, 2012 12:07 PM
>>>>>>>>> To: rave-dev@incubator.apache.org
>>>>>>>>> Subject: Managing OAuth tokens (RAVE-500)
>>>>>>>>>
>>>>>>>>> For (3-legged) OAuth the consumer key and secret need to be stored
>>>>>>>>>
>>>>>>>> inside
>>>>>>>
>>>>>>>> the database. At the moment it can only be done by hand, but that
>>>>>>>>>
>>>>>>>> should
>>>>>
>>>>>> be
>>>>>>>>
>>>>>>>>> moved to some admin interface. Our admin interface is a part of the
>>>>>>>>>
>>>>>>>> portal,
>>>>>>>>
>>>>>>>>> but the OAuth model, service and repository is a part of
>>>>>>>>> Rave-Shindig.
>>>>>>>>> If we move o.a.r.gadgets.oauth.model/**repository/service to
>>>>>>>>> rave-core
>>>>>>>>>
>>>>>>>> should
>>>>>>>>
>>>>>>>>> it remain in its current package?
>>>>>>>>>
>>>>>>>>
>>>>>>>> I think that the consumer key& secret need to be read& writable
>>>>>>>> from
>>>>>>>> core Rave; but, the majority of the functionality you built for
>>>>>>>> managing
>>>>>>>> the authorization tokens etc IMHO doesn't belong in Rave. Thoughts?
>>>>>>>>
>>>>>>>>
>>>>>>> The OAuth keys& secrets are not a part of the portal, so they should
>>>>>>> be
>>>>>>> managed by Rave-Shindig, but we don't have a manage UI for Shindig. We
>>>>>>> could create a REST interface to manage the keys& secrets, but only
>>>>>>> the
>>>>>>> portal knows if someone has the admin privileges to actually manage
>>>>>>>
>>>>>> them.
>>>>>
>>>>>>
>>>>>> The keys and secret are part of the gadget, which is managed by the
>>>>>> portal;
>>>>>>
>>>>> albeit in a generic way. Could we tie them to the generic Widget object?
>>>>>
>>>>> Maybe we should consider to at least also support using an external OAuth
>>>>> SP?
>>>>>
>>>>> There are several dedicated security/identity service providers and/or
>>>>> engines
>>>>> (supporting much more than just OAuth) which could be leveraged in.
>>>>>
>>>>> While having a default (simple) out-of-the-box implementation by Rave
>>>>> makes
>>>>> sense, for more enterprise level installments you can expect
>>>>> requirements to
>>>>> integrate with already existing security providers for this and other
>>>>> purpose.
>>>>>
>>>>> I would think our default/embedded OAuth SP should be 'just' a pluggable
>>>>> service, which can and should provide its own admin UI (widget-based or
>>>>> otherwise).
>>>>>
>>>>> It might be useful to support 'revoking' individual OAuth tokens directly
>>>>> through some Widget chrome action, but for general keys and secrets
>>>>> management I
>>>>> think we'll need to provide a separate UI (or delegate to external
>>>>> tooling).
>>>>>
>>>>
>>>> I completely agree with your approach when it comes to protecting Rave
>>>> resources with OAuth, but in the case of OpenSocial gadget (I don't know
>>>> enough about OAuth for other widget types to comment) keys& secrets, they
>>>> are provided to the embedded Shindig OAuth SP for any real work. The only
>>>> thing we do is implement a storage mechanism. Shindig also only keeps
>>>> access tokens for use; but, doesn't manage their revocation or grants.
>>>> That is the responsibility of the OAuth service they are accessing.
>>>>
>>> Right, I was taking about an OAuth authorization provider service with an
>>> OAuth consumer (client in OAuth 2).
>>> I should have better checked the topic of RAVE-500 which clearly is about
>>> OAuth consumer requirements.
>>>
>>>
>>>> Gadget developers typically register the gadget with a service endpoint
>>>> to obtain the key/secret pair and need a way to simply store the
>>>> information with the gadget such that it is retrievable by Shindig. Often,
>>>> these services live outside of the firewall (Google, Twitter, etc) and
>>>> really have nothing to do with the enterprise. That doesn't mean that
>>>> there couldn't be some external keystore, but its job would be to blindly
>>>> store consumer keys& secrets for a target entity, which seems to me to be
>>>> of limited value.
>>>>
>>>>
>>>> Given this is the case we are looking to solve at the moment, what
>>>> approach would you recommend?
>>>>
>>>
>>> Well, this is quite interesting.
>>> I must confess I never actually manually setup/registered an OAuth
>>> consumer key/secret myself, but although by the spec this process is
>>> undefined, AFAIK typically this is something done based on the concrete
>>> consumer/client domain, like if you use Google (see Rave oauth-consumer
>>> documentation).
>>> It which case it is not the Gadget *developer* but the portal/container
>>> *manager* who is responsible for setting up these consumer/client
>>> key/secrets...
>>>
>>> The Gadget URL is required and a key for the Shindig OAuthConsumerStore,
>>> but that can be unrelated to and independent of the site/domain where the
>>> Gadget is actually rendered.
>>> And in the Google case these consumer key/secrets are indeed independent
>>> of the actual Gadget used to access the secured resource (just not for
>>> Shindig which doesn't know this).
>>>
>>> From Shindig perspective I agree then the consumer key/secret should be
>>> regarded as part of the Gadget *definition* meta-data, but different from
>>> user related and even Gadget *instance* (moduleId) related data like the
>>> AppDataStore. And this is data which needs to be *seeded* upfront, before
>>> first time rendering. These two aspects makes this different and kind of
>>> weird from an SPI perspective as Shindig doesn't provide a service to
>>> create and store these.
>>>
>>
>>> Oh, and possibly an even further complicating aspect for again the Google
>>> case: is the client domain you need to register with Google based on the
>>> *portal* domain or the domain hosting the container (Shindig) itself?
>>>
>>
>> Neither. I registered the domain that hosts the gadget definition, but I
>> don't know if that is actually correct. It does work though..
>
> Ah, that is interesting.
> But also seems weird as the Google documentation for OAuth registration says you
> should register your webapp domain. And the domain hosting the gadget definition
> really doesn't have to be your own webapp.
>
> However, if this is true (and the Google documentation is wrong?), *then* this
> simplifies the discussion quite a lot. And of course this then also needs to
> hold true for *all* OAuth Authorization Providers.
> Because then this actually might be gadget URL based (not portal and/or instance
> based).
Giving this a bit more thought, I really don't belief this can work: an oauth
consumer key/secret cannot be tied to the domain hosting the gadget definition
as it may not be assumed that domain is 'owned' and controlled by the client
(portal/container) at all. Nor representative for any and all clients using that
gadget definition.
>
>>
>>
>>> I expect and do hope it is the portal domain otherwise you'll could end up
>>> with requiring separate consumer key/secrets if you start clustering
>>> multiple Shindig container nodes! For now I assume the first...
>>>
>>> From an administration POV then I think we need to add our own
>>> rave-shindig SPI to maintain the OAuthConsumerStoreRepository. And/or start
>>> discussing with Shindig team if that should be added to Shindig SPI too.
>>>
>>> On the other hand, the Shindig SPI is largely lacking in serious
>>> administrative features anyway. Consider deleting a previously used gadget
>>> definition from the portal. Or even only a Gadget instance
>>> (siteId/modulId)? How should we efficiently cleanup the related AppData
>>> across every user? The SPI doesn't provide the proper APIs for that either.
>>>
>>> Anyway, I think an administration UI for this and such services should
>>> belong to the portal, especially as they are indeed tied to the Gadget
>>> meta-data definition maintained by the portal already (and only).
>>>
>>
>> Is it really a part of the portal? What if I replace Rave-Shindig with an
>> externally hosted OpenSocial container? Shouldn't that container contain
>> the OAuth keys and secrets? In the end it is Shindig (in our case) that
>> handles OAuth, not the portal.
> Well, handling OAuth concerns the handshake, not necessarily the ownership or
> maintenance of the data. And as I said: Shindig doesn't provide an SPI for
> maintenance of this consumer key/secret data, only read access.
> Shindig also doesn't 'manage' the widget meta-data but expects that to be
> transiently passed in. So it seems to me we can/should tread OAuth consumer
> key/secets similar.
>
>>
>>
>>>
>>> I also think this issue is helpful with the roadmap discussion today about
>>> widget catalogs. IMO it clearly highlights (from an OpenSocial perspective
>>> at least) that while external widget catalogs can be supported, the portal
>>> will at least also need to maintain its own registry of widget definitions
>>> (as well as instances thereof: siteId/moduleId). If only in a minimal
>>> fashion to provide maintenance for portal specific data like OAuth consumer
>>> key/secrets and AppData. And probably more.
>>>
>>> And all of this then brings up another question: how to handle 'shared'
>>> data.
>>> Which is yet another roadmap discussion IMO...
>>>
>>> @Jasha: terrific question :)
>>>
>>
>> The issue seemed so trivial "create a admin page for consumer keys and
>> secrets"...
> Nothing really is trivial if you intend to create a platform or engine :)
>
>>
>>
>>>
>>> Ate
>>>
>>>
>>>
>>>
>>>>
>>>>>
>>>>>
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>>> Jasha Joachimsthal
>>>>>>>>>
>>>>>>>>> Europe - Amsterdam - Oosteinde 11, 1017 WT Amsterdam - +31(0)20 522
>>>>>>>>>
>>>>>>>> 4466
>>>>>>>
>>>>>>>> US - Boston - 1 Broadway, Cambridge, MA 02142 - +1 877 414 4776 (toll
>>>>>>>>>
>>>>>>>> free)
>>>>>>>>
>>>>>>>>>
>>>>>>>>> www.onehippo.com
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>
>>>
>>
>
Re: Managing OAuth tokens (RAVE-500)
Posted by Ate Douma <at...@douma.nu>.
On 03/06/2012 08:36 AM, Jasha Joachimsthal wrote:
> On 6 March 2012 04:09, Ate Douma<at...@douma.nu> wrote:
>
>> On 03/05/2012 05:03 PM, Franklin, Matthew B. wrote:
>>
>>> -----Original Message-----
>>>> From: Ate Douma [mailto:ate@douma.nu]
>>>> Sent: Monday, March 05, 2012 10:35 AM
>>>> To: rave-dev@incubator.apache.org
>>>> Subject: Re: Managing OAuth tokens (RAVE-500)
>>>>
>>>> On 03/05/2012 04:00 PM, Franklin, Matthew B. wrote:
>>>>
>>>>> -----Original Message-----
>>>>>> From: Jasha Joachimsthal [mailto:j.joachimsthal@**onehippo.com<j....@onehippo.com>
>>>>>> ]
>>>>>> Sent: Monday, March 05, 2012 9:56 AM
>>>>>> To: rave-dev@incubator.apache.org
>>>>>> Subject: Re: Managing OAuth tokens (RAVE-500)
>>>>>>
>>>>>> On 5 March 2012 15:35, Franklin, Matthew B.<mf...@mitre.org>
>>>>>>
>>>>> wrote:
>>>>
>>>>>
>>>>>> -----Original Message-----
>>>>>>>> From: Jasha Joachimsthal [mailto:j.joachimsthal@**onehippo.com<j....@onehippo.com>
>>>>>>>> ]
>>>>>>>> Sent: Friday, March 02, 2012 12:07 PM
>>>>>>>> To: rave-dev@incubator.apache.org
>>>>>>>> Subject: Managing OAuth tokens (RAVE-500)
>>>>>>>>
>>>>>>>> For (3-legged) OAuth the consumer key and secret need to be stored
>>>>>>>>
>>>>>>> inside
>>>>>>
>>>>>>> the database. At the moment it can only be done by hand, but that
>>>>>>>>
>>>>>>> should
>>>>
>>>>> be
>>>>>>>
>>>>>>>> moved to some admin interface. Our admin interface is a part of the
>>>>>>>>
>>>>>>> portal,
>>>>>>>
>>>>>>>> but the OAuth model, service and repository is a part of
>>>>>>>> Rave-Shindig.
>>>>>>>> If we move o.a.r.gadgets.oauth.model/**repository/service to
>>>>>>>> rave-core
>>>>>>>>
>>>>>>> should
>>>>>>>
>>>>>>>> it remain in its current package?
>>>>>>>>
>>>>>>>
>>>>>>> I think that the consumer key& secret need to be read& writable
>>>>>>> from
>>>>>>> core Rave; but, the majority of the functionality you built for
>>>>>>> managing
>>>>>>> the authorization tokens etc IMHO doesn't belong in Rave. Thoughts?
>>>>>>>
>>>>>>>
>>>>>> The OAuth keys& secrets are not a part of the portal, so they should
>>>>>> be
>>>>>> managed by Rave-Shindig, but we don't have a manage UI for Shindig. We
>>>>>> could create a REST interface to manage the keys& secrets, but only
>>>>>> the
>>>>>> portal knows if someone has the admin privileges to actually manage
>>>>>>
>>>>> them.
>>>>
>>>>>
>>>>> The keys and secret are part of the gadget, which is managed by the
>>>>> portal;
>>>>>
>>>> albeit in a generic way. Could we tie them to the generic Widget object?
>>>>
>>>> Maybe we should consider to at least also support using an external OAuth
>>>> SP?
>>>>
>>>> There are several dedicated security/identity service providers and/or
>>>> engines
>>>> (supporting much more than just OAuth) which could be leveraged in.
>>>>
>>>> While having a default (simple) out-of-the-box implementation by Rave
>>>> makes
>>>> sense, for more enterprise level installments you can expect
>>>> requirements to
>>>> integrate with already existing security providers for this and other
>>>> purpose.
>>>>
>>>> I would think our default/embedded OAuth SP should be 'just' a pluggable
>>>> service, which can and should provide its own admin UI (widget-based or
>>>> otherwise).
>>>>
>>>> It might be useful to support 'revoking' individual OAuth tokens directly
>>>> through some Widget chrome action, but for general keys and secrets
>>>> management I
>>>> think we'll need to provide a separate UI (or delegate to external
>>>> tooling).
>>>>
>>>
>>> I completely agree with your approach when it comes to protecting Rave
>>> resources with OAuth, but in the case of OpenSocial gadget (I don't know
>>> enough about OAuth for other widget types to comment) keys& secrets, they
>>> are provided to the embedded Shindig OAuth SP for any real work. The only
>>> thing we do is implement a storage mechanism. Shindig also only keeps
>>> access tokens for use; but, doesn't manage their revocation or grants.
>>> That is the responsibility of the OAuth service they are accessing.
>>>
>> Right, I was taking about an OAuth authorization provider service with an
>> OAuth consumer (client in OAuth 2).
>> I should have better checked the topic of RAVE-500 which clearly is about
>> OAuth consumer requirements.
>>
>>
>>> Gadget developers typically register the gadget with a service endpoint
>>> to obtain the key/secret pair and need a way to simply store the
>>> information with the gadget such that it is retrievable by Shindig. Often,
>>> these services live outside of the firewall (Google, Twitter, etc) and
>>> really have nothing to do with the enterprise. That doesn't mean that
>>> there couldn't be some external keystore, but its job would be to blindly
>>> store consumer keys& secrets for a target entity, which seems to me to be
>>> of limited value.
>>>
>>>
>>> Given this is the case we are looking to solve at the moment, what
>>> approach would you recommend?
>>>
>>
>> Well, this is quite interesting.
>> I must confess I never actually manually setup/registered an OAuth
>> consumer key/secret myself, but although by the spec this process is
>> undefined, AFAIK typically this is something done based on the concrete
>> consumer/client domain, like if you use Google (see Rave oauth-consumer
>> documentation).
>> It which case it is not the Gadget *developer* but the portal/container
>> *manager* who is responsible for setting up these consumer/client
>> key/secrets...
>>
>> The Gadget URL is required and a key for the Shindig OAuthConsumerStore,
>> but that can be unrelated to and independent of the site/domain where the
>> Gadget is actually rendered.
>> And in the Google case these consumer key/secrets are indeed independent
>> of the actual Gadget used to access the secured resource (just not for
>> Shindig which doesn't know this).
>>
>> From Shindig perspective I agree then the consumer key/secret should be
>> regarded as part of the Gadget *definition* meta-data, but different from
>> user related and even Gadget *instance* (moduleId) related data like the
>> AppDataStore. And this is data which needs to be *seeded* upfront, before
>> first time rendering. These two aspects makes this different and kind of
>> weird from an SPI perspective as Shindig doesn't provide a service to
>> create and store these.
>>
>
>> Oh, and possibly an even further complicating aspect for again the Google
>> case: is the client domain you need to register with Google based on the
>> *portal* domain or the domain hosting the container (Shindig) itself?
>>
>
> Neither. I registered the domain that hosts the gadget definition, but I
> don't know if that is actually correct. It does work though..
Ah, that is interesting.
But also seems weird as the Google documentation for OAuth registration says you
should register your webapp domain. And the domain hosting the gadget definition
really doesn't have to be your own webapp.
However, if this is true (and the Google documentation is wrong?), *then* this
simplifies the discussion quite a lot. And of course this then also needs to
hold true for *all* OAuth Authorization Providers.
Because then this actually might be gadget URL based (not portal and/or instance
based).
>
>
>> I expect and do hope it is the portal domain otherwise you'll could end up
>> with requiring separate consumer key/secrets if you start clustering
>> multiple Shindig container nodes! For now I assume the first...
>>
>> From an administration POV then I think we need to add our own
>> rave-shindig SPI to maintain the OAuthConsumerStoreRepository. And/or start
>> discussing with Shindig team if that should be added to Shindig SPI too.
>>
>> On the other hand, the Shindig SPI is largely lacking in serious
>> administrative features anyway. Consider deleting a previously used gadget
>> definition from the portal. Or even only a Gadget instance
>> (siteId/modulId)? How should we efficiently cleanup the related AppData
>> across every user? The SPI doesn't provide the proper APIs for that either.
>>
>> Anyway, I think an administration UI for this and such services should
>> belong to the portal, especially as they are indeed tied to the Gadget
>> meta-data definition maintained by the portal already (and only).
>>
>
> Is it really a part of the portal? What if I replace Rave-Shindig with an
> externally hosted OpenSocial container? Shouldn't that container contain
> the OAuth keys and secrets? In the end it is Shindig (in our case) that
> handles OAuth, not the portal.
Well, handling OAuth concerns the handshake, not necessarily the ownership or
maintenance of the data. And as I said: Shindig doesn't provide an SPI for
maintenance of this consumer key/secret data, only read access.
Shindig also doesn't 'manage' the widget meta-data but expects that to be
transiently passed in. So it seems to me we can/should tread OAuth consumer
key/secets similar.
>
>
>>
>> I also think this issue is helpful with the roadmap discussion today about
>> widget catalogs. IMO it clearly highlights (from an OpenSocial perspective
>> at least) that while external widget catalogs can be supported, the portal
>> will at least also need to maintain its own registry of widget definitions
>> (as well as instances thereof: siteId/moduleId). If only in a minimal
>> fashion to provide maintenance for portal specific data like OAuth consumer
>> key/secrets and AppData. And probably more.
>>
>> And all of this then brings up another question: how to handle 'shared'
>> data.
>> Which is yet another roadmap discussion IMO...
>>
>> @Jasha: terrific question :)
>>
>
> The issue seemed so trivial "create a admin page for consumer keys and
> secrets"...
Nothing really is trivial if you intend to create a platform or engine :)
>
>
>>
>> Ate
>>
>>
>>
>>
>>>
>>>>
>>>>
>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>
>>>>>>>> Jasha Joachimsthal
>>>>>>>>
>>>>>>>> Europe - Amsterdam - Oosteinde 11, 1017 WT Amsterdam - +31(0)20 522
>>>>>>>>
>>>>>>> 4466
>>>>>>
>>>>>>> US - Boston - 1 Broadway, Cambridge, MA 02142 - +1 877 414 4776 (toll
>>>>>>>>
>>>>>>> free)
>>>>>>>
>>>>>>>>
>>>>>>>> www.onehippo.com
>>>>>>>>
>>>>>>>
>>>>>>>
>>>
>>
>
Re: Managing OAuth tokens (RAVE-500)
Posted by Jasha Joachimsthal <j....@onehippo.com>.
On 6 March 2012 04:09, Ate Douma <at...@douma.nu> wrote:
> On 03/05/2012 05:03 PM, Franklin, Matthew B. wrote:
>
>> -----Original Message-----
>>> From: Ate Douma [mailto:ate@douma.nu]
>>> Sent: Monday, March 05, 2012 10:35 AM
>>> To: rave-dev@incubator.apache.org
>>> Subject: Re: Managing OAuth tokens (RAVE-500)
>>>
>>> On 03/05/2012 04:00 PM, Franklin, Matthew B. wrote:
>>>
>>>> -----Original Message-----
>>>>> From: Jasha Joachimsthal [mailto:j.joachimsthal@**onehippo.com<j....@onehippo.com>
>>>>> ]
>>>>> Sent: Monday, March 05, 2012 9:56 AM
>>>>> To: rave-dev@incubator.apache.org
>>>>> Subject: Re: Managing OAuth tokens (RAVE-500)
>>>>>
>>>>> On 5 March 2012 15:35, Franklin, Matthew B.<mf...@mitre.org>
>>>>>
>>>> wrote:
>>>
>>>>
>>>>> -----Original Message-----
>>>>>>> From: Jasha Joachimsthal [mailto:j.joachimsthal@**onehippo.com<j....@onehippo.com>
>>>>>>> ]
>>>>>>> Sent: Friday, March 02, 2012 12:07 PM
>>>>>>> To: rave-dev@incubator.apache.org
>>>>>>> Subject: Managing OAuth tokens (RAVE-500)
>>>>>>>
>>>>>>> For (3-legged) OAuth the consumer key and secret need to be stored
>>>>>>>
>>>>>> inside
>>>>>
>>>>>> the database. At the moment it can only be done by hand, but that
>>>>>>>
>>>>>> should
>>>
>>>> be
>>>>>>
>>>>>>> moved to some admin interface. Our admin interface is a part of the
>>>>>>>
>>>>>> portal,
>>>>>>
>>>>>>> but the OAuth model, service and repository is a part of
>>>>>>> Rave-Shindig.
>>>>>>> If we move o.a.r.gadgets.oauth.model/**repository/service to
>>>>>>> rave-core
>>>>>>>
>>>>>> should
>>>>>>
>>>>>>> it remain in its current package?
>>>>>>>
>>>>>>
>>>>>> I think that the consumer key& secret need to be read& writable
>>>>>> from
>>>>>> core Rave; but, the majority of the functionality you built for
>>>>>> managing
>>>>>> the authorization tokens etc IMHO doesn't belong in Rave. Thoughts?
>>>>>>
>>>>>>
>>>>> The OAuth keys& secrets are not a part of the portal, so they should
>>>>> be
>>>>> managed by Rave-Shindig, but we don't have a manage UI for Shindig. We
>>>>> could create a REST interface to manage the keys& secrets, but only
>>>>> the
>>>>> portal knows if someone has the admin privileges to actually manage
>>>>>
>>>> them.
>>>
>>>>
>>>> The keys and secret are part of the gadget, which is managed by the
>>>> portal;
>>>>
>>> albeit in a generic way. Could we tie them to the generic Widget object?
>>>
>>> Maybe we should consider to at least also support using an external OAuth
>>> SP?
>>>
>>> There are several dedicated security/identity service providers and/or
>>> engines
>>> (supporting much more than just OAuth) which could be leveraged in.
>>>
>>> While having a default (simple) out-of-the-box implementation by Rave
>>> makes
>>> sense, for more enterprise level installments you can expect
>>> requirements to
>>> integrate with already existing security providers for this and other
>>> purpose.
>>>
>>> I would think our default/embedded OAuth SP should be 'just' a pluggable
>>> service, which can and should provide its own admin UI (widget-based or
>>> otherwise).
>>>
>>> It might be useful to support 'revoking' individual OAuth tokens directly
>>> through some Widget chrome action, but for general keys and secrets
>>> management I
>>> think we'll need to provide a separate UI (or delegate to external
>>> tooling).
>>>
>>
>> I completely agree with your approach when it comes to protecting Rave
>> resources with OAuth, but in the case of OpenSocial gadget (I don't know
>> enough about OAuth for other widget types to comment) keys& secrets, they
>> are provided to the embedded Shindig OAuth SP for any real work. The only
>> thing we do is implement a storage mechanism. Shindig also only keeps
>> access tokens for use; but, doesn't manage their revocation or grants.
>> That is the responsibility of the OAuth service they are accessing.
>>
> Right, I was taking about an OAuth authorization provider service with an
> OAuth consumer (client in OAuth 2).
> I should have better checked the topic of RAVE-500 which clearly is about
> OAuth consumer requirements.
>
>
>> Gadget developers typically register the gadget with a service endpoint
>> to obtain the key/secret pair and need a way to simply store the
>> information with the gadget such that it is retrievable by Shindig. Often,
>> these services live outside of the firewall (Google, Twitter, etc) and
>> really have nothing to do with the enterprise. That doesn't mean that
>> there couldn't be some external keystore, but its job would be to blindly
>> store consumer keys& secrets for a target entity, which seems to me to be
>> of limited value.
>>
>>
>> Given this is the case we are looking to solve at the moment, what
>> approach would you recommend?
>>
>
> Well, this is quite interesting.
> I must confess I never actually manually setup/registered an OAuth
> consumer key/secret myself, but although by the spec this process is
> undefined, AFAIK typically this is something done based on the concrete
> consumer/client domain, like if you use Google (see Rave oauth-consumer
> documentation).
> It which case it is not the Gadget *developer* but the portal/container
> *manager* who is responsible for setting up these consumer/client
> key/secrets...
>
> The Gadget URL is required and a key for the Shindig OAuthConsumerStore,
> but that can be unrelated to and independent of the site/domain where the
> Gadget is actually rendered.
> And in the Google case these consumer key/secrets are indeed independent
> of the actual Gadget used to access the secured resource (just not for
> Shindig which doesn't know this).
>
> From Shindig perspective I agree then the consumer key/secret should be
> regarded as part of the Gadget *definition* meta-data, but different from
> user related and even Gadget *instance* (moduleId) related data like the
> AppDataStore. And this is data which needs to be *seeded* upfront, before
> first time rendering. These two aspects makes this different and kind of
> weird from an SPI perspective as Shindig doesn't provide a service to
> create and store these.
>
> Oh, and possibly an even further complicating aspect for again the Google
> case: is the client domain you need to register with Google based on the
> *portal* domain or the domain hosting the container (Shindig) itself?
>
Neither. I registered the domain that hosts the gadget definition, but I
don't know if that is actually correct. It does work though..
> I expect and do hope it is the portal domain otherwise you'll could end up
> with requiring separate consumer key/secrets if you start clustering
> multiple Shindig container nodes! For now I assume the first...
>
> From an administration POV then I think we need to add our own
> rave-shindig SPI to maintain the OAuthConsumerStoreRepository. And/or start
> discussing with Shindig team if that should be added to Shindig SPI too.
>
> On the other hand, the Shindig SPI is largely lacking in serious
> administrative features anyway. Consider deleting a previously used gadget
> definition from the portal. Or even only a Gadget instance
> (siteId/modulId)? How should we efficiently cleanup the related AppData
> across every user? The SPI doesn't provide the proper APIs for that either.
>
> Anyway, I think an administration UI for this and such services should
> belong to the portal, especially as they are indeed tied to the Gadget
> meta-data definition maintained by the portal already (and only).
>
Is it really a part of the portal? What if I replace Rave-Shindig with an
externally hosted OpenSocial container? Shouldn't that container contain
the OAuth keys and secrets? In the end it is Shindig (in our case) that
handles OAuth, not the portal.
>
> I also think this issue is helpful with the roadmap discussion today about
> widget catalogs. IMO it clearly highlights (from an OpenSocial perspective
> at least) that while external widget catalogs can be supported, the portal
> will at least also need to maintain its own registry of widget definitions
> (as well as instances thereof: siteId/moduleId). If only in a minimal
> fashion to provide maintenance for portal specific data like OAuth consumer
> key/secrets and AppData. And probably more.
>
> And all of this then brings up another question: how to handle 'shared'
> data.
> Which is yet another roadmap discussion IMO...
>
> @Jasha: terrific question :)
>
The issue seemed so trivial "create a admin page for consumer keys and
secrets"...
>
> Ate
>
>
>
>
>>
>>>
>>>
>>>>
>>>>>
>>>>>
>>>>>
>>>>>>
>>>>>>> Jasha Joachimsthal
>>>>>>>
>>>>>>> Europe - Amsterdam - Oosteinde 11, 1017 WT Amsterdam - +31(0)20 522
>>>>>>>
>>>>>> 4466
>>>>>
>>>>>> US - Boston - 1 Broadway, Cambridge, MA 02142 - +1 877 414 4776 (toll
>>>>>>>
>>>>>> free)
>>>>>>
>>>>>>>
>>>>>>> www.onehippo.com
>>>>>>>
>>>>>>
>>>>>>
>>
>
Re: Managing OAuth tokens (RAVE-500)
Posted by Ate Douma <at...@douma.nu>.
On 03/05/2012 05:03 PM, Franklin, Matthew B. wrote:
>> -----Original Message-----
>> From: Ate Douma [mailto:ate@douma.nu]
>> Sent: Monday, March 05, 2012 10:35 AM
>> To: rave-dev@incubator.apache.org
>> Subject: Re: Managing OAuth tokens (RAVE-500)
>>
>> On 03/05/2012 04:00 PM, Franklin, Matthew B. wrote:
>>>> -----Original Message-----
>>>> From: Jasha Joachimsthal [mailto:j.joachimsthal@onehippo.com]
>>>> Sent: Monday, March 05, 2012 9:56 AM
>>>> To: rave-dev@incubator.apache.org
>>>> Subject: Re: Managing OAuth tokens (RAVE-500)
>>>>
>>>> On 5 March 2012 15:35, Franklin, Matthew B.<mf...@mitre.org>
>> wrote:
>>>>
>>>>>> -----Original Message-----
>>>>>> From: Jasha Joachimsthal [mailto:j.joachimsthal@onehippo.com]
>>>>>> Sent: Friday, March 02, 2012 12:07 PM
>>>>>> To: rave-dev@incubator.apache.org
>>>>>> Subject: Managing OAuth tokens (RAVE-500)
>>>>>>
>>>>>> For (3-legged) OAuth the consumer key and secret need to be stored
>>>> inside
>>>>>> the database. At the moment it can only be done by hand, but that
>> should
>>>>> be
>>>>>> moved to some admin interface. Our admin interface is a part of the
>>>>> portal,
>>>>>> but the OAuth model, service and repository is a part of Rave-Shindig.
>>>>>> If we move o.a.r.gadgets.oauth.model/repository/service to rave-core
>>>>> should
>>>>>> it remain in its current package?
>>>>>
>>>>> I think that the consumer key& secret need to be read& writable from
>>>>> core Rave; but, the majority of the functionality you built for managing
>>>>> the authorization tokens etc IMHO doesn't belong in Rave. Thoughts?
>>>>>
>>>>
>>>> The OAuth keys& secrets are not a part of the portal, so they should be
>>>> managed by Rave-Shindig, but we don't have a manage UI for Shindig. We
>>>> could create a REST interface to manage the keys& secrets, but only the
>>>> portal knows if someone has the admin privileges to actually manage
>> them.
>>>
>>> The keys and secret are part of the gadget, which is managed by the portal;
>> albeit in a generic way. Could we tie them to the generic Widget object?
>>
>> Maybe we should consider to at least also support using an external OAuth
>> SP?
>>
>> There are several dedicated security/identity service providers and/or
>> engines
>> (supporting much more than just OAuth) which could be leveraged in.
>>
>> While having a default (simple) out-of-the-box implementation by Rave
>> makes
>> sense, for more enterprise level installments you can expect requirements to
>> integrate with already existing security providers for this and other purpose.
>>
>> I would think our default/embedded OAuth SP should be 'just' a pluggable
>> service, which can and should provide its own admin UI (widget-based or
>> otherwise).
>>
>> It might be useful to support 'revoking' individual OAuth tokens directly
>> through some Widget chrome action, but for general keys and secrets
>> management I
>> think we'll need to provide a separate UI (or delegate to external tooling).
>
> I completely agree with your approach when it comes to protecting Rave resources with OAuth, but in the case of OpenSocial gadget (I don't know enough about OAuth for other widget types to comment) keys& secrets, they are provided to the embedded Shindig OAuth SP for any real work. The only thing we do is implement a storage mechanism. Shindig also only keeps access tokens for use; but, doesn't manage their revocation or grants. That is the responsibility of the OAuth service they are accessing.
Right, I was taking about an OAuth authorization provider service with an OAuth
consumer (client in OAuth 2).
I should have better checked the topic of RAVE-500 which clearly is about OAuth
consumer requirements.
>
> Gadget developers typically register the gadget with a service endpoint to obtain the key/secret pair and need a way to simply store the information with the gadget such that it is retrievable by Shindig. Often, these services live outside of the firewall (Google, Twitter, etc) and really have nothing to do with the enterprise. That doesn't mean that there couldn't be some external keystore, but its job would be to blindly store consumer keys& secrets for a target entity, which seems to me to be of limited value.
>
> Given this is the case we are looking to solve at the moment, what approach would you recommend?
Well, this is quite interesting.
I must confess I never actually manually setup/registered an OAuth consumer
key/secret myself, but although by the spec this process is undefined, AFAIK
typically this is something done based on the concrete consumer/client domain,
like if you use Google (see Rave oauth-consumer documentation).
It which case it is not the Gadget *developer* but the portal/container
*manager* who is responsible for setting up these consumer/client key/secrets...
The Gadget URL is required and a key for the Shindig OAuthConsumerStore, but
that can be unrelated to and independent of the site/domain where the Gadget is
actually rendered.
And in the Google case these consumer key/secrets are indeed independent of the
actual Gadget used to access the secured resource (just not for Shindig which
doesn't know this).
From Shindig perspective I agree then the consumer key/secret should be
regarded as part of the Gadget *definition* meta-data, but different from user
related and even Gadget *instance* (moduleId) related data like the
AppDataStore. And this is data which needs to be *seeded* upfront, before first
time rendering. These two aspects makes this different and kind of weird from an
SPI perspective as Shindig doesn't provide a service to create and store these.
Oh, and possibly an even further complicating aspect for again the Google case:
is the client domain you need to register with Google based on the *portal*
domain or the domain hosting the container (Shindig) itself?
I expect and do hope it is the portal domain otherwise you'll could end up with
requiring separate consumer key/secrets if you start clustering multiple Shindig
container nodes! For now I assume the first...
From an administration POV then I think we need to add our own rave-shindig SPI
to maintain the OAuthConsumerStoreRepository. And/or start discussing with
Shindig team if that should be added to Shindig SPI too.
On the other hand, the Shindig SPI is largely lacking in serious administrative
features anyway. Consider deleting a previously used gadget definition from the
portal. Or even only a Gadget instance (siteId/modulId)? How should we
efficiently cleanup the related AppData across every user? The SPI doesn't
provide the proper APIs for that either.
Anyway, I think an administration UI for this and such services should belong to
the portal, especially as they are indeed tied to the Gadget meta-data
definition maintained by the portal already (and only).
I also think this issue is helpful with the roadmap discussion today about
widget catalogs. IMO it clearly highlights (from an OpenSocial perspective at
least) that while external widget catalogs can be supported, the portal will at
least also need to maintain its own registry of widget definitions (as well as
instances thereof: siteId/moduleId). If only in a minimal fashion to provide
maintenance for portal specific data like OAuth consumer key/secrets and
AppData. And probably more.
And all of this then brings up another question: how to handle 'shared' data.
Which is yet another roadmap discussion IMO...
@Jasha: terrific question :)
Ate
>
>>
>>
>>>
>>>>
>>>>
>>>>
>>>>>
>>>>>>
>>>>>> Jasha Joachimsthal
>>>>>>
>>>>>> Europe - Amsterdam - Oosteinde 11, 1017 WT Amsterdam - +31(0)20 522
>>>> 4466
>>>>>> US - Boston - 1 Broadway, Cambridge, MA 02142 - +1 877 414 4776 (toll
>>>>> free)
>>>>>>
>>>>>> www.onehippo.com
>>>>>
>
RE: Managing OAuth tokens (RAVE-500)
Posted by "Franklin, Matthew B." <mf...@mitre.org>.
>-----Original Message-----
>From: Ate Douma [mailto:ate@douma.nu]
>Sent: Monday, March 05, 2012 10:35 AM
>To: rave-dev@incubator.apache.org
>Subject: Re: Managing OAuth tokens (RAVE-500)
>
>On 03/05/2012 04:00 PM, Franklin, Matthew B. wrote:
>>> -----Original Message-----
>>> From: Jasha Joachimsthal [mailto:j.joachimsthal@onehippo.com]
>>> Sent: Monday, March 05, 2012 9:56 AM
>>> To: rave-dev@incubator.apache.org
>>> Subject: Re: Managing OAuth tokens (RAVE-500)
>>>
>>> On 5 March 2012 15:35, Franklin, Matthew B.<mf...@mitre.org>
>wrote:
>>>
>>>>> -----Original Message-----
>>>>> From: Jasha Joachimsthal [mailto:j.joachimsthal@onehippo.com]
>>>>> Sent: Friday, March 02, 2012 12:07 PM
>>>>> To: rave-dev@incubator.apache.org
>>>>> Subject: Managing OAuth tokens (RAVE-500)
>>>>>
>>>>> For (3-legged) OAuth the consumer key and secret need to be stored
>>> inside
>>>>> the database. At the moment it can only be done by hand, but that
>should
>>>> be
>>>>> moved to some admin interface. Our admin interface is a part of the
>>>> portal,
>>>>> but the OAuth model, service and repository is a part of Rave-Shindig.
>>>>> If we move o.a.r.gadgets.oauth.model/repository/service to rave-core
>>>> should
>>>>> it remain in its current package?
>>>>
>>>> I think that the consumer key& secret need to be read& writable from
>>>> core Rave; but, the majority of the functionality you built for managing
>>>> the authorization tokens etc IMHO doesn't belong in Rave. Thoughts?
>>>>
>>>
>>> The OAuth keys& secrets are not a part of the portal, so they should be
>>> managed by Rave-Shindig, but we don't have a manage UI for Shindig. We
>>> could create a REST interface to manage the keys& secrets, but only the
>>> portal knows if someone has the admin privileges to actually manage
>them.
>>
>> The keys and secret are part of the gadget, which is managed by the portal;
>albeit in a generic way. Could we tie them to the generic Widget object?
>
>Maybe we should consider to at least also support using an external OAuth
>SP?
>
>There are several dedicated security/identity service providers and/or
>engines
>(supporting much more than just OAuth) which could be leveraged in.
>
>While having a default (simple) out-of-the-box implementation by Rave
>makes
>sense, for more enterprise level installments you can expect requirements to
>integrate with already existing security providers for this and other purpose.
>
>I would think our default/embedded OAuth SP should be 'just' a pluggable
>service, which can and should provide its own admin UI (widget-based or
>otherwise).
>
>It might be useful to support 'revoking' individual OAuth tokens directly
>through some Widget chrome action, but for general keys and secrets
>management I
>think we'll need to provide a separate UI (or delegate to external tooling).
I completely agree with your approach when it comes to protecting Rave resources with OAuth, but in the case of OpenSocial gadget (I don't know enough about OAuth for other widget types to comment) keys & secrets, they are provided to the embedded Shindig OAuth SP for any real work. The only thing we do is implement a storage mechanism. Shindig also only keeps access tokens for use; but, doesn't manage their revocation or grants. That is the responsibility of the OAuth service they are accessing.
Gadget developers typically register the gadget with a service endpoint to obtain the key/secret pair and need a way to simply store the information with the gadget such that it is retrievable by Shindig. Often, these services live outside of the firewall (Google, Twitter, etc) and really have nothing to do with the enterprise. That doesn't mean that there couldn't be some external keystore, but its job would be to blindly store consumer keys & secrets for a target entity, which seems to me to be of limited value.
Given this is the case we are looking to solve at the moment, what approach would you recommend?
>
>
>>
>>>
>>>
>>>
>>>>
>>>>>
>>>>> Jasha Joachimsthal
>>>>>
>>>>> Europe - Amsterdam - Oosteinde 11, 1017 WT Amsterdam - +31(0)20 522
>>> 4466
>>>>> US - Boston - 1 Broadway, Cambridge, MA 02142 - +1 877 414 4776 (toll
>>>> free)
>>>>>
>>>>> www.onehippo.com
>>>>
Re: Managing OAuth tokens (RAVE-500)
Posted by Ate Douma <at...@douma.nu>.
On 03/05/2012 04:00 PM, Franklin, Matthew B. wrote:
>> -----Original Message-----
>> From: Jasha Joachimsthal [mailto:j.joachimsthal@onehippo.com]
>> Sent: Monday, March 05, 2012 9:56 AM
>> To: rave-dev@incubator.apache.org
>> Subject: Re: Managing OAuth tokens (RAVE-500)
>>
>> On 5 March 2012 15:35, Franklin, Matthew B.<mf...@mitre.org> wrote:
>>
>>>> -----Original Message-----
>>>> From: Jasha Joachimsthal [mailto:j.joachimsthal@onehippo.com]
>>>> Sent: Friday, March 02, 2012 12:07 PM
>>>> To: rave-dev@incubator.apache.org
>>>> Subject: Managing OAuth tokens (RAVE-500)
>>>>
>>>> For (3-legged) OAuth the consumer key and secret need to be stored
>> inside
>>>> the database. At the moment it can only be done by hand, but that should
>>> be
>>>> moved to some admin interface. Our admin interface is a part of the
>>> portal,
>>>> but the OAuth model, service and repository is a part of Rave-Shindig.
>>>> If we move o.a.r.gadgets.oauth.model/repository/service to rave-core
>>> should
>>>> it remain in its current package?
>>>
>>> I think that the consumer key& secret need to be read& writable from
>>> core Rave; but, the majority of the functionality you built for managing
>>> the authorization tokens etc IMHO doesn't belong in Rave. Thoughts?
>>>
>>
>> The OAuth keys& secrets are not a part of the portal, so they should be
>> managed by Rave-Shindig, but we don't have a manage UI for Shindig. We
>> could create a REST interface to manage the keys& secrets, but only the
>> portal knows if someone has the admin privileges to actually manage them.
>
> The keys and secret are part of the gadget, which is managed by the portal; albeit in a generic way. Could we tie them to the generic Widget object?
Maybe we should consider to at least also support using an external OAuth SP?
There are several dedicated security/identity service providers and/or engines
(supporting much more than just OAuth) which could be leveraged in.
While having a default (simple) out-of-the-box implementation by Rave makes
sense, for more enterprise level installments you can expect requirements to
integrate with already existing security providers for this and other purpose.
I would think our default/embedded OAuth SP should be 'just' a pluggable
service, which can and should provide its own admin UI (widget-based or otherwise).
It might be useful to support 'revoking' individual OAuth tokens directly
through some Widget chrome action, but for general keys and secrets management I
think we'll need to provide a separate UI (or delegate to external tooling).
>
>>
>>
>>
>>>
>>>>
>>>> Jasha Joachimsthal
>>>>
>>>> Europe - Amsterdam - Oosteinde 11, 1017 WT Amsterdam - +31(0)20 522
>> 4466
>>>> US - Boston - 1 Broadway, Cambridge, MA 02142 - +1 877 414 4776 (toll
>>> free)
>>>>
>>>> www.onehippo.com
>>>
RE: Managing OAuth tokens (RAVE-500)
Posted by "Franklin, Matthew B." <mf...@mitre.org>.
>-----Original Message-----
>From: Jasha Joachimsthal [mailto:j.joachimsthal@onehippo.com]
>Sent: Monday, March 05, 2012 9:56 AM
>To: rave-dev@incubator.apache.org
>Subject: Re: Managing OAuth tokens (RAVE-500)
>
>On 5 March 2012 15:35, Franklin, Matthew B. <mf...@mitre.org> wrote:
>
>> >-----Original Message-----
>> >From: Jasha Joachimsthal [mailto:j.joachimsthal@onehippo.com]
>> >Sent: Friday, March 02, 2012 12:07 PM
>> >To: rave-dev@incubator.apache.org
>> >Subject: Managing OAuth tokens (RAVE-500)
>> >
>> >For (3-legged) OAuth the consumer key and secret need to be stored
>inside
>> >the database. At the moment it can only be done by hand, but that should
>> be
>> >moved to some admin interface. Our admin interface is a part of the
>> portal,
>> >but the OAuth model, service and repository is a part of Rave-Shindig.
>> >If we move o.a.r.gadgets.oauth.model/repository/service to rave-core
>> should
>> >it remain in its current package?
>>
>> I think that the consumer key & secret need to be read & writable from
>> core Rave; but, the majority of the functionality you built for managing
>> the authorization tokens etc IMHO doesn't belong in Rave. Thoughts?
>>
>
>The OAuth keys & secrets are not a part of the portal, so they should be
>managed by Rave-Shindig, but we don't have a manage UI for Shindig. We
>could create a REST interface to manage the keys & secrets, but only the
>portal knows if someone has the admin privileges to actually manage them.
The keys and secret are part of the gadget, which is managed by the portal; albeit in a generic way. Could we tie them to the generic Widget object?
>
>
>
>>
>> >
>> >Jasha Joachimsthal
>> >
>> >Europe - Amsterdam - Oosteinde 11, 1017 WT Amsterdam - +31(0)20 522
>4466
>> >US - Boston - 1 Broadway, Cambridge, MA 02142 - +1 877 414 4776 (toll
>> free)
>> >
>> >www.onehippo.com
>>
Re: Managing OAuth tokens (RAVE-500)
Posted by Jasha Joachimsthal <j....@onehippo.com>.
On 5 March 2012 15:35, Franklin, Matthew B. <mf...@mitre.org> wrote:
> >-----Original Message-----
> >From: Jasha Joachimsthal [mailto:j.joachimsthal@onehippo.com]
> >Sent: Friday, March 02, 2012 12:07 PM
> >To: rave-dev@incubator.apache.org
> >Subject: Managing OAuth tokens (RAVE-500)
> >
> >For (3-legged) OAuth the consumer key and secret need to be stored inside
> >the database. At the moment it can only be done by hand, but that should
> be
> >moved to some admin interface. Our admin interface is a part of the
> portal,
> >but the OAuth model, service and repository is a part of Rave-Shindig.
> >If we move o.a.r.gadgets.oauth.model/repository/service to rave-core
> should
> >it remain in its current package?
>
> I think that the consumer key & secret need to be read & writable from
> core Rave; but, the majority of the functionality you built for managing
> the authorization tokens etc IMHO doesn't belong in Rave. Thoughts?
>
The OAuth keys & secrets are not a part of the portal, so they should be
managed by Rave-Shindig, but we don't have a manage UI for Shindig. We
could create a REST interface to manage the keys & secrets, but only the
portal knows if someone has the admin privileges to actually manage them.
>
> >
> >Jasha Joachimsthal
> >
> >Europe - Amsterdam - Oosteinde 11, 1017 WT Amsterdam - +31(0)20 522 4466
> >US - Boston - 1 Broadway, Cambridge, MA 02142 - +1 877 414 4776 (toll
> free)
> >
> >www.onehippo.com
>
RE: Managing OAuth tokens (RAVE-500)
Posted by "Franklin, Matthew B." <mf...@mitre.org>.
>-----Original Message-----
>From: Jasha Joachimsthal [mailto:j.joachimsthal@onehippo.com]
>Sent: Friday, March 02, 2012 12:07 PM
>To: rave-dev@incubator.apache.org
>Subject: Managing OAuth tokens (RAVE-500)
>
>For (3-legged) OAuth the consumer key and secret need to be stored inside
>the database. At the moment it can only be done by hand, but that should be
>moved to some admin interface. Our admin interface is a part of the portal,
>but the OAuth model, service and repository is a part of Rave-Shindig.
>If we move o.a.r.gadgets.oauth.model/repository/service to rave-core should
>it remain in its current package?
I think that the consumer key & secret need to be read & writable from core Rave; but, the majority of the functionality you built for managing the authorization tokens etc IMHO doesn't belong in Rave. Thoughts?
>
>Jasha Joachimsthal
>
>Europe - Amsterdam - Oosteinde 11, 1017 WT Amsterdam - +31(0)20 522 4466
>US - Boston - 1 Broadway, Cambridge, MA 02142 - +1 877 414 4776 (toll free)
>
>www.onehippo.com