Re: Knox - OAuth2 integration
Hi Larry, Thanks for the resources on Apache Oltu, we’ll definitely look into its details soon, it seems like a good candidate to start with. We have a lot of other things to work on until the Hadoop Summit however, so it’s likely that we’ll start the PoC only after it’s over. We’ll notify you as soon as we’ll have some progress with this. Marton On May 15, 2014, at 2:20 AM, larry mccay wrote: > 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 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 >> 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 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, >>>> >>>&
Re: Knox - OAuth2 integration
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 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 > 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 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 a
Re: Knox - OAuth2 integration
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 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 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 > > > >
Re: Knox - OAuth2 integration
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 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 > 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 >
Re: Knox - OAuth2 integration
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 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 >
