Re: [openstack-dev] [Horizon][Keystone] Steps toward Kerberos and Federation
On 09/05/2014 11:28 AM, Marco Fargetta wrote: I understand the general idea and the motivations but I am not sure about the implementation. Even with a SPA you still need to provide credentials and manage tokens for the authentication/authorisation in a way not too much different from the current implementation. Additionally, this might have some implications with the security since you have to open the services to accept connection from clients everywhere. Is there some schema/spec/pad/whatever describing this new approach for Horizon and the other services? I think several people are starting to discuss things along these lines, most under the Horizon heading. I'm just trying to contribute the Keystone piece. You are quite right about the security implications. One potential approach is to use a Proxy for services and hide any behavior or APIs you don't want exposed to the outside world. But in general, the services themselves should be hardened enough to be exposed directly to the public internet. That is the design of OpenStack. Cheers, Marco On Fri, Sep 05, 2014 at 10:14:00AM -0400, Adam Young wrote: On 09/05/2014 04:49 AM, Marco Fargetta wrote: Hi, I am wondering if the solution I was trying to sketch with the spec "https://review.openstack.org/#/c/96867/13"; is not easier to implement and manage then the steps highlated till n.2. Maybe, the spec is not yet there and should be improved (I will abandon or move to Kilo as Marek suggest) but the overall schema I think it is better then try to complicate the communication between Horizon and Keystone, IMHO. That is a very well written, detailed spec. I'm impressed. The S4U2Proxy/Step one stuff will be ready to go as soon as I drop off the Net for a while and clean up my patches. But that doesn't address the Federation issue. The Javascript approach is, I think, simpler and better than using OAUTH2 as you specify, as it is the direction that Horizon is going anyway: A single page App, Javascript driven, talking direct to all the Remote Services. I want to limit the number of services that get tokens. I want to limit the scope of those tokens as much as possible. Keeping passwords out of Horizon is just the first step to this goal. As I see it Keystone tokens and the OAUTH* protocols are both ways of doing distributed single sign on and delegation of privileges. However, Keystone specifies data that is relevant to OpenStack, and OAUTH is necessarily format agnostic. Using a different mechanism punts on the hard decisions and rewrites the easy ones. Yes, I wish we had started with OAUTH way back a couple years ago, but I can't say it is so compelling that we should do it now. Step 3 is a different story and it needs more evaluation of the possible scenarios opened. Cheers, Marco On Thu, Sep 04, 2014 at 05:37:38PM -0400, Adam Young wrote: While the Keystone team has made pretty good strides toward Federation for getting a Keystone token, we do not yet have a complete story for Horizon. The same is true about Kerberos. I've been working on this, and I want to inform the people that are interested in the approach, as well as get some feedback. My first priority has been Kerberos. I have a proof of concept of this working, but the amount of hacking I had to Django-OpenStack-Auth (DOA) made me shudder: its fairly ugly. A few discussions today have moved things such that I think I can clean up the approach. Phase 1. DOA should be able to tell whether to use password or Kerberos in order to get a token from Keystone based on an variable set by the Apache web server; mod_auth_kerb will set request.META['KRB5CCNAME'] only in the kerberos case. If it gets this variable, DOA will only do Kerberos. If it does not, it will only do password. There will be no fallback from Kerberos to password; this is enforced by mod_auth_kerb, not something we can easily hack around in Django. That gets us Kerberos, but not Federation. Most of the code changes are common with what follows after: Phase 1.5. Add an optional field to the password auth page that allows a user to log in with a token instead of userid/password. This can be a hidden field by default if we really want. DOA now needs to be able to validate a token. Since Horizon only cares about the hashed version of the tokens anyway, we only to Online lookup, not PKI token validation. In the successful response, Keystone will to return the properly hashed (SHA256 for example) of the PKI tokens for Horizon to cache. Phase 2. Use AJAX to get a token from Keystone instead of sending the credentials to the client. Then pass that token to Horizon in order to login. This implies that Keystone has set up CORS support. This will open the door for Federation. While it will provide a different path to Kerberos than the stage 1, I think both are valuable approaches and will serve different use cases. This Phase 3. Never send your token to Horizon. In thi
Re: [openstack-dev] [Horizon][Keystone] Steps toward Kerberos and Federation
I understand the general idea and the motivations but I am not sure about the implementation. Even with a SPA you still need to provide credentials and manage tokens for the authentication/authorisation in a way not too much different from the current implementation. Additionally, this might have some implications with the security since you have to open the services to accept connection from clients everywhere. Is there some schema/spec/pad/whatever describing this new approach for Horizon and the other services? Cheers, Marco On Fri, Sep 05, 2014 at 10:14:00AM -0400, Adam Young wrote: > On 09/05/2014 04:49 AM, Marco Fargetta wrote: > >Hi, > > > >I am wondering if the solution I was trying to sketch with the spec > >"https://review.openstack.org/#/c/96867/13"; is not easier to implement > >and manage then the steps highlated till n.2. Maybe, the spec is not > >yet there and should be improved (I will abandon or move to Kilo as > >Marek suggest) but the overall schema I think it is better then try to > >complicate the communication between Horizon and Keystone, IMHO. > That is a very well written, detailed spec. I'm impressed. > > The S4U2Proxy/Step one stuff will be ready to go as soon as I drop > off the Net for a while and clean up my patches. But that doesn't > address the Federation issue. > > The Javascript approach is, I think, simpler and better than using > OAUTH2 as you specify, as it is the direction that Horizon is going > anyway: A single page App, Javascript driven, talking direct to all > the Remote Services. > > I want to limit the number of services that get tokens. I want to > limit the scope of those tokens as much as possible. Keeping > passwords out of Horizon is just the first step to this goal. > > > As I see it Keystone tokens and the OAUTH* protocols are both ways > of doing distributed single sign on and delegation of privileges. > However, Keystone specifies data that is relevant to OpenStack, and > OAUTH is necessarily format agnostic. Using a different mechanism > punts on the hard decisions and rewrites the easy ones. > > Yes, I wish we had started with OAUTH way back a couple years ago, > but I can't say it is so compelling that we should do it now. > > > > >Step 3 is a different story and it needs more evaluation of the > >possible scenarios opened. > > > >Cheers, > >Marco > > > >On Thu, Sep 04, 2014 at 05:37:38PM -0400, Adam Young wrote: > >>While the Keystone team has made pretty good strides toward > >>Federation for getting a Keystone token, we do not yet have a > >>complete story for Horizon. The same is true about Kerberos. I've > >>been working on this, and I want to inform the people that are > >>interested in the approach, as well as get some feedback. > >> > >>My first priority has been Kerberos. I have a proof of concept of > >>this working, but the amount of hacking I had to > >>Django-OpenStack-Auth (DOA) made me shudder: its fairly ugly. A > >>few discussions today have moved things such that I think I can > >>clean up the approach. > >> > >>Phase 1. DOA should be able to tell whether to use password or > >>Kerberos in order to get a token from Keystone based on an variable > >>set by the Apache web server; mod_auth_kerb will set > >> > >> request.META['KRB5CCNAME'] > >> > >>only in the kerberos case. If it gets this variable, DOA will only > >>do Kerberos. If it does not, it will only do password. There will > >>be no fallback from Kerberos to password; this is enforced by > >>mod_auth_kerb, not something we can easily hack around in Django. > >> > >>That gets us Kerberos, but not Federation. Most of the code changes > >>are common with what follows after: > >> > >>Phase 1.5. Add an optional field to the password auth page that > >>allows a user to log in with a token instead of userid/password. > >>This can be a hidden field by default if we really want. DOA now > >>needs to be able to validate a token. Since Horizon only cares > >>about the hashed version of the tokens anyway, we only to Online > >>lookup, not PKI token validation. In the successful response, > >>Keystone will to return the properly hashed (SHA256 for example) of > >>the PKI tokens for Horizon to cache. > >> > >>Phase 2. Use AJAX to get a token from Keystone instead of sending > >>the credentials to the client. Then pass that token to Horizon in > >>order to login. This implies that Keystone has set up CORS support. > >>This will open the door for Federation. While it will provide a > >>different path to Kerberos than the stage 1, I think both are > >>valuable approaches and will serve different use cases. This > >> > >>Phase 3. Never send your token to Horizon. In this world, the > >>browser, with full CORS support, makes AJAX calls direct to Nova, > >>Glance, and all other services. > >> > >>Yep, this should be a cross project session for the summit. > >> > >>___ > >>OpenStack-dev mailing list > >>
Re: [openstack-dev] [Horizon][Keystone] Steps toward Kerberos and Federation
On 09/05/2014 04:49 AM, Marco Fargetta wrote: Hi, I am wondering if the solution I was trying to sketch with the spec "https://review.openstack.org/#/c/96867/13"; is not easier to implement and manage then the steps highlated till n.2. Maybe, the spec is not yet there and should be improved (I will abandon or move to Kilo as Marek suggest) but the overall schema I think it is better then try to complicate the communication between Horizon and Keystone, IMHO. That is a very well written, detailed spec. I'm impressed. The S4U2Proxy/Step one stuff will be ready to go as soon as I drop off the Net for a while and clean up my patches. But that doesn't address the Federation issue. The Javascript approach is, I think, simpler and better than using OAUTH2 as you specify, as it is the direction that Horizon is going anyway: A single page App, Javascript driven, talking direct to all the Remote Services. I want to limit the number of services that get tokens. I want to limit the scope of those tokens as much as possible. Keeping passwords out of Horizon is just the first step to this goal. As I see it Keystone tokens and the OAUTH* protocols are both ways of doing distributed single sign on and delegation of privileges. However, Keystone specifies data that is relevant to OpenStack, and OAUTH is necessarily format agnostic. Using a different mechanism punts on the hard decisions and rewrites the easy ones. Yes, I wish we had started with OAUTH way back a couple years ago, but I can't say it is so compelling that we should do it now. Step 3 is a different story and it needs more evaluation of the possible scenarios opened. Cheers, Marco On Thu, Sep 04, 2014 at 05:37:38PM -0400, Adam Young wrote: While the Keystone team has made pretty good strides toward Federation for getting a Keystone token, we do not yet have a complete story for Horizon. The same is true about Kerberos. I've been working on this, and I want to inform the people that are interested in the approach, as well as get some feedback. My first priority has been Kerberos. I have a proof of concept of this working, but the amount of hacking I had to Django-OpenStack-Auth (DOA) made me shudder: its fairly ugly. A few discussions today have moved things such that I think I can clean up the approach. Phase 1. DOA should be able to tell whether to use password or Kerberos in order to get a token from Keystone based on an variable set by the Apache web server; mod_auth_kerb will set request.META['KRB5CCNAME'] only in the kerberos case. If it gets this variable, DOA will only do Kerberos. If it does not, it will only do password. There will be no fallback from Kerberos to password; this is enforced by mod_auth_kerb, not something we can easily hack around in Django. That gets us Kerberos, but not Federation. Most of the code changes are common with what follows after: Phase 1.5. Add an optional field to the password auth page that allows a user to log in with a token instead of userid/password. This can be a hidden field by default if we really want. DOA now needs to be able to validate a token. Since Horizon only cares about the hashed version of the tokens anyway, we only to Online lookup, not PKI token validation. In the successful response, Keystone will to return the properly hashed (SHA256 for example) of the PKI tokens for Horizon to cache. Phase 2. Use AJAX to get a token from Keystone instead of sending the credentials to the client. Then pass that token to Horizon in order to login. This implies that Keystone has set up CORS support. This will open the door for Federation. While it will provide a different path to Kerberos than the stage 1, I think both are valuable approaches and will serve different use cases. This Phase 3. Never send your token to Horizon. In this world, the browser, with full CORS support, makes AJAX calls direct to Nova, Glance, and all other services. Yep, this should be a cross project session for the summit. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Horizon][Keystone] Steps toward Kerberos and Federation
Hi, I am wondering if the solution I was trying to sketch with the spec "https://review.openstack.org/#/c/96867/13"; is not easier to implement and manage then the steps highlated till n.2. Maybe, the spec is not yet there and should be improved (I will abandon or move to Kilo as Marek suggest) but the overall schema I think it is better then try to complicate the communication between Horizon and Keystone, IMHO. Step 3 is a different story and it needs more evaluation of the possible scenarios opened. Cheers, Marco On Thu, Sep 04, 2014 at 05:37:38PM -0400, Adam Young wrote: > While the Keystone team has made pretty good strides toward > Federation for getting a Keystone token, we do not yet have a > complete story for Horizon. The same is true about Kerberos. I've > been working on this, and I want to inform the people that are > interested in the approach, as well as get some feedback. > > My first priority has been Kerberos. I have a proof of concept of > this working, but the amount of hacking I had to > Django-OpenStack-Auth (DOA) made me shudder: its fairly ugly. A > few discussions today have moved things such that I think I can > clean up the approach. > > Phase 1. DOA should be able to tell whether to use password or > Kerberos in order to get a token from Keystone based on an variable > set by the Apache web server; mod_auth_kerb will set > > request.META['KRB5CCNAME'] > > only in the kerberos case. If it gets this variable, DOA will only > do Kerberos. If it does not, it will only do password. There will > be no fallback from Kerberos to password; this is enforced by > mod_auth_kerb, not something we can easily hack around in Django. > > That gets us Kerberos, but not Federation. Most of the code changes > are common with what follows after: > > Phase 1.5. Add an optional field to the password auth page that > allows a user to log in with a token instead of userid/password. > This can be a hidden field by default if we really want. DOA now > needs to be able to validate a token. Since Horizon only cares > about the hashed version of the tokens anyway, we only to Online > lookup, not PKI token validation. In the successful response, > Keystone will to return the properly hashed (SHA256 for example) of > the PKI tokens for Horizon to cache. > > Phase 2. Use AJAX to get a token from Keystone instead of sending > the credentials to the client. Then pass that token to Horizon in > order to login. This implies that Keystone has set up CORS support. > This will open the door for Federation. While it will provide a > different path to Kerberos than the stage 1, I think both are > valuable approaches and will serve different use cases. This > > Phase 3. Never send your token to Horizon. In this world, the > browser, with full CORS support, makes AJAX calls direct to Nova, > Glance, and all other services. > > Yep, this should be a cross project session for the summit. > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev smime.p7s Description: S/MIME cryptographic signature ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Horizon][Keystone] Steps toward Kerberos and Federation
On Thu, 2014-09-04 at 17:37 -0400, Adam Young wrote: > While the Keystone team has made pretty good strides toward Federation > for getting a Keystone token, we do not yet have a complete story for > Horizon. The same is true about Kerberos. I've been working on this, > and I want to inform the people that are interested in the approach, as > well as get some feedback. > > My first priority has been Kerberos. I have a proof of concept of this > working, but the amount of hacking I had to Django-OpenStack-Auth (DOA) > made me shudder: its fairly ugly. A few discussions today have moved > things such that I think I can clean up the approach. > > Phase 1. DOA should be able to tell whether to use password or Kerberos > in order to get a token from Keystone based on an variable set by the > Apache web server; mod_auth_kerb will set > > request.META['KRB5CCNAME'] > > only in the kerberos case. If it gets this variable, DOA will only do > Kerberos. If it does not, it will only do password. There will be no > fallback from Kerberos to password; this is enforced by mod_auth_kerb, > not something we can easily hack around in Django. > > That gets us Kerberos, but not Federation. Most of the code changes are > common with what follows after: > > Phase 1.5. Add an optional field to the password auth page that allows > a user to log in with a token instead of userid/password. This can be a > hidden field by default if we really want. DOA now needs to be able to > validate a token. Since Horizon only cares about the hashed version of > the tokens anyway, we only to Online lookup, not PKI token validation. > In the successful response, Keystone will to return the properly hashed > (SHA256 for example) of the PKI tokens for Horizon to cache. > > Phase 2. Use AJAX to get a token from Keystone instead of sending the > credentials to the client. Then pass that token to Horizon in order to > login. This implies that Keystone has set up CORS support. This will > open the door for Federation. While it will provide a different path to > Kerberos than the stage 1, I think both are valuable approaches and will > serve different use cases. This > > Phase 3. Never send your token to Horizon. In this world, the browser, > with full CORS support, makes AJAX calls direct to Nova, Glance, and all > other services. > > Yep, this should be a cross project session for the summit. So it was brought up briefly in Atlanta that keystone should provide a way to discover the available auth mechanisms. This would mean to me for example: 1. a GET /auth/methods or just GET /auth which would include a list of the methods for retrieving a token. (or just jsonhome entries) 2. a GET /OS-FEDERATION/idp that would list the available federated IDPs. (or just jsonhome entries) Horizon would then be able to do a similar thing to web services with 'login using your google id' or with user/pass and do some sensible things based on what is allowed, or if it is receiving a kerberos ticket and kerberos is one of the allowed methods then bypass all this stuff. If we did this wouldn't most of 'use CORS/AJAX/kerberos/whatever' be on a case by case basis? I don't know Horizon or the DOA very well at all so just let me know if i've picked up on completely the wrong things here. Jamie > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
