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? 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) 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... 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. (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? (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 (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? 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/ ? Thanks in advance, Mike
