>-----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:[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:[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. 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 >>>>
