Just to clarify where my thinking was headed.

I need to provide an oauth client management api for a sandbox ui to use.
This ui is not in the same webapp/host as shindig.  In fact it's a
completely separate environment that supports uploading of a gadget,
collecting oauth client credentials, binding those credentials to the
gadget, and rendering the gadget.  I don't necessarily want the container
javascript making the calls.  It would most like be server to server.

So I was leaning towards just plugging into the current rest/rpc handler and
either securing this client management api via a security token or oauth2
(assuming I can do server to server with that).

Or the other option is to just create an entirely different endpoint with a
plain old servlet on the shindig side and handle the security using a shared
secret.

I guess I was just wondering if it's better to use the framework provided or
homebrew this admin api myself.

doug


On 6/19/12 2:38 PM, "daviesd" <davi...@oclc.org> wrote:

> Thanks Stanton.  So it sounds like you were saying to roll my own on this and
> not try to leverage off of any existing shindig handlers?  I certainly agree
> on the security aspect.  This would all take place over ssl.
> 
> doug
> 
> 
> On 6/18/12 5:26 PM, "Stanton Sievers" <ssiev...@us.ibm.com> wrote:
> 
>> Hi Doug,
>> 
>> The largest challenge that I can see with doing what you're trying would
>> be to secure that endpoint.  Someone being able to add their own client
>> could potentially be bad.  From my viewpoint, if this is server to server,
>> you would want to sign the request with Server 1's private key and encrypt
>> with Server 2's public key.  Server 2 would decrypt with their private key
>> and verify the sender with Server 1's public key before adding the client.
>>  That would keep any old Joe from calling that endpoint and adding clients
>> to your system.  You would certainly want the client_secret to not be
>> plaintext on the wire.  That's my first thought, but I'm no security
>> expert. :)
>> 
>> Maybe I'm missing the point altogether...
>> 
>> Thanks,
>> -Stanton
>> 
>> 
>> 
>> From:   daviesd <davi...@oclc.org>
>> To:     shindig <dev@shindig.apache.org>,
>> Date:   06/18/2012 16:28
>> Subject:        Adding additional APIs to Shindig
>> 
>> 
>> 
>> I have an API I want to add to our custom shindig server that doesn¹t fit
>> any current opensocial specs (appdata, people, etc.).  The API would allow
>> our gadget sandbox webapp to create the oauth2 client and oauth2 gadget
>> binding entries (server to server).
>> 
>> So something like
>> 
>> POST /opensocial/rest/oauth2client [client_id, client_secret,
>> provider_name,
>> application url]
>> 
>> This would allow our sandbox gadget writers to enable oauth2 bindings
>> without a third party having to be involved.
>> 
>> My question is, what is the best way to expose such an API?  Should I just
>> expose it like all the other REST endpoints (and also via RPC) or should I
>> just create a servlet with my own authentication scheme (perhaps just
>> basic
>> authentication)?  If I use the existing framework should I use security
>> tokens or should I use oauth2?
>> 
>> I¹d be interested in hearing other viewpoints by people who have extended
>> shindig with their own APIs.
>> 
>> Thanks,
>> Doug
>> 
>> 


Reply via email to