Mike I will try to answer some of the questions the best I can, but I don't think I can answer everything. Hopefully I can get your going in the right direction. First at a high level I am wondering if you are trying to avoid the typical OAuth dance where the user has to log in and grant access to the app/gadget? I could see this hindering the user experience if you have a gadget asking a user to do the OAuth dance with itself.
On Tue, Oct 1, 2013 at 7:25 PM, Mike Pawlowski <mpaw...@ca.ibm.com> wrote: > > > Hi, > > --------------------------------------------------------------------------------------------------- > Use Case > --------------------------------------------------------------------------------------------------- > > We are trying to integrate a Shindig application as a direct member in our > SSO group based on the > OAuth 2.0 protocol (i.e. Assigned a client key and secret). > Specifically, we want to be able to execute a makeRequest from a gadget > against a protected > resource located on member applications in the SSO group. > > --------------------------------------------------------------------------------------------------- > Problem > --------------------------------------------------------------------------------------------------- > > Unfortunately, I haven't had any success in configuring Shindig to work > out-of-the-box with > our SSO Authorization Server. Ostensibly, our Authorization Server does not > strictly conform to > the OAuth 2.0 protocol (http://tools.ietf.org/html/rfc6749 ). > > We support a variant of the Authorization Code flow with an SSO twist. > > e.g. We use response and grant type values that differ from the > specification: > > 4.1.1. Authorization Request > response_type > REQUIRED. Value MUST be set to "code". > > 4.1.3. Access Token Request > grant_type > REQUIRED. Value MUST be set to "authorization_code". > > --------------------------------------------------------------------------------------------------- > Questions > --------------------------------------------------------------------------------------------------- > > (Q 1) As a meta-question, what is the recommended way to configure Shindig > to facilitate gadget makeRequest calls to protected resources using SSO / > OAuth 2.0? If you are just looking to test OAuth with Shindig out of the box the only thing you need to worry about configuring is the oauth.json and oauth2.json files. For example if you want to test the oauth2_google.xml gadget in the sample container in Shindig you would have to go to the Google API Console register the gadget to get an API key and secret and then add them to the oauth2.json file. > > I just want to validate whether we are taking the right approach by making > Shindig directly participate as a member our SSO group. > I'm following the OAuth 2 examples shipped with Shindig > (e.g. /gadgets/oauth2/oauth2_google.xml) > > On the surface, the easier alternative would be to get the access token and > pass it in as a parameter to the makeRequest call > (essentially Shindig would strictly proxy the request to the protected > resource rather than explicitly handle authorization). > i.e. > params[gadgets.io.RequestParameters.OAUTH_REQUEST_TOKEN] = "some-token"; > (or "some-token" is provided as a value to some custom Authorization > header) This is generally discouraged. All information related to OAuth is kept on the server. When the gadget makes a request the requires OAuth the proxy will add the access token to the request if it has one. If it doesn't have one will send back the authorization URL for the gadget to then use the oauth-popup feature to do the OAuth dance. > > In our case, the OpenSocial gadget container is located on a page that is > itself a protected resource. > The user will already be authenticated with our Authorization Server and > the server hosting the > page / OpenSocial gadget container will already have the corresponding > access token. > Unfortunately, the server hosting the page is on a different domain than > the Shindig server. > As a result, securely passing the access token to the gadget container / > gadget is very problematic. > I'm not sure if there is API in the Common Container that we could leverage > or some other established > procedure / method we could employ to get the access token securely... > Shindig has guice modules which are responsible for fetching and storing access tokens (keyed on the gadget and the user). If you could point Shindig at the place where the access tokens are stored than Shindig could use those access tokens. Essentially it might make sense to have a centralized store for access tokens that both the application/container and the Shindig server use. > Is there another option (i.e. Third approach)? > > Also, I'm curious if you know if other Shindig consumers have similar SSO > integration requirements and how they > implemented their support with respect to gadget makeRequest calls. It > would be a good point of reference. > > > (Q 2) Is there any documentation or guidance or examples on configuring > SSO / OAuth 2.0 support in Shindig and gadgets? > > I'm currently reverse engineering the Shindig source to figure out things, > relying on > comments in the various configuration files and reading the relevant > gadget / RFC specification > > e.g. > http://opensocial-resources.googlecode.com/svn/spec/2.5/Core-Gadget.xml#gadgets.io.makeRequest > > http://opensocial-resources.googlecode.com/svn/spec/2.5/Core-Gadget.xml#OAuth > > http://tools.ietf.org/html/rfc6749 > > For example, I noticed that there appears to be a degree of magic being > used in the "oauthpopup" gadget feature > to handle the OAuth 2.0 user authentication and redirection flow - which > isn't explained to a large degree. > This link might be helpful https://cwiki.apache.org/confluence/display/SHINDIG/OAuth+2.0+Service+Provider+Implementation+in+Apache+Shindig What questions do you have about OAuth popup? There isn't really much complex code in there. The one tricky think to keep in mind is that the OAuth callback servlets do interact with the JavaScript in that feature. For example that is how the popup window is closed automatically. > > (Q 3) What are the OAuth 2.0 / SSO specific classes / configuration files / > etc I should be focusing on or be aware of? > > I'm just trying to get an inventory of all the Shindig files I need to > modify or potentially be aware of (for debugging purposes) that would > assist me > in my integration task: > > e.g. Examples > /gadgets/oauth2 > > e.g. Configuration files > /WEB-INF/classes/config/oauth2.json > shindig.properties > > e.g. Servlets > /src/main/java/org/apache/shindig/gadgets/servlet/OAuth2CallbackServlet.java > > e.g. Packages / Classes > org.apache.shindig.gadgets.oauth2 > > e.g. JavaScript > src/main/javascript/features/oauthpopup/oauthpopup.js > > Anything else? > I think that covers it. > > (Q 4) How do I enable server logging in Shindig? > > I'd like to start by turning on all Shindig server logging across the board > and then progressively > filtering it down by log level and then only by OAuth specific classes: > e.g. > > if (OAuth2CallbackServlet.LOGGER.isLoggable(Level.FINE)) { > OAuth2CallbackServlet.LOGGER.log(Level.FINE, " callback exception " > , t); > } > > Is it just a matter of adding a log4j.properties file in a certain > directory and configuring by class? > e.g. > log4j.logger.net.jazz.ajax.service/ProxyOperation=TRACE > log4j.logger.net.jazz.ajax.service/AuthClient=TRACE > Hmmm haven't done this one yet. But I am guessing you should be able to enable logging for Shindig the same way you would do for other apps in the web container. > > (Q 5) How do I inject support for custom OAuth 2.0 grant types into > Shindig? > > Assuming we are following the right approach defined in the "Use Case" > section and (Q 1), there > appears to be injection points for consumers to add support for custom > grant types (which I *believe* is required in our case): > (a) org.apache.shindig.gadgets.oauth2.handler.GrantRequestHandler > (b) > org.apache.shindig.gadgets.oauth2.handler.AuthorizationEndpointResponseHandler > > Are there any other injection points that are relevant to the SSO / OAuth > 2.0 integration task? There are a lot of them, as far as which ones are related to grant types I am not sure. At some level I am sure most of the OAuth implementation is replaceable via Guice injection however there are probably only a few key pieces that you probably want to replace. There are several Guice modules for OAuth in the web.xml, that is probably the best place to start. > Just to confirm, is this accomplished via Guice? > Is this the best resource for learning how to use Guice: > https://code.google.com/p/google-guice/ ? That and a little bit of debugging ;) That is how I learned anyways. > > > Thanks in advance, > > Mike >
