Hello Marton - Thank you for posting to the dev list!
Kevin has been on the road this week and I believe today is a travel day - so he will likely be unavailable most of the day. I think that your thinking is mostly inline with what we have considered while investigating OAuth support for Knox in the past. I have to give some thought to the specific usecases that are trying to be supported here. Perhaps, you have very specific scenarios in mind for your product/customers? My recent thinking on the topic has been that we want to support OAuth token as a single-signon token from identity federation providers and that they would be delivered as a bearer token to the REST endpoint. This aligns more closely with other enterprise SSO mechnanisms such as SAML. There is a set of emerging standards in this space that I have been tracking and believe to be the right direction for OAuth 2 SSO tokens in the enterprise - for instance: http://tools.ietf.org/html/draft-ietf-oauth-jwt-bearer-09 Now, you may have usecases in mind for your offerings that are more mobile/consumer facing which would be more aligned with the authorization code and/or implicit flows. We should take a step back and drill into your motivations for the proposal in terms of usecases. Others may have other questions and thoughts on your proposal - so we will continue discussion on this thread. I look forward to working with you on this! thanks, --larry On Fri, May 2, 2014 at 5:45 AM, Marton Sereg <[email protected]>wrote: > Hi Vinay, Kevin, > > I’m reposting the email I’ve sent you last week about the Knox-OAuth2 > integration: > > after our talk last Friday we've started to think about the high level > design of how to integrate Knox with Oauth2 and came up with some ideas. To > demonstrate these we've created a simple sequence diagram that shows a > usual Oauth2 flow in case of Knox. > I haven't included every detail in the diagram as it would be too complex > but the essential parts are there. We thought that the authorization server > shouldn't be included in Knox, but it's access must be configurable. This > way the Knox Gateway will function only as a Resource Server in the OAuth2 > flow and this design allows users of Knox to use their own authorization > server and integrate it with Knox. In our PoC we will use Cloudfoundry's > UAA authorization server that is easily customizable and deployable. > > To be able to integrate Oauth2 in Knox we must solve two things: > > - Create an Oauth2 Provider in Knox that is able to handle the > authorization of a request based on an access token in the request's header. > This provider's filter needs to check first if the token is valid by > sending the token to the Authorization Server's /check_token endpoint. It > should be something very similar to what UAA's RemoteTokenServices class > does. > After the response from the Authorization Server arrives, the Knox Gateway > should handle the scopes and should decide if the original request can be > fulfilled. > > - The Knox Groovy Shell client must be prepared to handle the Oauth2 > flow's Client part > The sequence diagram shows the OAuth2 flow in case of a web application > client. As the Knox Groovy shell is not a web application and does not > involve communication with a browser, the flow will be a bit different in > this case (will likely use the implicit grant type) > > > Please let us know if you have any comments or ideas. > > thanks, > Marton >
