You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@shindig.apache.org by Mike Pawlowski <mp...@ca.ibm.com> on 2013/11/05 18:15:07 UTC
Is it possible for Shindig to render gadgets whose content is a protected
/ secured resource?
Hi
------------------------
Problem
------------------------
If the gadget content referenced by the gadget metadata is a protected /
secured resource (i.e. requires the user to authenticate / authorize access
to the resource), Shindig cannot render the gadget.
Note: The gadget metadata itself is not a secured / protected resource
The following error is shown in the gadget content area in place of the
expected gadget contents.
Unable to reach remote host. HTTP status 401
The following error appears in the Shindig server log:
[INFO ] The gadget at
http://localhost:9081/examples/gadgets/make-request-metadata did not
render. The following error occurred: Unable to reach remote host. HTTP
status 401.
e.g. Unprotected gadget metadata resource:
<Module specificationVersion="2.0">
<ModulePrefs title="My Gadget"
...
</ModulePrefs>
<OAuth2>
<Service name="jazz"></Service>
</OAuth2>
<!-- Protected Resource -->
<Content type="html" href="$
{baseURL}/gadgets/protected-gadget-content.html" view="home, profile,
canvas" />
</Module>
In this circumstance, Shindig doesn't invoke the configured OAuth 2.0 auth
flow as expected for accessing the content (the gadget rendering request
just fails outright).
------------------------
Assumptions
------------------------
(a) The gadget metadata resource must be unsecured / unprotected in order
for Shindig to render a gadget
------------------------
Questions
------------------------
(1) Like assumption (a), is it a Shindig / OpenSocial gadget specification
requirement that the gadget content be an unprotected / unsecured resource?
(2) Is it possible for Shindig to render gadgets whose content is a
protected / secured resource?
e.g. Configuration option to turn on the OAuth 2.0 auth flow for protected
content?
e.g. Inject a Guice module that will handle the OAuth 2.0 auth flow for
protected content?
(3) Does Shindig only support the OAuth 2.0 auth flow for gadget
makeRequest operations?
(4) Is the solution outlined below, viable? Are there any alternative ways
to invoke the OAuth 2.0 auth flow?
(5) Are there any built-in Shindig security features / mechanisms that we
could utilize or leverage to handle our use case?
------------------------
Our Solution
------------------------
* Gadget metadata is an unprotected resource
* Make the gadget content an unprotected resource
* Gadget content is just a stub that does a gadget makeRequest on gadget
load to GET the actual protected gadget content (HTML)
* The makeRequest operation invokes the OAuth 2.0 auth flow for the user if
required
* After authorization / authentication, the protected gadget content is
re-fetched and the response is simply inlined into the content area
Thanks,
Mike
Re: Is it possible for Shindig to render gadgets whose content is a
protected / secured resource?
Posted by Ryan Baxter <rb...@gmail.com>.
On Wed, Nov 6, 2013 at 1:04 PM, Mike Pawlowski <mp...@ca.ibm.com> wrote:
> Thanks for the response, Ryan.
>
> RE: Question (2)
>
> While trying to learn more about Shindig's content proxy that you
> mentioned, I noticed that there appears
> to be a provision for Shindig to render protected gadget content in the
> OpenSocial Core Gadget Specification 2.5.0:
>
> See:
> http://opensocial-resources.googlecode.com/svn/spec/2.5/Core-Gadget.xml#ContentElement
>
> @href
> "If @type is "html", the Container MUST proxy (Section 6) the current
> content section. Discussion [Issue-1173]"
>
> See:
> http://opensocial-resources.googlecode.com/svn/spec/2.5/Core-Gadget.xml#ProxiedContent
>
> "the container MUST issue an HTTP request to the URI specified by the href
> attribute following the rules defined in gadgets.io.makeRequest (Section
> 13.2.1.3)."
>
> Unless I'm reading the spec incorrectly - which is entirely possible - I
> should be able to specify additional Content element attributes that map to
> auth related makeRequest parameters
>
> e.g.
>
>
> <Module specificationVersion="2.0">
> <ModulePrefs title="My Gadget"
> ...
> </ModulePrefs>
>
> <OAuth2>
> <Service name="jazz"></Service>
> </OAuth2>
>
> <!-- Protected Resource -->
> <Content type="html"
> href="${baseURL}/gadgets/protected-gadget-content.html" view="home,
> profile, canvas" authz="OAUTH2" oauth_service_name="jazz"
> refresh_interval="0" />
> </Module>
>
> I tried this and of course this didn't work for me on the first try : )
> (I need to debug the underlying Shindig source to figure out what is going
> wrong)
>
> Using the above gadget metadata, I'm getting a 403 instead of a 401
> response code instead:
> The gadget at http://localhost:9081/examples/gadgets/make-request-metadatadid not render. The following error occurred: Unable to reach remote host.
> HTTP status 403.
>
> Is my spec interpretation correct?
>
Yup your interpretation is correct.
>
>
> Is the above alternate solution viable?
> e.g. Should Shindig support the OAuth2 auth flow for rendering gadget
> content?
>
It should support it, but it was never implemented. There are other
scenarios like this where the spec says you can use OAuth to make requests
for things but in reality Shindig only supports OAuth for
gadgets.io.makeRequest.
>
> e.g. Is there something wrong with the Content element mark-up I specified
> in the above sample gadget metadata?
>
It looks right to me.
>
>
>
> Mike
>
>
>
>
> [image: Inactive hide details for Ryan Baxter ---2013-11-06 10:39:37
> AM---On Tue, Nov 5, 2013 at 12:15 PM, Mike Pawlowski <mpawlow@ca.i]Ryan
> Baxter ---2013-11-06 10:39:37 AM---On Tue, Nov 5, 2013 at 12:15 PM, Mike
> Pawlowski <mp...@ca.ibm.com> wrote: >
>
> From: Ryan Baxter <rb...@gmail.com>
> To: "dev@shindig.apache.org" <de...@shindig.apache.org>,
> Date: 2013-11-06 10:39 AM
> Subject: Re: Is it possible for Shindig to render gadgets whose content
> is a protected / secured resource?
> ------------------------------
>
>
>
> On Tue, Nov 5, 2013 at 12:15 PM, Mike Pawlowski <mp...@ca.ibm.com>
> wrote:
> >
> >
> > Hi
> >
> > ------------------------
> > Problem
> > ------------------------
> >
> > If the gadget content referenced by the gadget metadata is a protected /
> > secured resource (i.e. requires the user to authenticate / authorize
> access
> > to the resource), Shindig cannot render the gadget.
> > Note: The gadget metadata itself is not a secured / protected resource
> >
> > The following error is shown in the gadget content area in place of the
> > expected gadget contents.
> > Unable to reach remote host. HTTP status 401
> >
> > The following error appears in the Shindig server log:
> > [INFO ] The gadget at
> > http://localhost:9081/examples/gadgets/make-request-metadata did not
> > render. The following error occurred: Unable to reach remote host. HTTP
> > status 401.
> >
> > e.g. Unprotected gadget metadata resource:
> >
> > <Module specificationVersion="2.0">
> > <ModulePrefs title="My Gadget"
> > ...
> > </ModulePrefs>
> >
> > <OAuth2>
> > <Service name="jazz"></Service>
> > </OAuth2>
> >
> > <!-- Protected Resource -->
> > <Content type="html" href="$
> > {baseURL}/gadgets/protected-gadget-content.html" view="home, profile,
> > canvas" />
> > </Module>
> >
> > In this circumstance, Shindig doesn't invoke the configured OAuth 2.0
> auth
> > flow as expected for accessing the content (the gadget rendering request
> > just fails outright).
> >
> > ------------------------
> > Assumptions
> > ------------------------
> >
> > (a) The gadget metadata resource must be unsecured / unprotected in order
> > for Shindig to render a gadget
> >
> > ------------------------
> > Questions
> > ------------------------
> >
> > (1) Like assumption (a), is it a Shindig / OpenSocial gadget
> specification
> > requirement that the gadget content be an unprotected / unsecured
> resource?
> Yes I believe so.
> >
> > (2) Is it possible for Shindig to render gadgets whose content is a
> > protected / secured resource?
> Not that I know of. The main problem with fetching protected content
> via OAuth 2.0 from the server is the OAuth dance. However there are
> probably creative solutions for dealing with this if Shindig does not
> currently have a token to use.
> >
> > e.g. Configuration option to turn on the OAuth 2.0 auth flow for
> protected
> > content?
> > e.g. Inject a Guice module that will handle the OAuth 2.0 auth flow for
> > protected content?
> >
> > (3) Does Shindig only support the OAuth 2.0 auth flow for gadget
> > makeRequest operations?
> The gadget proxy (used for makeRequest) and the content proxy (used
> for gadget resources) both support OAuth 2.0.
> >
> > (4) Is the solution outlined below, viable? Are there any alternative
> ways
> > to invoke the OAuth 2.0 auth flow?
> It seems viable however it is not the most efficient solution. I
> guess at this point it is your only option, without making changes to
> Shindig. I would at least try it and then revisit if making changes
> to Shindig would be necessary.
> >
> > (5) Are there any built-in Shindig security features / mechanisms that we
> > could utilize or leverage to handle our use case?
> I don't believe so.
> >
> >
> > ------------------------
> > Our Solution
> > ------------------------
> >
> > * Gadget metadata is an unprotected resource
> > * Make the gadget content an unprotected resource
> > * Gadget content is just a stub that does a gadget makeRequest on gadget
> > load to GET the actual protected gadget content (HTML)
> > * The makeRequest operation invokes the OAuth 2.0 auth flow for the user
> if
> > required
> > * After authorization / authentication, the protected gadget content is
> > re-fetched and the response is simply inlined into the content area
> >
> >
> >
> > Thanks,
> >
> > Mike
>
>
>
Re: Is it possible for Shindig to render gadgets whose content is a
protected / secured resource?
Posted by Mike Pawlowski <mp...@ca.ibm.com>.
Thanks for the response, Ryan.
RE: Question (2)
While trying to learn more about Shindig's content proxy that you
mentioned, I noticed that there appears
to be a provision for Shindig to render protected gadget content in the
OpenSocial Core Gadget Specification 2.5.0:
See:
http://opensocial-resources.googlecode.com/svn/spec/2.5/Core-Gadget.xml#ContentElement
@href
"If @type is "html", the Container MUST proxy (Section 6) the current
content section. Discussion [Issue-1173]"
See:
http://opensocial-resources.googlecode.com/svn/spec/2.5/Core-Gadget.xml#ProxiedContent
"the container MUST issue an HTTP request to the URI specified by the href
attribute following the rules defined in gadgets.io.makeRequest (Section
13.2.1.3)."
Unless I'm reading the spec incorrectly - which is entirely possible - I
should be able to specify additional Content element attributes that map to
auth related makeRequest parameters
e.g.
<Module specificationVersion="2.0">
<ModulePrefs title="My Gadget"
...
</ModulePrefs>
<OAuth2>
<Service name="jazz"></Service>
</OAuth2>
<!-- Protected Resource -->
<Content type="html" href="$
{baseURL}/gadgets/protected-gadget-content.html" view="home, profile,
canvas" authz="OAUTH2" oauth_service_name="jazz" refresh_interval="0" />
</Module>
I tried this and of course this didn't work for me on the first try : )
(I need to debug the underlying Shindig source to figure out what is going
wrong)
Using the above gadget metadata, I'm getting a 403 instead of a 401
response code instead:
The gadget at http://localhost:9081/examples/gadgets/make-request-metadata
did not render. The following error occurred: Unable to reach remote host.
HTTP status 403.
Is my spec interpretation correct?
Is the above alternate solution viable?
e.g. Should Shindig support the OAuth2 auth flow for rendering gadget
content?
e.g. Is there something wrong with the Content element mark-up I specified
in the above sample gadget metadata?
Mike
From: Ryan Baxter <rb...@gmail.com>
To: "dev@shindig.apache.org" <de...@shindig.apache.org>,
Date: 2013-11-06 10:39 AM
Subject: Re: Is it possible for Shindig to render gadgets whose content
is a protected / secured resource?
On Tue, Nov 5, 2013 at 12:15 PM, Mike Pawlowski <mp...@ca.ibm.com> wrote:
>
>
> Hi
>
> ------------------------
> Problem
> ------------------------
>
> If the gadget content referenced by the gadget metadata is a protected /
> secured resource (i.e. requires the user to authenticate / authorize
access
> to the resource), Shindig cannot render the gadget.
> Note: The gadget metadata itself is not a secured / protected resource
>
> The following error is shown in the gadget content area in place of the
> expected gadget contents.
> Unable to reach remote host. HTTP status 401
>
> The following error appears in the Shindig server log:
> [INFO ] The gadget at
> http://localhost:9081/examples/gadgets/make-request-metadata did not
> render. The following error occurred: Unable to reach remote host. HTTP
> status 401.
>
> e.g. Unprotected gadget metadata resource:
>
> <Module specificationVersion="2.0">
> <ModulePrefs title="My Gadget"
> ...
> </ModulePrefs>
>
> <OAuth2>
> <Service name="jazz"></Service>
> </OAuth2>
>
> <!-- Protected Resource -->
> <Content type="html" href="$
> {baseURL}/gadgets/protected-gadget-content.html" view="home, profile,
> canvas" />
> </Module>
>
> In this circumstance, Shindig doesn't invoke the configured OAuth 2.0
auth
> flow as expected for accessing the content (the gadget rendering request
> just fails outright).
>
> ------------------------
> Assumptions
> ------------------------
>
> (a) The gadget metadata resource must be unsecured / unprotected in order
> for Shindig to render a gadget
>
> ------------------------
> Questions
> ------------------------
>
> (1) Like assumption (a), is it a Shindig / OpenSocial gadget
specification
> requirement that the gadget content be an unprotected / unsecured
resource?
Yes I believe so.
>
> (2) Is it possible for Shindig to render gadgets whose content is a
> protected / secured resource?
Not that I know of. The main problem with fetching protected content
via OAuth 2.0 from the server is the OAuth dance. However there are
probably creative solutions for dealing with this if Shindig does not
currently have a token to use.
>
> e.g. Configuration option to turn on the OAuth 2.0 auth flow for
protected
> content?
> e.g. Inject a Guice module that will handle the OAuth 2.0 auth flow for
> protected content?
>
> (3) Does Shindig only support the OAuth 2.0 auth flow for gadget
> makeRequest operations?
The gadget proxy (used for makeRequest) and the content proxy (used
for gadget resources) both support OAuth 2.0.
>
> (4) Is the solution outlined below, viable? Are there any alternative
ways
> to invoke the OAuth 2.0 auth flow?
It seems viable however it is not the most efficient solution. I
guess at this point it is your only option, without making changes to
Shindig. I would at least try it and then revisit if making changes
to Shindig would be necessary.
>
> (5) Are there any built-in Shindig security features / mechanisms that we
> could utilize or leverage to handle our use case?
I don't believe so.
>
>
> ------------------------
> Our Solution
> ------------------------
>
> * Gadget metadata is an unprotected resource
> * Make the gadget content an unprotected resource
> * Gadget content is just a stub that does a gadget makeRequest on gadget
> load to GET the actual protected gadget content (HTML)
> * The makeRequest operation invokes the OAuth 2.0 auth flow for the user
if
> required
> * After authorization / authentication, the protected gadget content is
> re-fetched and the response is simply inlined into the content area
>
>
>
> Thanks,
>
> Mike
Re: Is it possible for Shindig to render gadgets whose content is a
protected / secured resource?
Posted by Ryan Baxter <rb...@gmail.com>.
On Tue, Nov 5, 2013 at 12:15 PM, Mike Pawlowski <mp...@ca.ibm.com> wrote:
>
>
> Hi
>
> ------------------------
> Problem
> ------------------------
>
> If the gadget content referenced by the gadget metadata is a protected /
> secured resource (i.e. requires the user to authenticate / authorize access
> to the resource), Shindig cannot render the gadget.
> Note: The gadget metadata itself is not a secured / protected resource
>
> The following error is shown in the gadget content area in place of the
> expected gadget contents.
> Unable to reach remote host. HTTP status 401
>
> The following error appears in the Shindig server log:
> [INFO ] The gadget at
> http://localhost:9081/examples/gadgets/make-request-metadata did not
> render. The following error occurred: Unable to reach remote host. HTTP
> status 401.
>
> e.g. Unprotected gadget metadata resource:
>
> <Module specificationVersion="2.0">
> <ModulePrefs title="My Gadget"
> ...
> </ModulePrefs>
>
> <OAuth2>
> <Service name="jazz"></Service>
> </OAuth2>
>
> <!-- Protected Resource -->
> <Content type="html" href="$
> {baseURL}/gadgets/protected-gadget-content.html" view="home, profile,
> canvas" />
> </Module>
>
> In this circumstance, Shindig doesn't invoke the configured OAuth 2.0 auth
> flow as expected for accessing the content (the gadget rendering request
> just fails outright).
>
> ------------------------
> Assumptions
> ------------------------
>
> (a) The gadget metadata resource must be unsecured / unprotected in order
> for Shindig to render a gadget
>
> ------------------------
> Questions
> ------------------------
>
> (1) Like assumption (a), is it a Shindig / OpenSocial gadget specification
> requirement that the gadget content be an unprotected / unsecured resource?
Yes I believe so.
>
> (2) Is it possible for Shindig to render gadgets whose content is a
> protected / secured resource?
Not that I know of. The main problem with fetching protected content
via OAuth 2.0 from the server is the OAuth dance. However there are
probably creative solutions for dealing with this if Shindig does not
currently have a token to use.
>
> e.g. Configuration option to turn on the OAuth 2.0 auth flow for protected
> content?
> e.g. Inject a Guice module that will handle the OAuth 2.0 auth flow for
> protected content?
>
> (3) Does Shindig only support the OAuth 2.0 auth flow for gadget
> makeRequest operations?
The gadget proxy (used for makeRequest) and the content proxy (used
for gadget resources) both support OAuth 2.0.
>
> (4) Is the solution outlined below, viable? Are there any alternative ways
> to invoke the OAuth 2.0 auth flow?
It seems viable however it is not the most efficient solution. I
guess at this point it is your only option, without making changes to
Shindig. I would at least try it and then revisit if making changes
to Shindig would be necessary.
>
> (5) Are there any built-in Shindig security features / mechanisms that we
> could utilize or leverage to handle our use case?
I don't believe so.
>
>
> ------------------------
> Our Solution
> ------------------------
>
> * Gadget metadata is an unprotected resource
> * Make the gadget content an unprotected resource
> * Gadget content is just a stub that does a gadget makeRequest on gadget
> load to GET the actual protected gadget content (HTML)
> * The makeRequest operation invokes the OAuth 2.0 auth flow for the user if
> required
> * After authorization / authentication, the protected gadget content is
> re-fetched and the response is simply inlined into the content area
>
>
>
> Thanks,
>
> Mike