Hi Marton - I apologize for the delayed response.
I think that it may make sense to take a look at Apache Oltu as the OAuth 2 resource server provider in Knox. http://oltu.apache.org/ I am not sure how far along there are in the implementation but I believe that the core OAuth 2 capabilities are available in 1.0. If it is possible to add the Oltu OAuth support through a servlet filter then it should be relatively straight forward to do so in a new federation provider in Knox for Oltu. The investigation should probably be a POC to prove Oltu's support for your requirements and then we can work on getting it plugged into Knox. I think there is great potential there and would love to see this move forward. What do you think? thanks, --larry On Tue, May 6, 2014 at 11:13 AM, larry mccay <[email protected]> wrote: > Hi Marton - > > Thank you for the additional context - it does make a few things more > clear. > After some thought, I will have follow up questions to help flesh out a > full usecase description. > > Once we have that nailed down we will be able to determine the best way to > integrate a new provider for it. > > thanks! > > --larry > > > On Tue, May 6, 2014 at 9:42 AM, Marton Sereg > <[email protected]>wrote: > >> Hi Larry, >> >> Our product has a Spring Boot based UI and a REST API - where the REST >> API acts as a resource server, and the UI as a client application in the >> OAuth flow. The auth tokens used by the client and accepted by the resource >> server are provided and validated by an external OAuth provider (internally >> we use Cloudfoundry’s UAA to test against). Our case is a bit simpler as we >> use Spring Security, whereas in case of Knox we’d need to create the >> providers/filter from the scratch. >> >> Our reason to have an OAuth2 provider is to offer the same experience - >> when customers interact with the cluster secured via Knox our use our UI >> they don’t need to maintain different set of credentials or re-sign when >> switching between the web applications. >> >> Marton >> >> On May 2, 2014, at 12:50 PM, larry mccay <[email protected]> wrote: >> >> > 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 >> > >> >> >
