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