Generally speaking there was nothing done to address the management of gadget bindings and clients externally.
On Thu, Jun 21, 2012 at 2:38 PM, Matthew G Marum <mgma...@us.ibm.com> wrote: > Client Credentials flow was implemented in OAuth 2.0 service provider and > the OAuth 2.0 consumer within Shindig. The client credentials flow is 2 > legged. > > *http://docs.opensocial.org/display/OSREF/Running+the+Demo+Gadgets*<http://docs.opensocial.org/display/OSREF/Running+the+Demo+Gadgets> > > * > https://cwiki.apache.org/confluence/display/SHINDIG/OAuth+2.0+Service+Provider+Implementation+in+Apache+Shindig > *<https://cwiki.apache.org/confluence/display/SHINDIG/OAuth+2.0+Service+Provider+Implementation+in+Apache+Shindig> > > > 2 legged OAuth 1.0a is also an option. > > > Matthew G Marum > Software Engineer | IBM Software Emerging Standards > mgma...@us.ibm.com | Office: 1 919 254 9702 > > [image: Inactive hide details for Ryan J Baxter---06/20/2012 08:51:50 > PM---Doug I don't think we have any flows for OAuth 2 implemented]Ryan J > Baxter---06/20/2012 08:51:50 PM---Doug I don't think we have any flows for > OAuth 2 implemented in Shindig that would support server t > > > > From: > > > Ryan J Baxter/Westford/IBM@Lotus > > To: > > > dev@shindig.apache.org > > Date: > > > 06/20/2012 08:51 PM > > Subject: > > > Re: Adding additional APIs to Shindig > ------------------------------ > > > > Doug I don't think we have any flows for OAuth 2 implemented in Shindig > that would support server to server calls, at least as far as I know. Adam > please correct me if I am wrong. Maybe you could using 2 legged OAuth > 1.0a... > > -Ryan > > > > > From: daviesd <davi...@oclc.org> > To: <dev@shindig.apache.org>, > Date: 06/20/2012 12:57 PM > Subject: Re: Adding additional APIs to Shindig > > > > 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 > >> > >> > > > > > >
