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 <marton.se...@sequenceiq.com>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 <larry.mc...@gmail.com> 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 < > marton.se...@sequenceiq.com> 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 > > > >
