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 >
