You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@shindig.apache.org by Ryan J Baxter <rj...@us.ibm.com> on 2011/08/11 00:02:44 UTC
Securing RPC
John and Paul,
In May, when Andrew and I were out at Google, we talked to you guys at a
high level about how to secure features and the RPC functionality in
Shindig. Andrew and I are at the point where we would like to tackle
this and would like to keep you guys in the loop with the implementation
so we can come up with a solid implementation. Based on our conversation
in May, here is what I have for high level changes that would need to be
made.
-Add a "feature security service" which will interface with some data
store describing what features are allowed for a given container.
-Possibly add a new gadget renderer or modify the existing gadget render
code to not return feature code if the feature has not been enabled in a
given container.
-Add a new element/parameter to the feature XML to allow feature
developers to specify the RPC endpoints they use in their feature code.
-Add an "RPC arbitrator" that uses the information from feature security
service in combination with the RPC endpoints specified in the feature XML
to either allow or disallow RPC requests made by gadgets.
Please let me know if you have any other thoughts on this topic.
-Ryan
Email: rjbaxter@us.ibm.com
Phone: 978-899-3041
developerWorks Profile
Re: Securing RPC
Posted by Dan Dumont <dd...@us.ibm.com>.
>I was thinking that the JS would just not be loaded in the iFrame for the
>gadget. But now that I am thinking about this that may not be so good
>since it will probably result in errors in the gadget. Returning empty
>implementations of the functions is probably a little better, but may
>still result in JS errors in the gadget.
I would think that gadgets that *require* features that have missing code
would have issues no matter what you do.
Otherwise, gadgets that *optional* features *should* gate the code that
uses those features with checks to see if they actually exist.
From: Ryan J Baxter/Westford/IBM@Lotus
To: dev@shindig.apache.org,
Cc: "Andrew E Davis" <An...@notesdev.ibm.com>, John
Hjelmstad <jo...@gmail.com>, Paul Lindner <li...@inuus.com>
Date: 08/10/2011 08:18 PM
Subject: Re: Securing RPC
Responses inline.
-Ryan
Email: rjbaxter@us.ibm.com
Phone: 978-899-3041
developerWorks Profile
From: John Hjelmstad <fa...@google.com>
To: dev@shindig.apache.org,
Cc: John Hjelmstad <jo...@gmail.com>, Paul Lindner
<li...@inuus.com>, Andrew E Davis/Westford/IBM@IBMUS
Date: 08/10/2011 06:10 PM
Subject: Re: Securing RPC
>Hey Ryan,
>
>A few comments inline.
>
>On Wed, Aug 10, 2011 at 3:02 PM, Ryan J Baxter <rj...@us.ibm.com>
wrote:
>
>> John and Paul,
>>
>> In May, when Andrew and I were out at Google, we talked to you guys at
a
>> high level about how to secure features and the RPC functionality in
>> Shindig. Andrew and I are at the point where we would like to tackle
>> this and would like to keep you guys in the loop with the
implementation
>> so we can come up with a solid implementation. Based on our
conversation
>> in May, here is what I have for high level changes that would need to
be
>> made.
>>
>> -Add a "feature security service" which will interface with some data
>> store describing what features are allowed for a given container.
>>
>
>Sounds good to me.
>
>
>>
>> -Possibly add a new gadget renderer or modify the existing gadget
render
>> code to not return feature code if the feature has not been enabled in
a
>> given container.
>>
>
>By "not return feature code" do you mean "return empty code" -- or is it
an
>implicit requirement that symbol names be exported but with empty
>implementations?
>
I was thinking that the JS would just not be loaded in the iFrame for the
gadget. But now that I am thinking about this that may not be so good
since it will probably result in errors in the gadget. Returning empty
implementations of the functions is probably a little better, but may
still result in JS errors in the gadget.
>
>>
>> -Add a new element/parameter to the feature XML to allow feature
>> developers to specify the RPC endpoints they use in their feature code.
>>
>
>You should be able to use:
><api>
> <exports type="rpc">rpc_symbol_name</exports>
></api>
>
>...for this purpose. I'm excited to see that be put to use.
Great I will take a look at that!
>
>
>>
>> -Add an "RPC arbitrator" that uses the information from feature
security
>> service in combination with the RPC endpoints specified in the feature
XML
>> to either allow or disallow RPC requests made by gadgets.
>>
>
>I assume this piece will be in the container/provider-side JS, true? You
>might be able to auto-generate stubs for this from the JS server itself,
>without a whole lot of code.
>
Yeah this will be in the container. We were thinking the RPC code will
have a setArbitrator function which can be used to set the arbitrator to
use. We were also thinking of pulling down the list of allowed RPC
endpoints when the container makes the metadata request for the gadget.
Could you elaborate more on what you were thinking with the JS server?
>Cheers,
>John
>
>
>>
>> Please let me know if you have any other thoughts on this topic.
>>
>>
>> -Ryan
>>
>> Email: rjbaxter@us.ibm.com
>> Phone: 978-899-3041
>> developerWorks Profile
>>
>>
Re: Securing RPC
Posted by John Hjelmstad <fa...@google.com>.
Hey Ryan,
Sorry for the late response; I've been on vacation.
I just responded to your CL, but long story short it sounds like <uses> is
the syntax you want for RPCs that the feature calls.
<uses type="rpc>foo</uses> = gadgets.rpc.call("foo", ...);
<exports type="rpc">bar</exports> = gadgets.rpc.register("bar", ...);
--j
On Wed, Aug 24, 2011 at 6:37 AM, Ryan J Baxter <rj...@us.ibm.com> wrote:
> I mean in the feature.xml
>
> .....
> <api>
> <export type="rpc">rpc_service_id</export>
> <api>
> ....
>
> I am wondering whether the above export is used to export the service id
> when a feature calls g.rpc.register('rpc_service_id') or when a feature
> calls g.rpc.call('rpc_service_id')? It sounds like it used when a feature
> registers a service id.
>
> What I am trying to do is get a list of all the rpc services that a gadget
> could possibly call. This will be the list of allowed rpc services a
> gadget is allowed to call inside a container. If a gadget tries to call a
> service not in this list than the call will be "blocked". I was going to
> use exports with the type="rpc" to export any rpc services CALLED from
> within a feature's JS and then get all the exports with type="rpc" for
> each feature a gadget requires in order to generate that list, but that
> doesn't seem like that is the intent of exports with the type="rpc".
> Sounds like we may need another export type to export the rpc services a
> feature calls, would you agree?
>
> -Ryan
>
> Email: rjbaxter@us.ibm.com
> Phone: 978-899-3041
> developerWorks Profile
>
>
>
> From: John Hjelmstad <jo...@gmail.com>
> To: Ryan J Baxter/Westford/IBM@Lotus,
> Cc: Andrew E Davis <An...@notesdev.ibm.com>, Paul
> Lindner <li...@inuus.com>, dev@shindig.apache.org
> Date: 08/23/2011 09:36 PM
> Subject: Re: Securing RPC
>
>
>
> When you say export, do you mean the JS symbol name or the service ID
> registered by g.rpc.register(...)?
>
> I'm assuming the latter based on context... the implemented strategy is to
> export when the feature registers it. Am I understanding that your ask is
> to
> register lazily, only upon the first call? If so, you should be able to
> achieve this through use of the default handler, registerDefault(...) no?
>
> -j
>
> On Tue, Aug 23, 2011 at 6:32 PM, Ryan J Baxter <rj...@us.ibm.com>
> wrote:
>
> > John, quick question for you on using exports with type="rpc"....was the
> > intent to export the rpc name when the feature registers it or when a
> > feature calls it? I want to use it for when a feature calls it, I just
> want
> > to make sure that was the intent.
> >
> >
> > -Ryan
> >
> > Email: rjbaxter@us.ibm.com
> > Phone: 978-899-3041
> > developerWorks Profile<
>
> http://www.ibm.com/developerworks/mydeveloperworks/profiles/user/RyanJBaxter
> >
> >
> >
> >
> > From: John Hjelmstad <jo...@gmail.com>
> > To: Ryan J Baxter/Westford/IBM@Lotus,
> > Cc: dev@shindig.apache.org, Andrew E Davis <
> > Andrew_E_Davis%IBMUS@notesdev.ibm.com>, Paul Lindner <li...@inuus.com>
> > Date: 08/11/2011 08:19 PM
> > Subject: Re: Securing RPC
> > ------------------------------
> >
> >
> >
> > On Wed, Aug 10, 2011 at 5:16 PM, Ryan J Baxter <rj...@us.ibm.com>
> > wrote:
> >
> > > Responses inline.
> > >
> > >
> > > -Ryan
> > >
> > > Email: rjbaxter@us.ibm.com
> > > Phone: 978-899-3041
> > > developerWorks Profile<
> >
>
> http://www.ibm.com/developerworks/mydeveloperworks/profiles/user/RyanJBaxter
>
> > >
> >
> > >
> > >
> > >
> > > From: John Hjelmstad <fa...@google.com>
> > > To: dev@shindig.apache.org,
> > > Cc: John Hjelmstad <jo...@gmail.com>, Paul Lindner <
> > > lindner@inuus.com>, Andrew E Davis/Westford/IBM@IBMUS
> > > Date: 08/10/2011 06:10 PM
> > > Subject: Re: Securing RPC
> > > ------------------------------
> > >
> > >
> > >
> > > >Hey Ryan,
> > > >
> > > >A few comments inline.
> > > >
> > > >On Wed, Aug 10, 2011 at 3:02 PM, Ryan J Baxter <rj...@us.ibm.com>
> > > wrote:
> > > >
> > > >> John and Paul,
> > > >>
> > > >> In May, when Andrew and I were out at Google, we talked to you guys
> at
> > a
> > > >> high level about how to secure features and the RPC functionality
> in
> > > >> Shindig. Andrew and I are at the point where we would like to
> tackle
> > > >> this and would like to keep you guys in the loop with the
> > implementation
> > > >> so we can come up with a solid implementation. Based on our
> > > conversation
> > > >> in May, here is what I have for high level changes that would need
> to
> > be
> > > >> made.
> > > >>
> > > >> -Add a "feature security service" which will interface with some
> data
> > > >> store describing what features are allowed for a given container.
> > > >>
> > > >
> > > >Sounds good to me.
> > > >
> > > >
> > > >>
> > > >> -Possibly add a new gadget renderer or modify the existing gadget
> > render
> > > >> code to not return feature code if the feature has not been enabled
> in
> > a
> > > >> given container.
> > > >>
> > > >
> > > >By "not return feature code" do you mean "return empty code" -- or is
> it
> > > an
> > > >implicit requirement that symbol names be exported but with empty
> > > >implementations?
> > > >
> > >
> > > I was thinking that the JS would just not be loaded in the iFrame for
> the
> > > gadget. But now that I am thinking about this that may not be so good
> > since
> > > it will probably result in errors in the gadget. Returning empty
> > > implementations of the functions is probably a little better, but may
> > still
> > > result in JS errors in the gadget.
> >
> >
> > That was my concern as well, though Dan's point about a gadget that
> > <Requires> a feature that is denied is a good one. The regular
> recommended
> > approach in this case is to just issue an error in the container,
> > indicating
> > that the gadget cannot be rendered in the first place.
> >
> > Under that assertion, the problem space is reduced to essentially
> nothing.
> > If any rpc is denied that is provided by a <Requires>'d feature, the
> gadget
> > fails. If the feature is <Optional>, the gadget should behave
> appropriately
> > anyway.
> >
> >
> > >
> > >
> > > >
> > > >>
> > > >> -Add a new element/parameter to the feature XML to allow feature
> > > >> developers to specify the RPC endpoints they use in their feature
> > code.
> > > >>
> > > >
> > > >You should be able to use:
> > > ><api>
> > > > <exports type="rpc">rpc_symbol_name</exports>
> > > ></api>
> > > >
> > > >...for this purpose. I'm excited to see that be put to use.
> > >
> > > Great I will take a look at that!
> > >
> > >
> > > >
> > > >
> > > >>
> > > >> -Add an "RPC arbitrator" that uses the information from feature
> > security
> > > >> service in combination with the RPC endpoints specified in the
> feature
> > > XML
> > > >> to either allow or disallow RPC requests made by gadgets.
> > > >>
> > > >
> > > >I assume this piece will be in the container/provider-side JS, true?
> You
> > > >might be able to auto-generate stubs for this from the JS server
> itself,
> > > >without a whole lot of code.
> > > >
> > >
> > > Yeah this will be in the container. We were thinking the RPC code
> will
> > > have a setArbitrator function which can be used to set the arbitrator
> to
> > > use. We were also thinking of pulling down the list of allowed RPC
> > > endpoints when the container makes the metadata request for the
> gadget.
> > > Could you elaborate more on what you were thinking with the JS
> server?
> > >
> > >
> > > >Cheers,
> > > >John
> > > >
> > > >
> > > >>
> > > >> Please let me know if you have any other thoughts on this topic.
> > > >>
> > > >>
> > > >> -Ryan
> > > >>
> > > >> Email: rjbaxter@us.ibm.com
> > > >> Phone: 978-899-3041
> > > >> developerWorks Profile
> > > >>
> > > >>
> > >
> > >
> > >
> >
> >
> >
>
>
>
>
Re: Securing RPC
Posted by Ryan J Baxter <rj...@us.ibm.com>.
I mean in the feature.xml
.....
<api>
<export type="rpc">rpc_service_id</export>
<api>
....
I am wondering whether the above export is used to export the service id
when a feature calls g.rpc.register('rpc_service_id') or when a feature
calls g.rpc.call('rpc_service_id')? It sounds like it used when a feature
registers a service id.
What I am trying to do is get a list of all the rpc services that a gadget
could possibly call. This will be the list of allowed rpc services a
gadget is allowed to call inside a container. If a gadget tries to call a
service not in this list than the call will be "blocked". I was going to
use exports with the type="rpc" to export any rpc services CALLED from
within a feature's JS and then get all the exports with type="rpc" for
each feature a gadget requires in order to generate that list, but that
doesn't seem like that is the intent of exports with the type="rpc".
Sounds like we may need another export type to export the rpc services a
feature calls, would you agree?
-Ryan
Email: rjbaxter@us.ibm.com
Phone: 978-899-3041
developerWorks Profile
From: John Hjelmstad <jo...@gmail.com>
To: Ryan J Baxter/Westford/IBM@Lotus,
Cc: Andrew E Davis <An...@notesdev.ibm.com>, Paul
Lindner <li...@inuus.com>, dev@shindig.apache.org
Date: 08/23/2011 09:36 PM
Subject: Re: Securing RPC
When you say export, do you mean the JS symbol name or the service ID
registered by g.rpc.register(...)?
I'm assuming the latter based on context... the implemented strategy is to
export when the feature registers it. Am I understanding that your ask is
to
register lazily, only upon the first call? If so, you should be able to
achieve this through use of the default handler, registerDefault(...) no?
-j
On Tue, Aug 23, 2011 at 6:32 PM, Ryan J Baxter <rj...@us.ibm.com>
wrote:
> John, quick question for you on using exports with type="rpc"....was the
> intent to export the rpc name when the feature registers it or when a
> feature calls it? I want to use it for when a feature calls it, I just
want
> to make sure that was the intent.
>
>
> -Ryan
>
> Email: rjbaxter@us.ibm.com
> Phone: 978-899-3041
> developerWorks Profile<
http://www.ibm.com/developerworks/mydeveloperworks/profiles/user/RyanJBaxter
>
>
>
>
> From: John Hjelmstad <jo...@gmail.com>
> To: Ryan J Baxter/Westford/IBM@Lotus,
> Cc: dev@shindig.apache.org, Andrew E Davis <
> Andrew_E_Davis%IBMUS@notesdev.ibm.com>, Paul Lindner <li...@inuus.com>
> Date: 08/11/2011 08:19 PM
> Subject: Re: Securing RPC
> ------------------------------
>
>
>
> On Wed, Aug 10, 2011 at 5:16 PM, Ryan J Baxter <rj...@us.ibm.com>
> wrote:
>
> > Responses inline.
> >
> >
> > -Ryan
> >
> > Email: rjbaxter@us.ibm.com
> > Phone: 978-899-3041
> > developerWorks Profile<
>
http://www.ibm.com/developerworks/mydeveloperworks/profiles/user/RyanJBaxter
> >
>
> >
> >
> >
> > From: John Hjelmstad <fa...@google.com>
> > To: dev@shindig.apache.org,
> > Cc: John Hjelmstad <jo...@gmail.com>, Paul Lindner <
> > lindner@inuus.com>, Andrew E Davis/Westford/IBM@IBMUS
> > Date: 08/10/2011 06:10 PM
> > Subject: Re: Securing RPC
> > ------------------------------
> >
> >
> >
> > >Hey Ryan,
> > >
> > >A few comments inline.
> > >
> > >On Wed, Aug 10, 2011 at 3:02 PM, Ryan J Baxter <rj...@us.ibm.com>
> > wrote:
> > >
> > >> John and Paul,
> > >>
> > >> In May, when Andrew and I were out at Google, we talked to you guys
at
> a
> > >> high level about how to secure features and the RPC functionality
in
> > >> Shindig. Andrew and I are at the point where we would like to
tackle
> > >> this and would like to keep you guys in the loop with the
> implementation
> > >> so we can come up with a solid implementation. Based on our
> > conversation
> > >> in May, here is what I have for high level changes that would need
to
> be
> > >> made.
> > >>
> > >> -Add a "feature security service" which will interface with some
data
> > >> store describing what features are allowed for a given container.
> > >>
> > >
> > >Sounds good to me.
> > >
> > >
> > >>
> > >> -Possibly add a new gadget renderer or modify the existing gadget
> render
> > >> code to not return feature code if the feature has not been enabled
in
> a
> > >> given container.
> > >>
> > >
> > >By "not return feature code" do you mean "return empty code" -- or is
it
> > an
> > >implicit requirement that symbol names be exported but with empty
> > >implementations?
> > >
> >
> > I was thinking that the JS would just not be loaded in the iFrame for
the
> > gadget. But now that I am thinking about this that may not be so good
> since
> > it will probably result in errors in the gadget. Returning empty
> > implementations of the functions is probably a little better, but may
> still
> > result in JS errors in the gadget.
>
>
> That was my concern as well, though Dan's point about a gadget that
> <Requires> a feature that is denied is a good one. The regular
recommended
> approach in this case is to just issue an error in the container,
> indicating
> that the gadget cannot be rendered in the first place.
>
> Under that assertion, the problem space is reduced to essentially
nothing.
> If any rpc is denied that is provided by a <Requires>'d feature, the
gadget
> fails. If the feature is <Optional>, the gadget should behave
appropriately
> anyway.
>
>
> >
> >
> > >
> > >>
> > >> -Add a new element/parameter to the feature XML to allow feature
> > >> developers to specify the RPC endpoints they use in their feature
> code.
> > >>
> > >
> > >You should be able to use:
> > ><api>
> > > <exports type="rpc">rpc_symbol_name</exports>
> > ></api>
> > >
> > >...for this purpose. I'm excited to see that be put to use.
> >
> > Great I will take a look at that!
> >
> >
> > >
> > >
> > >>
> > >> -Add an "RPC arbitrator" that uses the information from feature
> security
> > >> service in combination with the RPC endpoints specified in the
feature
> > XML
> > >> to either allow or disallow RPC requests made by gadgets.
> > >>
> > >
> > >I assume this piece will be in the container/provider-side JS, true?
You
> > >might be able to auto-generate stubs for this from the JS server
itself,
> > >without a whole lot of code.
> > >
> >
> > Yeah this will be in the container. We were thinking the RPC code
will
> > have a setArbitrator function which can be used to set the arbitrator
to
> > use. We were also thinking of pulling down the list of allowed RPC
> > endpoints when the container makes the metadata request for the
gadget.
> > Could you elaborate more on what you were thinking with the JS
server?
> >
> >
> > >Cheers,
> > >John
> > >
> > >
> > >>
> > >> Please let me know if you have any other thoughts on this topic.
> > >>
> > >>
> > >> -Ryan
> > >>
> > >> Email: rjbaxter@us.ibm.com
> > >> Phone: 978-899-3041
> > >> developerWorks Profile
> > >>
> > >>
> >
> >
> >
>
>
>
Re: Securing RPC
Posted by John Hjelmstad <jo...@gmail.com>.
When you say export, do you mean the JS symbol name or the service ID
registered by g.rpc.register(...)?
I'm assuming the latter based on context... the implemented strategy is to
export when the feature registers it. Am I understanding that your ask is to
register lazily, only upon the first call? If so, you should be able to
achieve this through use of the default handler, registerDefault(...) no?
-j
On Tue, Aug 23, 2011 at 6:32 PM, Ryan J Baxter <rj...@us.ibm.com> wrote:
> John, quick question for you on using exports with type="rpc"....was the
> intent to export the rpc name when the feature registers it or when a
> feature calls it? I want to use it for when a feature calls it, I just want
> to make sure that was the intent.
>
>
> -Ryan
>
> Email: rjbaxter@us.ibm.com
> Phone: 978-899-3041
> developerWorks Profile<http://www.ibm.com/developerworks/mydeveloperworks/profiles/user/RyanJBaxter>
>
>
>
> From: John Hjelmstad <jo...@gmail.com>
> To: Ryan J Baxter/Westford/IBM@Lotus,
> Cc: dev@shindig.apache.org, Andrew E Davis <
> Andrew_E_Davis%IBMUS@notesdev.ibm.com>, Paul Lindner <li...@inuus.com>
> Date: 08/11/2011 08:19 PM
> Subject: Re: Securing RPC
> ------------------------------
>
>
>
> On Wed, Aug 10, 2011 at 5:16 PM, Ryan J Baxter <rj...@us.ibm.com>
> wrote:
>
> > Responses inline.
> >
> >
> > -Ryan
> >
> > Email: rjbaxter@us.ibm.com
> > Phone: 978-899-3041
> > developerWorks Profile<
> http://www.ibm.com/developerworks/mydeveloperworks/profiles/user/RyanJBaxter
> >
>
> >
> >
> >
> > From: John Hjelmstad <fa...@google.com>
> > To: dev@shindig.apache.org,
> > Cc: John Hjelmstad <jo...@gmail.com>, Paul Lindner <
> > lindner@inuus.com>, Andrew E Davis/Westford/IBM@IBMUS
> > Date: 08/10/2011 06:10 PM
> > Subject: Re: Securing RPC
> > ------------------------------
> >
> >
> >
> > >Hey Ryan,
> > >
> > >A few comments inline.
> > >
> > >On Wed, Aug 10, 2011 at 3:02 PM, Ryan J Baxter <rj...@us.ibm.com>
> > wrote:
> > >
> > >> John and Paul,
> > >>
> > >> In May, when Andrew and I were out at Google, we talked to you guys at
> a
> > >> high level about how to secure features and the RPC functionality in
> > >> Shindig. Andrew and I are at the point where we would like to tackle
> > >> this and would like to keep you guys in the loop with the
> implementation
> > >> so we can come up with a solid implementation. Based on our
> > conversation
> > >> in May, here is what I have for high level changes that would need to
> be
> > >> made.
> > >>
> > >> -Add a "feature security service" which will interface with some data
> > >> store describing what features are allowed for a given container.
> > >>
> > >
> > >Sounds good to me.
> > >
> > >
> > >>
> > >> -Possibly add a new gadget renderer or modify the existing gadget
> render
> > >> code to not return feature code if the feature has not been enabled in
> a
> > >> given container.
> > >>
> > >
> > >By "not return feature code" do you mean "return empty code" -- or is it
> > an
> > >implicit requirement that symbol names be exported but with empty
> > >implementations?
> > >
> >
> > I was thinking that the JS would just not be loaded in the iFrame for the
> > gadget. But now that I am thinking about this that may not be so good
> since
> > it will probably result in errors in the gadget. Returning empty
> > implementations of the functions is probably a little better, but may
> still
> > result in JS errors in the gadget.
>
>
> That was my concern as well, though Dan's point about a gadget that
> <Requires> a feature that is denied is a good one. The regular recommended
> approach in this case is to just issue an error in the container,
> indicating
> that the gadget cannot be rendered in the first place.
>
> Under that assertion, the problem space is reduced to essentially nothing.
> If any rpc is denied that is provided by a <Requires>'d feature, the gadget
> fails. If the feature is <Optional>, the gadget should behave appropriately
> anyway.
>
>
> >
> >
> > >
> > >>
> > >> -Add a new element/parameter to the feature XML to allow feature
> > >> developers to specify the RPC endpoints they use in their feature
> code.
> > >>
> > >
> > >You should be able to use:
> > ><api>
> > > <exports type="rpc">rpc_symbol_name</exports>
> > ></api>
> > >
> > >...for this purpose. I'm excited to see that be put to use.
> >
> > Great I will take a look at that!
> >
> >
> > >
> > >
> > >>
> > >> -Add an "RPC arbitrator" that uses the information from feature
> security
> > >> service in combination with the RPC endpoints specified in the feature
> > XML
> > >> to either allow or disallow RPC requests made by gadgets.
> > >>
> > >
> > >I assume this piece will be in the container/provider-side JS, true? You
> > >might be able to auto-generate stubs for this from the JS server itself,
> > >without a whole lot of code.
> > >
> >
> > Yeah this will be in the container. We were thinking the RPC code will
> > have a setArbitrator function which can be used to set the arbitrator to
> > use. We were also thinking of pulling down the list of allowed RPC
> > endpoints when the container makes the metadata request for the gadget.
> > Could you elaborate more on what you were thinking with the JS server?
> >
> >
> > >Cheers,
> > >John
> > >
> > >
> > >>
> > >> Please let me know if you have any other thoughts on this topic.
> > >>
> > >>
> > >> -Ryan
> > >>
> > >> Email: rjbaxter@us.ibm.com
> > >> Phone: 978-899-3041
> > >> developerWorks Profile
> > >>
> > >>
> >
> >
> >
>
>
>
Re: Securing RPC
Posted by Ryan J Baxter <rj...@us.ibm.com>.
John, quick question for you on using exports with type="rpc"....was the
intent to export the rpc name when the feature registers it or when a
feature calls it? I want to use it for when a feature calls it, I just
want to make sure that was the intent.
-Ryan
Email: rjbaxter@us.ibm.com
Phone: 978-899-3041
developerWorks Profile
From: John Hjelmstad <jo...@gmail.com>
To: Ryan J Baxter/Westford/IBM@Lotus,
Cc: dev@shindig.apache.org, Andrew E Davis
<An...@notesdev.ibm.com>, Paul Lindner <li...@inuus.com>
Date: 08/11/2011 08:19 PM
Subject: Re: Securing RPC
On Wed, Aug 10, 2011 at 5:16 PM, Ryan J Baxter <rj...@us.ibm.com>
wrote:
> Responses inline.
>
>
> -Ryan
>
> Email: rjbaxter@us.ibm.com
> Phone: 978-899-3041
> developerWorks Profile<
http://www.ibm.com/developerworks/mydeveloperworks/profiles/user/RyanJBaxter
>
>
>
>
> From: John Hjelmstad <fa...@google.com>
> To: dev@shindig.apache.org,
> Cc: John Hjelmstad <jo...@gmail.com>, Paul Lindner <
> lindner@inuus.com>, Andrew E Davis/Westford/IBM@IBMUS
> Date: 08/10/2011 06:10 PM
> Subject: Re: Securing RPC
> ------------------------------
>
>
>
> >Hey Ryan,
> >
> >A few comments inline.
> >
> >On Wed, Aug 10, 2011 at 3:02 PM, Ryan J Baxter <rj...@us.ibm.com>
> wrote:
> >
> >> John and Paul,
> >>
> >> In May, when Andrew and I were out at Google, we talked to you guys
at a
> >> high level about how to secure features and the RPC functionality in
> >> Shindig. Andrew and I are at the point where we would like to
tackle
> >> this and would like to keep you guys in the loop with the
implementation
> >> so we can come up with a solid implementation. Based on our
> conversation
> >> in May, here is what I have for high level changes that would need to
be
> >> made.
> >>
> >> -Add a "feature security service" which will interface with some data
> >> store describing what features are allowed for a given container.
> >>
> >
> >Sounds good to me.
> >
> >
> >>
> >> -Possibly add a new gadget renderer or modify the existing gadget
render
> >> code to not return feature code if the feature has not been enabled
in a
> >> given container.
> >>
> >
> >By "not return feature code" do you mean "return empty code" -- or is
it
> an
> >implicit requirement that symbol names be exported but with empty
> >implementations?
> >
>
> I was thinking that the JS would just not be loaded in the iFrame for
the
> gadget. But now that I am thinking about this that may not be so good
since
> it will probably result in errors in the gadget. Returning empty
> implementations of the functions is probably a little better, but may
still
> result in JS errors in the gadget.
That was my concern as well, though Dan's point about a gadget that
<Requires> a feature that is denied is a good one. The regular recommended
approach in this case is to just issue an error in the container,
indicating
that the gadget cannot be rendered in the first place.
Under that assertion, the problem space is reduced to essentially nothing.
If any rpc is denied that is provided by a <Requires>'d feature, the
gadget
fails. If the feature is <Optional>, the gadget should behave
appropriately
anyway.
>
>
> >
> >>
> >> -Add a new element/parameter to the feature XML to allow feature
> >> developers to specify the RPC endpoints they use in their feature
code.
> >>
> >
> >You should be able to use:
> ><api>
> > <exports type="rpc">rpc_symbol_name</exports>
> ></api>
> >
> >...for this purpose. I'm excited to see that be put to use.
>
> Great I will take a look at that!
>
>
> >
> >
> >>
> >> -Add an "RPC arbitrator" that uses the information from feature
security
> >> service in combination with the RPC endpoints specified in the
feature
> XML
> >> to either allow or disallow RPC requests made by gadgets.
> >>
> >
> >I assume this piece will be in the container/provider-side JS, true?
You
> >might be able to auto-generate stubs for this from the JS server
itself,
> >without a whole lot of code.
> >
>
> Yeah this will be in the container. We were thinking the RPC code will
> have a setArbitrator function which can be used to set the arbitrator to
> use. We were also thinking of pulling down the list of allowed RPC
> endpoints when the container makes the metadata request for the gadget.
> Could you elaborate more on what you were thinking with the JS server?
>
>
> >Cheers,
> >John
> >
> >
> >>
> >> Please let me know if you have any other thoughts on this topic.
> >>
> >>
> >> -Ryan
> >>
> >> Email: rjbaxter@us.ibm.com
> >> Phone: 978-899-3041
> >> developerWorks Profile
> >>
> >>
>
>
>
Re: Securing RPC
Posted by Ryan J Baxter <rj...@us.ibm.com>.
Agree, sounds good to me. I will keep you in the loop.
-Ryan
Email: rjbaxter@us.ibm.com
Phone: 978-899-3041
developerWorks Profile
From: John Hjelmstad <jo...@gmail.com>
To: Ryan J Baxter/Westford/IBM@Lotus,
Cc: dev@shindig.apache.org, Andrew E Davis
<An...@notesdev.ibm.com>, Paul Lindner <li...@inuus.com>
Date: 08/11/2011 08:19 PM
Subject: Re: Securing RPC
On Wed, Aug 10, 2011 at 5:16 PM, Ryan J Baxter <rj...@us.ibm.com>
wrote:
> Responses inline.
>
>
> -Ryan
>
> Email: rjbaxter@us.ibm.com
> Phone: 978-899-3041
> developerWorks Profile<
http://www.ibm.com/developerworks/mydeveloperworks/profiles/user/RyanJBaxter
>
>
>
>
> From: John Hjelmstad <fa...@google.com>
> To: dev@shindig.apache.org,
> Cc: John Hjelmstad <jo...@gmail.com>, Paul Lindner <
> lindner@inuus.com>, Andrew E Davis/Westford/IBM@IBMUS
> Date: 08/10/2011 06:10 PM
> Subject: Re: Securing RPC
> ------------------------------
>
>
>
> >Hey Ryan,
> >
> >A few comments inline.
> >
> >On Wed, Aug 10, 2011 at 3:02 PM, Ryan J Baxter <rj...@us.ibm.com>
> wrote:
> >
> >> John and Paul,
> >>
> >> In May, when Andrew and I were out at Google, we talked to you guys
at a
> >> high level about how to secure features and the RPC functionality in
> >> Shindig. Andrew and I are at the point where we would like to
tackle
> >> this and would like to keep you guys in the loop with the
implementation
> >> so we can come up with a solid implementation. Based on our
> conversation
> >> in May, here is what I have for high level changes that would need to
be
> >> made.
> >>
> >> -Add a "feature security service" which will interface with some data
> >> store describing what features are allowed for a given container.
> >>
> >
> >Sounds good to me.
> >
> >
> >>
> >> -Possibly add a new gadget renderer or modify the existing gadget
render
> >> code to not return feature code if the feature has not been enabled
in a
> >> given container.
> >>
> >
> >By "not return feature code" do you mean "return empty code" -- or is
it
> an
> >implicit requirement that symbol names be exported but with empty
> >implementations?
> >
>
> I was thinking that the JS would just not be loaded in the iFrame for
the
> gadget. But now that I am thinking about this that may not be so good
since
> it will probably result in errors in the gadget. Returning empty
> implementations of the functions is probably a little better, but may
still
> result in JS errors in the gadget.
That was my concern as well, though Dan's point about a gadget that
<Requires> a feature that is denied is a good one. The regular recommended
approach in this case is to just issue an error in the container,
indicating
that the gadget cannot be rendered in the first place.
Under that assertion, the problem space is reduced to essentially nothing.
If any rpc is denied that is provided by a <Requires>'d feature, the
gadget
fails. If the feature is <Optional>, the gadget should behave
appropriately
anyway.
>
>
> >
> >>
> >> -Add a new element/parameter to the feature XML to allow feature
> >> developers to specify the RPC endpoints they use in their feature
code.
> >>
> >
> >You should be able to use:
> ><api>
> > <exports type="rpc">rpc_symbol_name</exports>
> ></api>
> >
> >...for this purpose. I'm excited to see that be put to use.
>
> Great I will take a look at that!
>
>
> >
> >
> >>
> >> -Add an "RPC arbitrator" that uses the information from feature
security
> >> service in combination with the RPC endpoints specified in the
feature
> XML
> >> to either allow or disallow RPC requests made by gadgets.
> >>
> >
> >I assume this piece will be in the container/provider-side JS, true?
You
> >might be able to auto-generate stubs for this from the JS server
itself,
> >without a whole lot of code.
> >
>
> Yeah this will be in the container. We were thinking the RPC code will
> have a setArbitrator function which can be used to set the arbitrator to
> use. We were also thinking of pulling down the list of allowed RPC
> endpoints when the container makes the metadata request for the gadget.
> Could you elaborate more on what you were thinking with the JS server?
>
>
> >Cheers,
> >John
> >
> >
> >>
> >> Please let me know if you have any other thoughts on this topic.
> >>
> >>
> >> -Ryan
> >>
> >> Email: rjbaxter@us.ibm.com
> >> Phone: 978-899-3041
> >> developerWorks Profile
> >>
> >>
>
>
>
Re: Securing RPC
Posted by John Hjelmstad <jo...@gmail.com>.
On Wed, Aug 10, 2011 at 5:16 PM, Ryan J Baxter <rj...@us.ibm.com> wrote:
> Responses inline.
>
>
> -Ryan
>
> Email: rjbaxter@us.ibm.com
> Phone: 978-899-3041
> developerWorks Profile<http://www.ibm.com/developerworks/mydeveloperworks/profiles/user/RyanJBaxter>
>
>
>
> From: John Hjelmstad <fa...@google.com>
> To: dev@shindig.apache.org,
> Cc: John Hjelmstad <jo...@gmail.com>, Paul Lindner <
> lindner@inuus.com>, Andrew E Davis/Westford/IBM@IBMUS
> Date: 08/10/2011 06:10 PM
> Subject: Re: Securing RPC
> ------------------------------
>
>
>
> >Hey Ryan,
> >
> >A few comments inline.
> >
> >On Wed, Aug 10, 2011 at 3:02 PM, Ryan J Baxter <rj...@us.ibm.com>
> wrote:
> >
> >> John and Paul,
> >>
> >> In May, when Andrew and I were out at Google, we talked to you guys at a
> >> high level about how to secure features and the RPC functionality in
> >> Shindig. Andrew and I are at the point where we would like to tackle
> >> this and would like to keep you guys in the loop with the implementation
> >> so we can come up with a solid implementation. Based on our
> conversation
> >> in May, here is what I have for high level changes that would need to be
> >> made.
> >>
> >> -Add a "feature security service" which will interface with some data
> >> store describing what features are allowed for a given container.
> >>
> >
> >Sounds good to me.
> >
> >
> >>
> >> -Possibly add a new gadget renderer or modify the existing gadget render
> >> code to not return feature code if the feature has not been enabled in a
> >> given container.
> >>
> >
> >By "not return feature code" do you mean "return empty code" -- or is it
> an
> >implicit requirement that symbol names be exported but with empty
> >implementations?
> >
>
> I was thinking that the JS would just not be loaded in the iFrame for the
> gadget. But now that I am thinking about this that may not be so good since
> it will probably result in errors in the gadget. Returning empty
> implementations of the functions is probably a little better, but may still
> result in JS errors in the gadget.
That was my concern as well, though Dan's point about a gadget that
<Requires> a feature that is denied is a good one. The regular recommended
approach in this case is to just issue an error in the container, indicating
that the gadget cannot be rendered in the first place.
Under that assertion, the problem space is reduced to essentially nothing.
If any rpc is denied that is provided by a <Requires>'d feature, the gadget
fails. If the feature is <Optional>, the gadget should behave appropriately
anyway.
>
>
> >
> >>
> >> -Add a new element/parameter to the feature XML to allow feature
> >> developers to specify the RPC endpoints they use in their feature code.
> >>
> >
> >You should be able to use:
> ><api>
> > <exports type="rpc">rpc_symbol_name</exports>
> ></api>
> >
> >...for this purpose. I'm excited to see that be put to use.
>
> Great I will take a look at that!
>
>
> >
> >
> >>
> >> -Add an "RPC arbitrator" that uses the information from feature security
> >> service in combination with the RPC endpoints specified in the feature
> XML
> >> to either allow or disallow RPC requests made by gadgets.
> >>
> >
> >I assume this piece will be in the container/provider-side JS, true? You
> >might be able to auto-generate stubs for this from the JS server itself,
> >without a whole lot of code.
> >
>
> Yeah this will be in the container. We were thinking the RPC code will
> have a setArbitrator function which can be used to set the arbitrator to
> use. We were also thinking of pulling down the list of allowed RPC
> endpoints when the container makes the metadata request for the gadget.
> Could you elaborate more on what you were thinking with the JS server?
>
>
> >Cheers,
> >John
> >
> >
> >>
> >> Please let me know if you have any other thoughts on this topic.
> >>
> >>
> >> -Ryan
> >>
> >> Email: rjbaxter@us.ibm.com
> >> Phone: 978-899-3041
> >> developerWorks Profile
> >>
> >>
>
>
>
Re: Securing RPC
Posted by Ryan J Baxter <rj...@us.ibm.com>.
Responses inline.
-Ryan
Email: rjbaxter@us.ibm.com
Phone: 978-899-3041
developerWorks Profile
From: John Hjelmstad <fa...@google.com>
To: dev@shindig.apache.org,
Cc: John Hjelmstad <jo...@gmail.com>, Paul Lindner
<li...@inuus.com>, Andrew E Davis/Westford/IBM@IBMUS
Date: 08/10/2011 06:10 PM
Subject: Re: Securing RPC
>Hey Ryan,
>
>A few comments inline.
>
>On Wed, Aug 10, 2011 at 3:02 PM, Ryan J Baxter <rj...@us.ibm.com>
wrote:
>
>> John and Paul,
>>
>> In May, when Andrew and I were out at Google, we talked to you guys at
a
>> high level about how to secure features and the RPC functionality in
>> Shindig. Andrew and I are at the point where we would like to tackle
>> this and would like to keep you guys in the loop with the
implementation
>> so we can come up with a solid implementation. Based on our
conversation
>> in May, here is what I have for high level changes that would need to
be
>> made.
>>
>> -Add a "feature security service" which will interface with some data
>> store describing what features are allowed for a given container.
>>
>
>Sounds good to me.
>
>
>>
>> -Possibly add a new gadget renderer or modify the existing gadget
render
>> code to not return feature code if the feature has not been enabled in
a
>> given container.
>>
>
>By "not return feature code" do you mean "return empty code" -- or is it
an
>implicit requirement that symbol names be exported but with empty
>implementations?
>
I was thinking that the JS would just not be loaded in the iFrame for the
gadget. But now that I am thinking about this that may not be so good
since it will probably result in errors in the gadget. Returning empty
implementations of the functions is probably a little better, but may
still result in JS errors in the gadget.
>
>>
>> -Add a new element/parameter to the feature XML to allow feature
>> developers to specify the RPC endpoints they use in their feature code.
>>
>
>You should be able to use:
><api>
> <exports type="rpc">rpc_symbol_name</exports>
></api>
>
>...for this purpose. I'm excited to see that be put to use.
Great I will take a look at that!
>
>
>>
>> -Add an "RPC arbitrator" that uses the information from feature
security
>> service in combination with the RPC endpoints specified in the feature
XML
>> to either allow or disallow RPC requests made by gadgets.
>>
>
>I assume this piece will be in the container/provider-side JS, true? You
>might be able to auto-generate stubs for this from the JS server itself,
>without a whole lot of code.
>
Yeah this will be in the container. We were thinking the RPC code will
have a setArbitrator function which can be used to set the arbitrator to
use. We were also thinking of pulling down the list of allowed RPC
endpoints when the container makes the metadata request for the gadget.
Could you elaborate more on what you were thinking with the JS server?
>Cheers,
>John
>
>
>>
>> Please let me know if you have any other thoughts on this topic.
>>
>>
>> -Ryan
>>
>> Email: rjbaxter@us.ibm.com
>> Phone: 978-899-3041
>> developerWorks Profile
>>
>>
Re: Securing RPC
Posted by John Hjelmstad <fa...@google.com>.
Hey Ryan,
A few comments inline.
On Wed, Aug 10, 2011 at 3:02 PM, Ryan J Baxter <rj...@us.ibm.com> wrote:
> John and Paul,
>
> In May, when Andrew and I were out at Google, we talked to you guys at a
> high level about how to secure features and the RPC functionality in
> Shindig. Andrew and I are at the point where we would like to tackle
> this and would like to keep you guys in the loop with the implementation
> so we can come up with a solid implementation. Based on our conversation
> in May, here is what I have for high level changes that would need to be
> made.
>
> -Add a "feature security service" which will interface with some data
> store describing what features are allowed for a given container.
>
Sounds good to me.
>
> -Possibly add a new gadget renderer or modify the existing gadget render
> code to not return feature code if the feature has not been enabled in a
> given container.
>
By "not return feature code" do you mean "return empty code" -- or is it an
implicit requirement that symbol names be exported but with empty
implementations?
>
> -Add a new element/parameter to the feature XML to allow feature
> developers to specify the RPC endpoints they use in their feature code.
>
You should be able to use:
<api>
<exports type="rpc">rpc_symbol_name</exports>
</api>
...for this purpose. I'm excited to see that be put to use.
>
> -Add an "RPC arbitrator" that uses the information from feature security
> service in combination with the RPC endpoints specified in the feature XML
> to either allow or disallow RPC requests made by gadgets.
>
I assume this piece will be in the container/provider-side JS, true? You
might be able to auto-generate stubs for this from the JS server itself,
without a whole lot of code.
Cheers,
John
>
> Please let me know if you have any other thoughts on this topic.
>
>
> -Ryan
>
> Email: rjbaxter@us.ibm.com
> Phone: 978-899-3041
> developerWorks Profile
>
>