Re: Securing RPC

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