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