Cross-container data and multi-signing - Proposal for 2.0

[goosemanjack]

In the interest of scope creep, we have a new proposal for supporting
data tag requests across different containers. This feature also
facilitates safely embedding and using multiple credential sets -
OAuth and otherwise - within a gadget.

http://docs.opensocial.org/display/OSD/Cross+Container+Data+Requests

(from doc)

This proposal seeks to define a mechanism for gadgets running in one
container to invoke data endpoints existing in another container. It
also allows for defining multiple signing mechanisms for cases where a
gadget may have to talk to APIs secured with different OAuth keys.

...

Example cross-container request:

<Module>
<ModulePrefs>
<Require feature="dataProviders" />
</ModulePrefs>
<Data>
<os:apiProvider key="fooNetwork"
authz="oauth2"
encrypt="oauth_secret"
encrypt_method="AES">
<uriBasePath>http://fooNet.com/apis/v2/</uriBasePath>
<oauth_key>XXXXX</oauth_key>
<oauth_secret>YYYYYY</oauth_secret>
</os:apiProvider>


<os:PeopleRequest key="fooPeople" provider="fooNetwork" />
<os:HttpRequest key="arbitraryFoo" provider="fooNetwork"
href="http://fooNet.com/exampleElse/proprietaryStuff" />
</Data>
<Content>
I got a proprietary answer of ${arbitraryFoo.SpecialValue} from that
endpoint.
</Content>
</Module>

...

Before anyone freaks out, I'd like to start the discussion in the 2.0
time frame, but my feelings won't be hurt is this slips to 2.1.

[rbaxter85]

Goosemanjack, can this be used to request data from secure endpoints
that are not part of the OpenSocial spec?

[goosemanjack]

Yes. As a start we'd want to insure support for major APIs used on
the web. Examples would be Twitter, Facebook graph API et al, Google
maps, etc. This should support both oauth (1.0a and 2.0) and other
commonly found security schemes, like app ID, etc.

[rbaxter85]

Ah yes...i see that in the spec sorry for the dumb question.

I am still trying to wrap my hear around this and the benefits of
using this approach of makeRequest. Is it because it allows you to
define the oAuth provider in the gadget itself and not have to
register it with the container as you do today? On that note, isn't
it a security risk to define the oAuth key and secret in the gadget
XML? If you define it in the XML than anyone can see it and hence use
it.

[Bastian Hofmann]

Som things I don't understand yet about this proposal:

- How would you ensure that a shared secret is not compromised? it seems to be very public for me, if you are putting it into the gadget xml.

- How is this different from the current oauth authorization type?

- You are talking about OAuth2 and other authorization mechanisms. Wouldn't it make more sense to just add these authorization types to makeRequest or osapi:http, methods that gadget developers already use and know, instead of defining new tags and methods?

-- Bastian

2011/2/19 rbaxter85 <rbax...@gmail.com>

--
You received this message because you are subscribed to the Google Groups "OpenSocial and Gadgets Specification Discussion" group.
To post to this group, send email to opensocial-an...@googlegroups.com.
To unsubscribe from this group, send email to opensocial-and-gadg...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/opensocial-and-gadgets-spec?hl=en.

[goosemanjack]

I agree that it's less than ideal to embed a secret in the gadget XML
file. That's why the proposal includes a mechanism for encrypting the
secret key. Currently each app is assigned a single set of OAuth
credentials out of band from the gadget XML upload. This works fine
when the gadget is only communicating with the container-provided APIs
or custom APIs under the control of the gadget developer such that
they can specify OAuth credentials expected by the endpoint.

What is missing is a mechanism to define multiple OAuth (or other)
credentials. For instance, a mashup app wants to execute on Myspace
and talk to the social APIs, but also check in to Foursquare.
Foursquare uses OAuth, but has supplied different credentials from
those assigned to the gadget. Right now the only way to do this would
be for the app to have a private API that wraps the target Foursquare
API and makes the call using the correct credentials. This proposal
would allow the gadget to make the call to the target API on
Foursquare directly without the need to bounce it off a different API
to translate the OAuth credentials. I see a need to define a little
more how the client gadgets.io.makeRequest could also use the
credentials.

This would also seek to provide a mechanism to safely embed other
styles of API security credentials in the gadget XML so that a wider
variety of APIs can be called.



On Feb 20, 11:07 pm, Bastian Hofmann <bashofm...@googlemail.com>
wrote:

> Som things I don't understand yet about this proposal:
>
> - How would you ensure that a shared secret is not compromised? it seems to
> be very public for me, if you are putting it into the gadget xml.
> - How is this different from the current oauth authorization type?
> - You are talking about OAuth2 and other authorization mechanisms. Wouldn't
> it make more sense to just add these authorization types to makeRequest or
> osapi:http, methods that gadget developers already use and know, instead of
> defining new tags and methods?
>
> -- Bastian
>

> 2011/2/19 rbaxter85 <rbaxte...@gmail.com>

[Bastian Hofmann]

Depending on the container implementation it is already possible to define multiple oauth credentials for different services in one gadget, see http://code.google.com/intl/de-DE/apis/gadgets/docs/oauth.html. At VZnet we are allowing gadget developers to add their custom credentials in our sandbox (see http://developer.studivz.net/wiki/index.php/Lesson_23:_Connecting_to_an_external_API_with_OAuth_authorization) at iGoogle you have to mail the credentials somewhere as far as I know. Since many containers are already supporting this we should build up on this, if we want to add new features, instead of creating something totally new, in my opinion.

I'm not sure yet if I like the idea of providing even a crypted secret in the gadget XML. While it unifies the way to provide the secrets across containers, I see the following problems:

- For security reasons crypting the secrets with a secret from the gadget should be a MUST, but not every container are assigning a secret to their gadgets

- Developers will get this wrong and just provide an uncrypted secret in their gadget xml, while this won't work, they are compromising their secret this way

- Containers could possibly implement this wrong and allow uncrypted secrets

- If a gadget secret gets disclosed somehow, all service's secrets are compromised as well

-- Bastian

2011/2/22 goosemanjack <cc...@myspace.com>

[rbaxter85]

I would have to agree with Bastian on this.

The way iGoogle requires you to register your oAuth key and secret
with them by sending an email, is not very user friendly. I like how
VZnet allows you to do it by letting the developer register that
information themselves. Its more flexible in that if anything changes
it's easy for the developer to change it and not have to wait for the
admins of the container to process their request. Maybe this should
be something we standardize in the container or maybe this is just
implementation details....I'm not really sure.

On Feb 22, 4:00 am, Bastian Hofmann <bashofm...@googlemail.com> wrote:
> Depending on the container implementation it is already possible to define

> multiple oauth credentials for different services in one gadget, seehttp://code.google.com/intl/de-DE/apis/gadgets/docs/oauth.html. At VZnet we

> are allowing gadget developers to add their custom credentials in our

> sandbox (seehttp://developer.studivz.net/wiki/index.php/Lesson_23:_Connecting_to_...)

[Mark W.]

I agree with both Ryan and Bastian.

However, there is some good stuff on the proposal. For example, the idea being able to define a "uriBasePath" to the osapi calls makes a lot of sense. This would be a container configuration, similar to how you name your oauth configurations.  This makes it much easier to move things between environments, e.g. dev, test, qa, production. Assuming the relative URL is the same, the base path will be set by the container.

If a container chooses to expose registration of this somehow, then that's fine too.

[goosemanjack]

So if I can summarize the feedback so far, the main concern is
specifying OAuth credentials within the gadget file - encrypted or
not. If we change this proposal so that credentials are loaded out of
band in some unspecified manner, does that make the proposal workable
for everyone?

It seems containers are already implementing proprietary mechanisms,
so it would be good to unify the approach. If the credentials are
defined out of gadget file, but still referenced via a @provider key,
then we can get the benefits of the proposal and a standardized
skeleton of how to handle this across containers. This should also be
extensible to client-side gadgets.io.makeRequest calls by adding the
@provider value to the options object passed to the proxy.

Does that make sense to everyone?
--
clc

[rbaxter85]

+1

[Bastian Hofmann]

The currently used mechanisms used by containers are not proprietary, but specified in part here:

http://opensocial-resources.googlecode.com/svn/spec/1.1/Core-Gadget.xml#OAuthElement

Only the means of providing the OAuth credentials are different in every container.

So in my opinion we should either try to build up on this existing mechanism if possible instead of creating something new, or deprecate it completely.

2011/2/25 rbaxter85 <rbax...@gmail.com>

+1

[goosemanjack]

That looks like a good place to extend for the OAuth 2.0 work. As I
read that currently, it appears to provide nodes for contacting a
three-legged OAuth (1.0a) provider to get the request token. There is
a lot of overlap with the proposal, but it's not 1:1. For instance,
the ModulePrefs/OAuth/Service (with the addition of a REST API root
URL) looks to be exactly what this proposal is trying to cover for
cross-container calls. Unfortunately, this mechanism is restricted to
OAuth.

This proposal tries to cover defining security credentials and REST
API providers in a more general sense. There are numerous APIs
available that have proprietary security mechanisms, or mechanisms
that predate oauth. For instance, the Google map web services have
what appears to be a pre-oauth mechanism for signing requests

http://code.google.com/apis/maps/documentation/webservices/index.html#URLSigning

I would also assume that OAuth 2.0 won't be the final security
mechanism we ever see for securing endpoints. For that reason, my
vote is to deprecate the ModulePrefs/OAuth section of the spec you
referenced and replace it with a more generic version to specify API
security.

http://opensocial-resources.googlecode.com/svn/spec/1.1/Core-Gadget.xml#OAuthElement

If everyone thinks defining an API provider and security credentials
is something more suited to being within ModulePrefs than embedded in
a data block, we can make that change to the proposal. If we do that,
I would change the proposal to drop this as an add-on feature and push
it to a core element of ModulePrefs.
--
clc

On Feb 25, 1:46 am, Bastian Hofmann <bashofm...@googlemail.com> wrote:
> The currently used mechanisms used by containers are not proprietary, but
> specified in part here:
>

> http://opensocial-resources.googlecode.com/svn/spec/1.1/Core-Gadget.x...

> Only the means of providing the OAuth credentials are different in every
> container.
>
> So in my opinion we should either try to build up on this existing mechanism
> if possible instead of creating something new, or deprecate it completely.
>

> 2011/2/25 rbaxter85 <rbaxte...@gmail.com>

[Mark W.]

+1

[Mark W.]

Chris,

I agree with putting the security credentials into the module prefs and making a feature.

[rbaxter85]

I don't think moving the element containing the security credentials
makes it any more secure. Maybe I am just not understanding what your
changing, but it sounds like your just moving things from the data
section to the module prefs section.

[Andy Smith]

It sounds like the new approach would be to define a general configuration in the module prefs to allow for developers to support multiple types of security endpoints.   I believe the term credentials references the particular service provider endpoint configuration, not consumerKey or secrets.  
--
Thank you,

Andy

[Mark W.]

Andy's correct. I agree with you, Ryan, that storing the credentials in the gadget def is not what we want to do. I think we are walking down the path of two things:

The first is a way to specify a "security configuration", much like we do with OAuth.

The second is an "alias" that will provide a base url.

Both of these are configured in the container, out of band to the gadget definition. We should consider adding the security configuration to section 7 on the discovery document. This would allow you can ask the container for it's security configurations. We might want to do this for alias as well. We could probably agree on these for common things also (but this should be a separate appendix to the spec so that it can evolve independently).

Then, we'd modify the http request parameters to have an "alias" parameter. If it's present, the href is treated as a relative URL to what's in the alias.

[rbaxter85]

Got it. I thought the word "credentials" meant literally the users
security credentials. I am all for making an abstract security
section though.

[goosemanjack]

It feels like we're coming to an consensus on this one. I'll update
the proposal later this week to reflect the discussion. I'm also most
of the way into getting a public Negroni site (.Net OpenSocial
container) so we can put up live prototypes and play around with
things. Expect that announced in the next couple weeks.
--
clc

[goosemanjack]

Updated the proposal to specify security keys out of band from gadget
file. Also showed usage with gadgets.io.makeRequest and identified
deprecated spec sections. I'll work up a spec patch next.

http://docs.opensocial.org/display/OSD/Cross+Container+Data+Requests
--
clc

[goosemanjack]

Patch applied and ready for voting:

(vote)
http://code.google.com/p/opensocial-resources/source/detail?r=1418

(issue)
http://code.google.com/p/opensocial-resources/issues/detail?id=1181