On 6 March 2012 04:09, Ate Douma <[email protected]> wrote: > On 03/05/2012 05:03 PM, Franklin, Matthew B. wrote: > >> -----Original Message----- >>> From: Ate Douma [mailto:[email protected]] >>> Sent: Monday, March 05, 2012 10:35 AM >>> To: [email protected] >>> 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<[email protected]> >>>>> ] >>>>> Sent: Monday, March 05, 2012 9:56 AM >>>>> To: [email protected] >>>>> Subject: Re: Managing OAuth tokens (RAVE-500) >>>>> >>>>> On 5 March 2012 15:35, Franklin, Matthew B.<[email protected]> >>>>> >>>> wrote: >>> >>>> >>>>> -----Original Message----- >>>>>>> From: Jasha Joachimsthal >>>>>>> [mailto:j.joachimsthal@**onehippo.com<[email protected]> >>>>>>> ] >>>>>>> Sent: Friday, March 02, 2012 12:07 PM >>>>>>> To: [email protected] >>>>>>> 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 >>>>>>> >>>>>> >>>>>> >> >
