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