Re: [openstack-dev] [Keystone][Horizon] CORS and Federation
On 09/17/2014 11:56 AM, Matthieu Huin wrote:
Hi,
- Original Message -
From: Adam Young ayo...@redhat.com
To: openstack-dev@lists.openstack.org
Sent: Wednesday, September 17, 2014 5:00:16 PM
Subject: Re: [openstack-dev] [Keystone][Horizon] CORS and Federation
On 09/17/2014 10:35 AM, David Chadwick wrote:
this would work as well, but wouldn't it require two different API calls?
I think it would be 2 calls no matter what.
OK, lets talk this through:
1. Configure Horizon to return a generic login page, with a button that says
Or do Federated
2. Use clicks that button and gets the Federated UI. No new HTTP request
needed for this, still just static Javascript. Form has an edit field for
the user to enter the SAML IdP, anda button to fetch the list of the public
IdPs from Keystone.
3. Assume user clicks the list of public IdPs, those fill out a drop-down
box. If the user clicks on one, it populates the textbox with the URL for
the IdP.
3a. However, if the users IdP is not in the list, they go back to the email
they got from their IT guy that has Paste this URL into the IdP edit box
4. User clicks OK.
Window pops up with the WebUI for the user to visit the SAML IdP URL. This
will be of the form
GET
htps://keystone/main/OS-FEDERATION/identity_providers/{identity_provider}/protocols/{protocol}/auth
Which will perform the necessary redirects to get the user the SAML
assertion, and return it to Keystone.
5. Javascript picks up the Federated unscoped token from the response at the
end of step 4 and use that to get a scoped token.
I think the jump to step 6 isn't unnecessary: logging in Horizon requires only
a username and a password,
unless I am wrong scoping is done afterwards by selecting a project in a list.
Besides, should we expect
a federated user to necessarily know beforehand to which domain/project she was
mapped ?
Think of it this way; today, Horizon uses the userid and password to
get a token. In the case where that password is in LDAP, Horizon should
never, ever see it. Even Keystone should never see it. So the Token
abstracts that away, and says instead I've checked their password.
its good.
6. Javascript submites the scoped token to Horizon and user is logged in.
Horizon will also need to keep track of the fact that a federated auth was used:
Once Horizon has a token, it can do all this. Federation is kindof
irrelevant.
* to list projects and domains available to the user
* to scope the unscoped saml token
As these are done through the federation API rather than the usual one.
Whew.
Whew indeed !
On 17/09/2014 15:17, Adam Young wrote:
On 09/17/2014 10:07 AM, David Chadwick wrote:
On 17/09/2014 14:55, Marek Denis wrote:
On 17.09.2014 15:45, Steve Martinelli wrote:
++ to your suggestion David, I think making the list of trusted IdPs
publicly available makes sense.
I think this might be useful in an academic/science world but on the
other hand most cloud providers from the 'business' world might be very
reluctant to expose list of their clients for free.
It is interesting that this latter comment came from the
academic/science world, whereas the supportive one came from the
business world :-)
So maybe there could be a config parameter in keystone to determine
which option is installed?
My thought was that there would be a public list, which is a subset of
the overall list.
For non-publicized IdPs, the end users would get an URL out of band and
enter that in when prompted; if they enter an invalid URL, they would
get an warning message.
It wouldn't hide the fact that a customer was registered with a given
cloud provider, but wouldn't advertise it, either.
regards
David
cheers,
Marek.
___
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] [Keystone][Horizon] CORS and Federation
Adam
I agree with you
David
On 18/09/2014 17:17, Adam Young wrote:
On 09/17/2014 11:53 AM, Marek Denis wrote:
Hi,
First of all, we should clarify whether your JS client wants to
implement ECP or WebSSO workflow. They are slightly different.
ECP seems to be poorly supported in live deployments, and we cannot
count on it. WebSSO is the first round. We should do ECP as a second
step.
I feel JS is smart enough to implement the ECP flow and then and it
could simply implement what we already have in the keystoneclient [0].
This + some discovery service described by Adam would be required.
However, some problems may arise when it comes to ADFS support (we
needed separate plugin in keystoneclient) and other protocols which
should work by default from browsers.
[0]
https://github.com/openstack/python-keystoneclient/blob/master/keystoneclient/contrib/auth/v3/saml2.py#L29
Rest of the comments inlined.
On 17.09.2014 17:00, Adam Young wrote:
On 09/17/2014 10:35 AM, David Chadwick wrote:
this would work as well, but wouldn't it require two different API
calls?
I think it would be 2 calls no matter what.
OK, lets talk this through:
1. Configure Horizon to return a generic login page, with a button that
says Or do Federated
2. Use clicks that button and gets the Federated UI. No new HTTP
request needed for this, still just static Javascript. Form has an edit
field for the user to enter the SAML IdP, anda button to fetch the list
of the public IdPs from Keystone.
3. Assume user clicks the list of public IdPs, those fill out a
drop-down box. If the user clicks on one, it populates the textbox with
the URL for the IdP.
3a. However, if the users IdP is not in the list, they go back to the
email they got from their IT guy that has Paste this URL into the IdP
edit box
Well, we don't keep any IdPs' URL in Keystone backend at the moment.
However, this can be easily fixed.
Right. That is a feature request.
4. User clicks OK.
OK
Window pops up with the WebUI for the user to visit the SAML IdP URL.
This will be of the form
|
GET
htps://keystone/main/OS-FEDERATION/identity_providers/{identity_provider}/protocols/{protocol}/auth|
Which will perform the necessary redirects to get the user the SAML
assertion, and return it to Keystone.
Let's assume this step would work for now. I am interested how would
the SP-IDP-SP workflow look like from the JS perspective. In classic
WebSSO, where user uses only his browser:
1) Go to the protected resource
(/v3/OS-FEDERATION/identity_providers/{identity_provider}/protocols/{protocol}/auth
in our case)
2) (skipping the DS step for now) get redirected to the IdP
3) Authenticate with the IdP
4) Get redirected to the SP
5) Read your protected content, because you have been authenticated
and authorized to do so (get an unscoped, federated token issued by
Keystone in our case)
Now, I can imagine, if that's the websso approach can we somehow make
JS mimic the browser with all its blessing? So the user would actualy
see the real HTML website? If so, that would be enough to make it work.
I think that we need to show the user the real website in a Popup window
until we have a guarantee of ECP support.
5. Javascript picks up the Federated unscoped token from the response
at the end of step 4 and use that to get a scoped token.
___
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] [Keystone][Horizon] CORS and Federation
You're quite probably correct - going through the OWASP threat list in more detail is on my TODO. That was just off the top of my head as something that has me concerned but I've not investigated it thoroughly. On 17 September 2014 14:15, Adam Young ayo...@redhat.com wrote: On 09/16/2014 08:56 PM, Richard Jones wrote: CORS for all of OpenStack is possible once the oslo middleware lands*, but as you note it's only one of many elements to be considered when exposing the APIs to browsers. There is no current support for CSRF protection in the OpenStack APIs, for example. I believe that sort of functionality belongs in an intermediary between the APIs and the browser. Typically, CSRF is done by writing a customer header. Why wouldn't the -X-Auth-Token header qualify? Its not a cookie, automatically added. So, CORS support would be necesary for horizon to send the token on a request to Nova, but no other site would be able to do that. No? Richard * https://review.openstack.org/#/c/120964/ On 17 September 2014 08:59, Gabriel Hurley gabriel.hur...@nebula.com wrote: This is generally the right plan. The hard parts are in getting people to deploy it correctly and securely, and handling fallback cases for lack of browser support, etc. What we really don't want to do is to encourage people to set Access-Control-Allow-Origin: * type headers or other such nonsense simply because it's too much work to do things correctly. This becomes especially challenging for federated clouds. I would encourage looking at the problem of adding all the necessary headers for CORS as an OpenStack-wide issue. Once you figure it out for Keystone, the next logical step is to want to make calls from the browser directly to all the other service endpoints, and each service is going to have to respond with the correct CORS headers (Access-Control-Allow-Methods and Access-Control-Allow-Headers are particularly fun ones for projects like Glance or Swift). A common middleware and means of configuring it will go a long way to easing user pain and spurring adoption of the new mechanisms. It will help the Horizon team substantially in the long run to do it consistently and predictably across the stack. As a side-note, once we're in the realm of handling all this sensitive data with the browser as a middleman, encouraging people to configure things like CSP is probably also a good idea to make sure we're not loading malicious scripts or other resources. Securing a browser-centric world is a tricky realm... let's make sure we get it right. :-) - Gabriel -Original Message- From: Adam Young [mailto:ayo...@redhat.com] Sent: Tuesday, September 16, 2014 3:40 PM To: OpenStack Development Mailing List Subject: [openstack-dev] [Keystone][Horizon] CORS and Federation Phase one for dealing with Federation can be done with CORS support solely for Keystone/Horizon integration: 1. Horizon Login page creates Javascript to do AJAX call to Keystone 2. Keystone generates a token 3. Javascript reads token out of response and sends it to Horizon. This should support Kerberos, X509, and Password auth; the Keystone team is discussing how to advertise mechanisms, lets leave the onus on us to solve that one and get back in a timely manner. For Federation, the handshake is a little more complex, and there might be a need for some sort of popup window for the user to log in to their home SAML provider. Its several more AJAX calls, but the end effect should be the same: get a standard Keystone token and hand it to Horizon. This would mean that Horizon would have to validate tokens the same way as any other endpoint. That should not be too hard, but there is a little bit of create a user, get a token, make a call logic that currently lives only in keystonemiddleware/auth_token; Its a solvable problem. This approach will support the straight Javascript approach that Richard Jones discussed; Keystone behind a proxy will work this way without CORS support. If CORS can be sorted out for the other services, we can do straight Javascript without the Proxy. I see it as phased approach with this being the first phase. ___ 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 listOpenStack-dev@lists.openstack.orghttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org
Re: [openstack-dev] [Keystone][Horizon] CORS and Federation
Hi Adam Kristy has already added support to Horizon for federated login to Keystone. She will send you details of how she did this. One issue that arose was this: in order to give the user the list of IDPs/protocols that are trusted, the call to Keystone needs to be authenticated. But the user is not yet authenticated. So Horizon has to have its own credentials for logging into Keystone so that it can retrieve the list of IdPs for the user. This works, but it is not ideal. The situation is far worse for the Keystone command line client. The user is not logged in and the Keystone client does not have its own account on Keystone, so it cannot retrieve the list of IdPs for the user. The only way that Kristy could solve this, was to remove the requirement for authentication to the API that retrieves the list of IdPs. But this is not a standard solution as it requires modifying the core Keystone code. We need a fix to address this issue. My suggestion would be to make the API for retrieving the list of trusted IDPs publicly accessible, so that no credentials are needed for this. regards David On 16/09/2014 23:39, Adam Young wrote: Phase one for dealing with Federation can be done with CORS support solely for Keystone/Horizon integration: 1. Horizon Login page creates Javascript to do AJAX call to Keystone 2. Keystone generates a token 3. Javascript reads token out of response and sends it to Horizon. This should support Kerberos, X509, and Password auth; the Keystone team is discussing how to advertise mechanisms, lets leave the onus on us to solve that one and get back in a timely manner. For Federation, the handshake is a little more complex, and there might be a need for some sort of popup window for the user to log in to their home SAML provider. Its several more AJAX calls, but the end effect should be the same: get a standard Keystone token and hand it to Horizon. This would mean that Horizon would have to validate tokens the same way as any other endpoint. That should not be too hard, but there is a little bit of create a user, get a token, make a call logic that currently lives only in keystonemiddleware/auth_token; Its a solvable problem. This approach will support the straight Javascript approach that Richard Jones discussed; Keystone behind a proxy will work this way without CORS support. If CORS can be sorted out for the other services, we can do straight Javascript without the Proxy. I see it as phased approach with this being the first phase. ___ 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] [Keystone][Horizon] CORS and Federation
++ to your suggestion David, I think making the list of trusted IdPs publicly available makes sense. - Steve David Chadwick d.w.chadw...@kent.ac.uk wrote on 09/17/2014 09:37:21 AM: From: David Chadwick d.w.chadw...@kent.ac.uk To: openstack-dev@lists.openstack.org, Kristy Siu k.w.s@kent.ac.uk, Date: 09/17/2014 09:42 AM Subject: Re: [openstack-dev] [Keystone][Horizon] CORS and Federation Hi Adam Kristy has already added support to Horizon for federated login to Keystone. She will send you details of how she did this. One issue that arose was this: in order to give the user the list of IDPs/protocols that are trusted, the call to Keystone needs to be authenticated. But the user is not yet authenticated. So Horizon has to have its own credentials for logging into Keystone so that it can retrieve the list of IdPs for the user. This works, but it is not ideal. The situation is far worse for the Keystone command line client. The user is not logged in and the Keystone client does not have its own account on Keystone, so it cannot retrieve the list of IdPs for the user. The only way that Kristy could solve this, was to remove the requirement for authentication to the API that retrieves the list of IdPs. But this is not a standard solution as it requires modifying the core Keystone code. We need a fix to address this issue. My suggestion would be to make the API for retrieving the list of trusted IDPs publicly accessible, so that no credentials are needed for this. regards David On 16/09/2014 23:39, Adam Young wrote: Phase one for dealing with Federation can be done with CORS support solely for Keystone/Horizon integration: 1. Horizon Login page creates _javascript_ to do AJAX call to Keystone 2. Keystone generates a token 3. _javascript_ reads token out of response and sends it to Horizon. This should support Kerberos, X509, and Password auth; the Keystone team is discussing how to advertise mechanisms, lets leave the onus on us to solve that one and get back in a timely manner. For Federation, the handshake is a little more complex, and there might be a need for some sort of popup window for the user to log in to their home SAML provider. Its several more AJAX calls, but the end effect should be the same: get a standard Keystone token and hand it to Horizon. This would mean that Horizon would have to validate tokens the same way as any other endpoint. That should not be too hard, but there is a little bit of create a user, get a token, make a call logic that currently lives only in keystonemiddleware/auth_token; Its a solvable problem. This approach will support the straight _javascript_ approach that Richard Jones discussed; Keystone behind a proxy will work this way without CORS support. If CORS can be sorted out for the other services, we can do straight _javascript_ without the Proxy. I see it as phased approach with this being the first phase. ___ 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] [Keystone][Horizon] CORS and Federation
On 17.09.2014 15:45, Steve Martinelli wrote: ++ to your suggestion David, I think making the list of trusted IdPs publicly available makes sense. I think this might be useful in an academic/science world but on the other hand most cloud providers from the 'business' world might be very reluctant to expose list of their clients for free. cheers, Marek. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Keystone][Horizon] CORS and Federation
On 17/09/2014 14:55, Marek Denis wrote: On 17.09.2014 15:45, Steve Martinelli wrote: ++ to your suggestion David, I think making the list of trusted IdPs publicly available makes sense. I think this might be useful in an academic/science world but on the other hand most cloud providers from the 'business' world might be very reluctant to expose list of their clients for free. It is interesting that this latter comment came from the academic/science world, whereas the supportive one came from the business world :-) So maybe there could be a config parameter in keystone to determine which option is installed? regards David cheers, Marek. ___ 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] [Keystone][Horizon] CORS and Federation
Has Kristy's patch made it into Juno ? Tim -Original Message- From: David Chadwick [mailto:d.w.chadw...@kent.ac.uk] Sent: 17 September 2014 15:37 To: openstack-dev@lists.openstack.org; Kristy Siu Subject: Re: [openstack-dev] [Keystone][Horizon] CORS and Federation Hi Adam Kristy has already added support to Horizon for federated login to Keystone. She will send you details of how she did this. One issue that arose was this: in order to give the user the list of IDPs/protocols that are trusted, the call to Keystone needs to be authenticated. But the user is not yet authenticated. So Horizon has to have its own credentials for logging into Keystone so that it can retrieve the list of IdPs for the user. This works, but it is not ideal. The situation is far worse for the Keystone command line client. The user is not logged in and the Keystone client does not have its own account on Keystone, so it cannot retrieve the list of IdPs for the user. The only way that Kristy could solve this, was to remove the requirement for authentication to the API that retrieves the list of IdPs. But this is not a standard solution as it requires modifying the core Keystone code. We need a fix to address this issue. My suggestion would be to make the API for retrieving the list of trusted IDPs publicly accessible, so that no credentials are needed for this. regards David On 16/09/2014 23:39, Adam Young wrote: Phase one for dealing with Federation can be done with CORS support solely for Keystone/Horizon integration: 1. Horizon Login page creates Javascript to do AJAX call to Keystone 2. Keystone generates a token 3. Javascript reads token out of response and sends it to Horizon. This should support Kerberos, X509, and Password auth; the Keystone team is discussing how to advertise mechanisms, lets leave the onus on us to solve that one and get back in a timely manner. For Federation, the handshake is a little more complex, and there might be a need for some sort of popup window for the user to log in to their home SAML provider. Its several more AJAX calls, but the end effect should be the same: get a standard Keystone token and hand it to Horizon. This would mean that Horizon would have to validate tokens the same way as any other endpoint. That should not be too hard, but there is a little bit of create a user, get a token, make a call logic that currently lives only in keystonemiddleware/auth_token; Its a solvable problem. This approach will support the straight Javascript approach that Richard Jones discussed; Keystone behind a proxy will work this way without CORS support. If CORS can be sorted out for the other services, we can do straight Javascript without the Proxy. I see it as phased approach with this being the first phase. ___ 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] [Keystone][Horizon] CORS and Federation
On 09/17/2014 10:07 AM, David Chadwick wrote: On 17/09/2014 14:55, Marek Denis wrote: On 17.09.2014 15:45, Steve Martinelli wrote: ++ to your suggestion David, I think making the list of trusted IdPs publicly available makes sense. I think this might be useful in an academic/science world but on the other hand most cloud providers from the 'business' world might be very reluctant to expose list of their clients for free. It is interesting that this latter comment came from the academic/science world, whereas the supportive one came from the business world :-) So maybe there could be a config parameter in keystone to determine which option is installed? My thought was that there would be a public list, which is a subset of the overall list. For non-publicized IdPs, the end users would get an URL out of band and enter that in when prompted; if they enter an invalid URL, they would get an warning message. It wouldn't hide the fact that a customer was registered with a given cloud provider, but wouldn't advertise it, either. regards David cheers, Marek. ___ 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] [Keystone][Horizon] CORS and Federation
I had the same thought :) Config option or some documentation that outlines changes in policy.json. Either way, we should support both. David Chadwick d.w.chadw...@kent.ac.uk wrote on 09/17/2014 10:07:43 AM: From: David Chadwick d.w.chadw...@kent.ac.uk To: openstack-dev@lists.openstack.org, Date: 09/17/2014 10:10 AM Subject: Re: [openstack-dev] [Keystone][Horizon] CORS and Federation On 17/09/2014 14:55, Marek Denis wrote: On 17.09.2014 15:45, Steve Martinelli wrote: ++ to your suggestion David, I think making the list of trusted IdPs publicly available makes sense. I think this might be useful in an academic/science world but on the other hand most cloud providers from the 'business' world might be very reluctant to expose list of their clients for free. It is interesting that this latter comment came from the academic/science world, whereas the supportive one came from the business world :-) So maybe there could be a config parameter in keystone to determine which option is installed? regards David cheers, Marek. ___ 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] [Keystone][Horizon] CORS and Federation
this would work as well, but wouldn't it require two different API calls? On 17/09/2014 15:17, Adam Young wrote: On 09/17/2014 10:07 AM, David Chadwick wrote: On 17/09/2014 14:55, Marek Denis wrote: On 17.09.2014 15:45, Steve Martinelli wrote: ++ to your suggestion David, I think making the list of trusted IdPs publicly available makes sense. I think this might be useful in an academic/science world but on the other hand most cloud providers from the 'business' world might be very reluctant to expose list of their clients for free. It is interesting that this latter comment came from the academic/science world, whereas the supportive one came from the business world :-) So maybe there could be a config parameter in keystone to determine which option is installed? My thought was that there would be a public list, which is a subset of the overall list. For non-publicized IdPs, the end users would get an URL out of band and enter that in when prompted; if they enter an invalid URL, they would get an warning message. It wouldn't hide the fact that a customer was registered with a given cloud provider, but wouldn't advertise it, either. regards David cheers, Marek. ___ 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 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Keystone][Horizon] CORS and Federation
Hi Tim I don't believe she has pushed this through the official channel yet as we were very pushed for time to get something working for our GIANT CLASSe project. We only did the work in the latter half of August. I also don't know if we are too late for Juno or not. regards David On 17/09/2014 15:14, Tim Bell wrote: Has Kristy's patch made it into Juno ? Tim -Original Message- From: David Chadwick [mailto:d.w.chadw...@kent.ac.uk] Sent: 17 September 2014 15:37 To: openstack-dev@lists.openstack.org; Kristy Siu Subject: Re: [openstack-dev] [Keystone][Horizon] CORS and Federation Hi Adam Kristy has already added support to Horizon for federated login to Keystone. She will send you details of how she did this. One issue that arose was this: in order to give the user the list of IDPs/protocols that are trusted, the call to Keystone needs to be authenticated. But the user is not yet authenticated. So Horizon has to have its own credentials for logging into Keystone so that it can retrieve the list of IdPs for the user. This works, but it is not ideal. The situation is far worse for the Keystone command line client. The user is not logged in and the Keystone client does not have its own account on Keystone, so it cannot retrieve the list of IdPs for the user. The only way that Kristy could solve this, was to remove the requirement for authentication to the API that retrieves the list of IdPs. But this is not a standard solution as it requires modifying the core Keystone code. We need a fix to address this issue. My suggestion would be to make the API for retrieving the list of trusted IDPs publicly accessible, so that no credentials are needed for this. regards David On 16/09/2014 23:39, Adam Young wrote: Phase one for dealing with Federation can be done with CORS support solely for Keystone/Horizon integration: 1. Horizon Login page creates Javascript to do AJAX call to Keystone 2. Keystone generates a token 3. Javascript reads token out of response and sends it to Horizon. This should support Kerberos, X509, and Password auth; the Keystone team is discussing how to advertise mechanisms, lets leave the onus on us to solve that one and get back in a timely manner. For Federation, the handshake is a little more complex, and there might be a need for some sort of popup window for the user to log in to their home SAML provider. Its several more AJAX calls, but the end effect should be the same: get a standard Keystone token and hand it to Horizon. This would mean that Horizon would have to validate tokens the same way as any other endpoint. That should not be too hard, but there is a little bit of create a user, get a token, make a call logic that currently lives only in keystonemiddleware/auth_token; Its a solvable problem. This approach will support the straight Javascript approach that Richard Jones discussed; Keystone behind a proxy will work this way without CORS support. If CORS can be sorted out for the other services, we can do straight Javascript without the Proxy. I see it as phased approach with this being the first phase. ___ 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 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Keystone][Horizon] CORS and Federation
On 09/17/2014 10:14 AM, Tim Bell wrote: Has Kristy's patch made it into Juno ? I don't see any patches from Kristy in either the merged or pending review state for non-keystone projects; https://review.openstack.org/#/q/owner:%22Kristy+Siu%22,n,z So I'm guessing it is proof-of-concept code that has not been yet submitted. How do you propose going from Horizon to Keystone using SAML creds? Tim -Original Message- From: David Chadwick [mailto:d.w.chadw...@kent.ac.uk] Sent: 17 September 2014 15:37 To: openstack-dev@lists.openstack.org; Kristy Siu Subject: Re: [openstack-dev] [Keystone][Horizon] CORS and Federation Hi Adam Kristy has already added support to Horizon for federated login to Keystone. She will send you details of how she did this. One issue that arose was this: in order to give the user the list of IDPs/protocols that are trusted, the call to Keystone needs to be authenticated. But the user is not yet authenticated. So Horizon has to have its own credentials for logging into Keystone so that it can retrieve the list of IdPs for the user. This works, but it is not ideal. The situation is far worse for the Keystone command line client. The user is not logged in and the Keystone client does not have its own account on Keystone, so it cannot retrieve the list of IdPs for the user. The only way that Kristy could solve this, was to remove the requirement for authentication to the API that retrieves the list of IdPs. But this is not a standard solution as it requires modifying the core Keystone code. We need a fix to address this issue. My suggestion would be to make the API for retrieving the list of trusted IDPs publicly accessible, so that no credentials are needed for this. regards David On 16/09/2014 23:39, Adam Young wrote: Phase one for dealing with Federation can be done with CORS support solely for Keystone/Horizon integration: 1. Horizon Login page creates Javascript to do AJAX call to Keystone 2. Keystone generates a token 3. Javascript reads token out of response and sends it to Horizon. This should support Kerberos, X509, and Password auth; the Keystone team is discussing how to advertise mechanisms, lets leave the onus on us to solve that one and get back in a timely manner. For Federation, the handshake is a little more complex, and there might be a need for some sort of popup window for the user to log in to their home SAML provider. Its several more AJAX calls, but the end effect should be the same: get a standard Keystone token and hand it to Horizon. This would mean that Horizon would have to validate tokens the same way as any other endpoint. That should not be too hard, but there is a little bit of create a user, get a token, make a call logic that currently lives only in keystonemiddleware/auth_token; Its a solvable problem. This approach will support the straight Javascript approach that Richard Jones discussed; Keystone behind a proxy will work this way without CORS support. If CORS can be sorted out for the other services, we can do straight Javascript without the Proxy. I see it as phased approach with this being the first phase. ___ 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 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Keystone][Horizon] CORS and Federation
On 09/17/2014 10:35 AM, David Chadwick wrote:
this would work as well, but wouldn't it require two different API calls?
I think it would be 2 calls no matter what.
OK, lets talk this through:
1. Configure Horizon to return a generic login page, with a button that
says Or do Federated
2. Use clicks that button and gets the Federated UI. No new HTTP
request needed for this, still just static Javascript. Form has an edit
field for the user to enter the SAML IdP, anda button to fetch the list
of the public IdPs from Keystone.
3. Assume user clicks the list of public IdPs, those fill out a
drop-down box. If the user clicks on one, it populates the textbox with
the URL for the IdP.
3a. However, if the users IdP is not in the list, they go back to the
email they got from their IT guy that has Paste this URL into the IdP
edit box
4. User clicks OK.
Window pops up with the WebUI for the user to visit the SAML IdP URL.
This will be of the form
|
GET
htps://keystone/main/OS-FEDERATION/identity_providers/{identity_provider}/protocols/{protocol}/auth|
Which will perform the necessary redirects to get the user the SAML
assertion, and return it to Keystone.
5. Javascript picks up the Federated unscoped token from the response
at the end of step 4 and use that to get a scoped token.
6. Javascript submites the scoped token to Horizon and user is logged in.
Whew.
On 17/09/2014 15:17, Adam Young wrote:
On 09/17/2014 10:07 AM, David Chadwick wrote:
On 17/09/2014 14:55, Marek Denis wrote:
On 17.09.2014 15:45, Steve Martinelli wrote:
++ to your suggestion David, I think making the list of trusted IdPs
publicly available makes sense.
I think this might be useful in an academic/science world but on the
other hand most cloud providers from the 'business' world might be very
reluctant to expose list of their clients for free.
It is interesting that this latter comment came from the
academic/science world, whereas the supportive one came from the
business world :-)
So maybe there could be a config parameter in keystone to determine
which option is installed?
My thought was that there would be a public list, which is a subset of
the overall list.
For non-publicized IdPs, the end users would get an URL out of band and
enter that in when prompted; if they enter an invalid URL, they would
get an warning message.
It wouldn't hide the fact that a customer was registered with a given
cloud provider, but wouldn't advertise it, either.
regards
David
cheers,
Marek.
___
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
___
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] [Keystone][Horizon] CORS and Federation
On 17/09/2014 15:38, Adam Young wrote: On 09/17/2014 10:14 AM, Tim Bell wrote: Has Kristy's patch made it into Juno ? I don't see any patches from Kristy in either the merged or pending review state for non-keystone projects; https://review.openstack.org/#/q/owner:%22Kristy+Siu%22,n,z So I'm guessing it is proof-of-concept code that has not been yet submitted. That is correct How do you propose going from Horizon to Keystone using SAML creds? The flow is something like this Browser Horizon Keystone/Apache IDP -get login- --retrieve IDPs-- -list of IdPs -- -display login page- -Choose fed login- -redirect to Keystone- | -fed login request - remember address of Horizon --- SAML Authn request (redirect)--- | ---User logs in SAML Authn Response (redirect)-- | -- -redirect back to Horizon- | using remembered address -- The modification that Kristy had to make to Keystone was the last redirection request to Horizon had to be remembered when the initial request was received We would like to make our proof of concept code available to the Horizon experts for them to re-engineer/toughen to industry standards so that it can be released asap to the public. We have documentation that describes our release which you can download from here https://classe.sec.cs.kent.ac.uk/juno-server.pdf Note that a newer version will be uploaded very shortly as the above version contains partial VO documentation which will be stripped out until we can complete it later this month or next. regards David Tim -Original Message- From: David Chadwick [mailto:d.w.chadw...@kent.ac.uk] Sent: 17 September 2014 15:37 To: openstack-dev@lists.openstack.org; Kristy Siu Subject: Re: [openstack-dev] [Keystone][Horizon] CORS and Federation Hi Adam Kristy has already added support to Horizon for federated login to Keystone. She will send you details of how she did this. One issue that arose was this: in order to give the user the list of IDPs/protocols that are trusted, the call to Keystone needs to be authenticated. But the user is not yet authenticated. So Horizon has to have its own credentials for logging into Keystone so that it can retrieve the list of IdPs for the user. This works, but it is not ideal. The situation is far worse for the Keystone command line client. The user is not logged in and the Keystone client does not have its own account on Keystone, so it cannot retrieve the list of IdPs for the user. The only way that Kristy could solve this, was to remove the requirement for authentication to the API that retrieves the list of IdPs. But this is not a standard solution as it requires modifying the core Keystone code. We need a fix to address this issue. My suggestion would be to make the API for retrieving the list of trusted IDPs publicly accessible, so that no credentials are needed for this. regards David On 16/09/2014 23:39, Adam Young wrote: Phase one for dealing with Federation can be done with CORS support solely for Keystone/Horizon integration: 1. Horizon Login page creates Javascript to do AJAX call to Keystone 2. Keystone generates a token 3. Javascript reads token out of response and sends it to Horizon. This should support Kerberos, X509, and Password auth; the Keystone team is discussing how to advertise mechanisms, lets leave the onus on us to solve that one and get back in a timely manner. For Federation, the handshake is a little more complex, and there might be a need for some sort of popup window for the user to log in to their home SAML provider. Its several more AJAX calls, but the end effect should be the same: get a standard Keystone token and hand it to Horizon. This would mean that Horizon would have to validate tokens the same way as any other endpoint. That should not be too hard, but there is a little bit of create a user, get a token, make a call logic that currently lives only in keystonemiddleware/auth_token; Its a solvable problem. This approach will support the straight Javascript approach that Richard Jones discussed; Keystone behind a proxy will work this way without CORS support. If CORS can be sorted out for the other services, we can do straight Javascript without the Proxy. I see it as phased approach with this being the first phase. ___ 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] [Keystone][Horizon] CORS and Federation
Hi,
First of all, we should clarify whether your JS client wants to
implement ECP or WebSSO workflow. They are slightly different.
I feel JS is smart enough to implement the ECP flow and then and it
could simply implement what we already have in the keystoneclient [0].
This + some discovery service described by Adam would be required.
However, some problems may arise when it comes to ADFS support (we
needed separate plugin in keystoneclient) and other protocols which
should work by default from browsers.
[0]
https://github.com/openstack/python-keystoneclient/blob/master/keystoneclient/contrib/auth/v3/saml2.py#L29
Rest of the comments inlined.
On 17.09.2014 17:00, Adam Young wrote:
On 09/17/2014 10:35 AM, David Chadwick wrote:
this would work as well, but wouldn't it require two different API calls?
I think it would be 2 calls no matter what.
OK, lets talk this through:
1. Configure Horizon to return a generic login page, with a button that
says Or do Federated
2. Use clicks that button and gets the Federated UI. No new HTTP
request needed for this, still just static Javascript. Form has an edit
field for the user to enter the SAML IdP, anda button to fetch the list
of the public IdPs from Keystone.
3. Assume user clicks the list of public IdPs, those fill out a
drop-down box. If the user clicks on one, it populates the textbox with
the URL for the IdP.
3a. However, if the users IdP is not in the list, they go back to the
email they got from their IT guy that has Paste this URL into the IdP
edit box
Well, we don't keep any IdPs' URL in Keystone backend at the moment.
However, this can be easily fixed.
4. User clicks OK.
OK
Window pops up with the WebUI for the user to visit the SAML IdP URL.
This will be of the form
|
GET
htps://keystone/main/OS-FEDERATION/identity_providers/{identity_provider}/protocols/{protocol}/auth|
Which will perform the necessary redirects to get the user the SAML
assertion, and return it to Keystone.
Let's assume this step would work for now. I am interested how would the
SP-IDP-SP workflow look like from the JS perspective. In classic WebSSO,
where user uses only his browser:
1) Go to the protected resource
(/v3/OS-FEDERATION/identity_providers/{identity_provider}/protocols/{protocol}/auth
in our case)
2) (skipping the DS step for now) get redirected to the IdP
3) Authenticate with the IdP
4) Get redirected to the SP
5) Read your protected content, because you have been authenticated and
authorized to do so (get an unscoped, federated token issued by Keystone
in our case)
Now, I can imagine, if that's the websso approach can we somehow make JS
mimic the browser with all its blessing? So the user would actualy see
the real HTML website? If so, that would be enough to make it work.
5. Javascript picks up the Federated unscoped token from the response
at the end of step 4 and use that to get a scoped token.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Keystone][Horizon] CORS and Federation
Hi,
- Original Message -
From: Adam Young ayo...@redhat.com
To: openstack-dev@lists.openstack.org
Sent: Wednesday, September 17, 2014 5:00:16 PM
Subject: Re: [openstack-dev] [Keystone][Horizon] CORS and Federation
On 09/17/2014 10:35 AM, David Chadwick wrote:
this would work as well, but wouldn't it require two different API calls?
I think it would be 2 calls no matter what.
OK, lets talk this through:
1. Configure Horizon to return a generic login page, with a button that says
Or do Federated
2. Use clicks that button and gets the Federated UI. No new HTTP request
needed for this, still just static Javascript. Form has an edit field for
the user to enter the SAML IdP, anda button to fetch the list of the public
IdPs from Keystone.
3. Assume user clicks the list of public IdPs, those fill out a drop-down
box. If the user clicks on one, it populates the textbox with the URL for
the IdP.
3a. However, if the users IdP is not in the list, they go back to the email
they got from their IT guy that has Paste this URL into the IdP edit box
4. User clicks OK.
Window pops up with the WebUI for the user to visit the SAML IdP URL. This
will be of the form
GET
htps://keystone/main/OS-FEDERATION/identity_providers/{identity_provider}/protocols/{protocol}/auth
Which will perform the necessary redirects to get the user the SAML
assertion, and return it to Keystone.
5. Javascript picks up the Federated unscoped token from the response at the
end of step 4 and use that to get a scoped token.
I think the jump to step 6 isn't unnecessary: logging in Horizon requires only
a username and a password,
unless I am wrong scoping is done afterwards by selecting a project in a list.
Besides, should we expect
a federated user to necessarily know beforehand to which domain/project she was
mapped ?
6. Javascript submites the scoped token to Horizon and user is logged in.
Horizon will also need to keep track of the fact that a federated auth was used:
* to list projects and domains available to the user
* to scope the unscoped saml token
As these are done through the federation API rather than the usual one.
Whew.
Whew indeed !
On 17/09/2014 15:17, Adam Young wrote:
On 09/17/2014 10:07 AM, David Chadwick wrote:
On 17/09/2014 14:55, Marek Denis wrote:
On 17.09.2014 15:45, Steve Martinelli wrote:
++ to your suggestion David, I think making the list of trusted IdPs
publicly available makes sense.
I think this might be useful in an academic/science world but on the
other hand most cloud providers from the 'business' world might be very
reluctant to expose list of their clients for free.
It is interesting that this latter comment came from the
academic/science world, whereas the supportive one came from the
business world :-)
So maybe there could be a config parameter in keystone to determine
which option is installed?
My thought was that there would be a public list, which is a subset of
the overall list.
For non-publicized IdPs, the end users would get an URL out of band and
enter that in when prompted; if they enter an invalid URL, they would
get an warning message.
It wouldn't hide the fact that a customer was registered with a given
cloud provider, but wouldn't advertise it, either.
regards
David
cheers,
Marek.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Keystone][Horizon] CORS and Federation
Hi all, The code for my proof of concept software is at https://github.com/kwss/horizon/tree/federated (templates) And https://github.com/kwss/django_openstack_auth/tree/federated (federation handling). Please note that the horizon branch also contains some additional panels for managing IdPs and mappings. Regards, Kristy On 17 Sep 2014, at 16:34, David Chadwick d.w.chadw...@kent.ac.uk wrote: On 17/09/2014 15:38, Adam Young wrote: On 09/17/2014 10:14 AM, Tim Bell wrote: Has Kristy's patch made it into Juno ? I don't see any patches from Kristy in either the merged or pending review state for non-keystone projects; https://review.openstack.org/#/q/owner:%22Kristy+Siu%22,n,z So I'm guessing it is proof-of-concept code that has not been yet submitted. That is correct How do you propose going from Horizon to Keystone using SAML creds? The flow is something like this Browser Horizon Keystone/Apache IDP -get login- --retrieve IDPs-- -list of IdPs -- -display login page- -Choose fed login- -redirect to Keystone- | -fed login request - remember address of Horizon --- SAML Authn request (redirect)--- | ---User logs in SAML Authn Response (redirect)-- | -- -redirect back to Horizon- | using remembered address -- The modification that Kristy had to make to Keystone was the last redirection request to Horizon had to be remembered when the initial request was received We would like to make our proof of concept code available to the Horizon experts for them to re-engineer/toughen to industry standards so that it can be released asap to the public. We have documentation that describes our release which you can download from here https://classe.sec.cs.kent.ac.uk/juno-server.pdf Note that a newer version will be uploaded very shortly as the above version contains partial VO documentation which will be stripped out until we can complete it later this month or next. regards David Tim -Original Message- From: David Chadwick [mailto:d.w.chadw...@kent.ac.uk] Sent: 17 September 2014 15:37 To: openstack-dev@lists.openstack.org; Kristy Siu Subject: Re: [openstack-dev] [Keystone][Horizon] CORS and Federation Hi Adam Kristy has already added support to Horizon for federated login to Keystone. She will send you details of how she did this. One issue that arose was this: in order to give the user the list of IDPs/protocols that are trusted, the call to Keystone needs to be authenticated. But the user is not yet authenticated. So Horizon has to have its own credentials for logging into Keystone so that it can retrieve the list of IdPs for the user. This works, but it is not ideal. The situation is far worse for the Keystone command line client. The user is not logged in and the Keystone client does not have its own account on Keystone, so it cannot retrieve the list of IdPs for the user. The only way that Kristy could solve this, was to remove the requirement for authentication to the API that retrieves the list of IdPs. But this is not a standard solution as it requires modifying the core Keystone code. We need a fix to address this issue. My suggestion would be to make the API for retrieving the list of trusted IDPs publicly accessible, so that no credentials are needed for this. regards David On 16/09/2014 23:39, Adam Young wrote: Phase one for dealing with Federation can be done with CORS support solely for Keystone/Horizon integration: 1. Horizon Login page creates Javascript to do AJAX call to Keystone 2. Keystone generates a token 3. Javascript reads token out of response and sends it to Horizon. This should support Kerberos, X509, and Password auth; the Keystone team is discussing how to advertise mechanisms, lets leave the onus on us to solve that one and get back in a timely manner. For Federation, the handshake is a little more complex, and there might be a need for some sort of popup window for the user to log in to their home SAML provider. Its several more AJAX calls, but the end effect should be the same: get a standard Keystone token and hand it to Horizon. This would mean that Horizon would have to validate tokens the same way as any other endpoint. That should not be too hard, but there is a little bit of create a user, get a token, make a call logic that currently lives only in keystonemiddleware/auth_token; Its a solvable problem. This approach will support the straight Javascript approach that Richard Jones discussed; Keystone behind a proxy will work this way without CORS support. If CORS can be sorted out for the other services, we can do straight
Re: [openstack-dev] [Keystone][Horizon] CORS and Federation
On 17/09/2014 16:53, Marek Denis wrote:
Hi,
First of all, we should clarify whether your JS client wants to
implement ECP or WebSSO workflow. They are slightly different.
Our modification to Horizon uses WebSSO since this is the obvious
profile for a browser to use as it can handle redirects automatically.
Your modification for Keystone client uses ECP which is the obvious one
for this to use, as redirects are not required.
However, we also have a mod for Keystone client which uses WebSSO, in
case this is all the keystone server supports
regards
David
I feel JS is smart enough to implement the ECP flow and then and it
could simply implement what we already have in the keystoneclient [0].
This + some discovery service described by Adam would be required.
However, some problems may arise when it comes to ADFS support (we
needed separate plugin in keystoneclient) and other protocols which
should work by default from browsers.
[0]
https://github.com/openstack/python-keystoneclient/blob/master/keystoneclient/contrib/auth/v3/saml2.py#L29
Rest of the comments inlined.
On 17.09.2014 17:00, Adam Young wrote:
On 09/17/2014 10:35 AM, David Chadwick wrote:
this would work as well, but wouldn't it require two different API
calls?
I think it would be 2 calls no matter what.
OK, lets talk this through:
1. Configure Horizon to return a generic login page, with a button that
says Or do Federated
2. Use clicks that button and gets the Federated UI. No new HTTP
request needed for this, still just static Javascript. Form has an edit
field for the user to enter the SAML IdP, anda button to fetch the list
of the public IdPs from Keystone.
3. Assume user clicks the list of public IdPs, those fill out a
drop-down box. If the user clicks on one, it populates the textbox with
the URL for the IdP.
3a. However, if the users IdP is not in the list, they go back to the
email they got from their IT guy that has Paste this URL into the IdP
edit box
Well, we don't keep any IdPs' URL in Keystone backend at the moment.
However, this can be easily fixed.
4. User clicks OK.
OK
Window pops up with the WebUI for the user to visit the SAML IdP URL.
This will be of the form
|
GET
htps://keystone/main/OS-FEDERATION/identity_providers/{identity_provider}/protocols/{protocol}/auth|
Which will perform the necessary redirects to get the user the SAML
assertion, and return it to Keystone.
Let's assume this step would work for now. I am interested how would the
SP-IDP-SP workflow look like from the JS perspective. In classic WebSSO,
where user uses only his browser:
1) Go to the protected resource
(/v3/OS-FEDERATION/identity_providers/{identity_provider}/protocols/{protocol}/auth
in our case)
2) (skipping the DS step for now) get redirected to the IdP
3) Authenticate with the IdP
4) Get redirected to the SP
5) Read your protected content, because you have been authenticated and
authorized to do so (get an unscoped, federated token issued by Keystone
in our case)
Now, I can imagine, if that's the websso approach can we somehow make JS
mimic the browser with all its blessing? So the user would actualy see
the real HTML website? If so, that would be enough to make it work.
5. Javascript picks up the Federated unscoped token from the response
at the end of step 4 and use that to get a scoped token.
___
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] [Keystone][Horizon] CORS and Federation
This is generally the right plan. The hard parts are in getting people to deploy it correctly and securely, and handling fallback cases for lack of browser support, etc. What we really don't want to do is to encourage people to set Access-Control-Allow-Origin: * type headers or other such nonsense simply because it's too much work to do things correctly. This becomes especially challenging for federated clouds. I would encourage looking at the problem of adding all the necessary headers for CORS as an OpenStack-wide issue. Once you figure it out for Keystone, the next logical step is to want to make calls from the browser directly to all the other service endpoints, and each service is going to have to respond with the correct CORS headers (Access-Control-Allow-Methods and Access-Control-Allow-Headers are particularly fun ones for projects like Glance or Swift). A common middleware and means of configuring it will go a long way to easing user pain and spurring adoption of the new mechanisms. It will help the Horizon team substantially in the long run to do it consistently and predictably across the stack. As a side-note, once we're in the realm of handling all this sensitive data with the browser as a middleman, encouraging people to configure things like CSP is probably also a good idea to make sure we're not loading malicious scripts or other resources. Securing a browser-centric world is a tricky realm... let's make sure we get it right. :-) - Gabriel -Original Message- From: Adam Young [mailto:ayo...@redhat.com] Sent: Tuesday, September 16, 2014 3:40 PM To: OpenStack Development Mailing List Subject: [openstack-dev] [Keystone][Horizon] CORS and Federation Phase one for dealing with Federation can be done with CORS support solely for Keystone/Horizon integration: 1. Horizon Login page creates Javascript to do AJAX call to Keystone 2. Keystone generates a token 3. Javascript reads token out of response and sends it to Horizon. This should support Kerberos, X509, and Password auth; the Keystone team is discussing how to advertise mechanisms, lets leave the onus on us to solve that one and get back in a timely manner. For Federation, the handshake is a little more complex, and there might be a need for some sort of popup window for the user to log in to their home SAML provider. Its several more AJAX calls, but the end effect should be the same: get a standard Keystone token and hand it to Horizon. This would mean that Horizon would have to validate tokens the same way as any other endpoint. That should not be too hard, but there is a little bit of create a user, get a token, make a call logic that currently lives only in keystonemiddleware/auth_token; Its a solvable problem. This approach will support the straight Javascript approach that Richard Jones discussed; Keystone behind a proxy will work this way without CORS support. If CORS can be sorted out for the other services, we can do straight Javascript without the Proxy. I see it as phased approach with this being the first phase. ___ 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] [Keystone][Horizon] CORS and Federation
On 09/16/2014 06:59 PM, Gabriel Hurley wrote: This is generally the right plan. The hard parts are in getting people to deploy it correctly and securely, and handling fallback cases for lack of browser support, etc. Do we really care about Browser support? I mean, are we really going to have to support non-Javascript capable browsers for Horizon? Are there any Browsers with sufficient quality of Javascript support that don't also have CORS support? What we really don't want to do is to encourage people to set Access-Control-Allow-Origin: * type headers or other such nonsense simply because it's too much work to do things correctly. This becomes especially challenging for federated clouds. I was thinking we would have two common approaches: 1. User the service catalog. It implies adding Horizon to the Service catalog, but then we know each endpoint, and we can limit CORS to other official endpoints. This is my preferred approach. 2. Have a DNS Zone for the openstack deployment. So, the Access-Control-Allow-Origin: *.openstack.example.com I would encourage looking at the problem of adding all the necessary headers for CORS as an OpenStack-wide issue. Once you figure it out for Keystone, the next logical step is to want to make calls from the browser directly to all the other service endpoints, and each service is going to have to respond with the correct CORS headers (Access-Control-Allow-Methods and Access-Control-Allow-Headers are particularly fun ones for projects like Glance or Swift). A common middleware and means of configuring it will go a long way to easing user pain and spurring adoption of the new mechanisms. It will help the Horizon team substantially in the long run to do it consistently and predictably across the stack. As a side-note, once we're in the realm of handling all this sensitive data with the browser as a middleman, encouraging people to configure things like CSP is probably also a good idea to make sure we're not loading malicious scripts or other resources. Yes. I think this is an obvious cross-project track session for the Summit. Securing a browser-centric world is a tricky realm... let's make sure we get it right. :-) Agreed. I think this is one topic that will benefit from serious upfront effort. - Gabriel -Original Message- From: Adam Young [mailto:ayo...@redhat.com] Sent: Tuesday, September 16, 2014 3:40 PM To: OpenStack Development Mailing List Subject: [openstack-dev] [Keystone][Horizon] CORS and Federation Phase one for dealing with Federation can be done with CORS support solely for Keystone/Horizon integration: 1. Horizon Login page creates Javascript to do AJAX call to Keystone 2. Keystone generates a token 3. Javascript reads token out of response and sends it to Horizon. This should support Kerberos, X509, and Password auth; the Keystone team is discussing how to advertise mechanisms, lets leave the onus on us to solve that one and get back in a timely manner. For Federation, the handshake is a little more complex, and there might be a need for some sort of popup window for the user to log in to their home SAML provider. Its several more AJAX calls, but the end effect should be the same: get a standard Keystone token and hand it to Horizon. This would mean that Horizon would have to validate tokens the same way as any other endpoint. That should not be too hard, but there is a little bit of create a user, get a token, make a call logic that currently lives only in keystonemiddleware/auth_token; Its a solvable problem. This approach will support the straight Javascript approach that Richard Jones discussed; Keystone behind a proxy will work this way without CORS support. If CORS can be sorted out for the other services, we can do straight Javascript without the Proxy. I see it as phased approach with this being the first phase. ___ 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] [Keystone][Horizon] CORS and Federation
On 09/16/2014 08:56 PM, Richard Jones wrote: CORS for all of OpenStack is possible once the oslo middleware lands*, but as you note it's only one of many elements to be considered when exposing the APIs to browsers. There is no current support for CSRF protection in the OpenStack APIs, for example. I believe that sort of functionality belongs in an intermediary between the APIs and the browser. Typically, CSRF is done by writing a customer header. Why wouldn't the -X-Auth-Token header qualify? Its not a cookie, automatically added. So, CORS support would be necesary for horizon to send the token on a request to Nova, but no other site would be able to do that. No? Richard * https://review.openstack.org/#/c/120964/ On 17 September 2014 08:59, Gabriel Hurley gabriel.hur...@nebula.com mailto:gabriel.hur...@nebula.com wrote: This is generally the right plan. The hard parts are in getting people to deploy it correctly and securely, and handling fallback cases for lack of browser support, etc. What we really don't want to do is to encourage people to set Access-Control-Allow-Origin: * type headers or other such nonsense simply because it's too much work to do things correctly. This becomes especially challenging for federated clouds. I would encourage looking at the problem of adding all the necessary headers for CORS as an OpenStack-wide issue. Once you figure it out for Keystone, the next logical step is to want to make calls from the browser directly to all the other service endpoints, and each service is going to have to respond with the correct CORS headers (Access-Control-Allow-Methods and Access-Control-Allow-Headers are particularly fun ones for projects like Glance or Swift). A common middleware and means of configuring it will go a long way to easing user pain and spurring adoption of the new mechanisms. It will help the Horizon team substantially in the long run to do it consistently and predictably across the stack. As a side-note, once we're in the realm of handling all this sensitive data with the browser as a middleman, encouraging people to configure things like CSP is probably also a good idea to make sure we're not loading malicious scripts or other resources. Securing a browser-centric world is a tricky realm... let's make sure we get it right. :-) - Gabriel -Original Message- From: Adam Young [mailto:ayo...@redhat.com mailto:ayo...@redhat.com] Sent: Tuesday, September 16, 2014 3:40 PM To: OpenStack Development Mailing List Subject: [openstack-dev] [Keystone][Horizon] CORS and Federation Phase one for dealing with Federation can be done with CORS support solely for Keystone/Horizon integration: 1. Horizon Login page creates Javascript to do AJAX call to Keystone 2. Keystone generates a token 3. Javascript reads token out of response and sends it to Horizon. This should support Kerberos, X509, and Password auth; the Keystone team is discussing how to advertise mechanisms, lets leave the onus on us to solve that one and get back in a timely manner. For Federation, the handshake is a little more complex, and there might be a need for some sort of popup window for the user to log in to their home SAML provider. Its several more AJAX calls, but the end effect should be the same: get a standard Keystone token and hand it to Horizon. This would mean that Horizon would have to validate tokens the same way as any other endpoint. That should not be too hard, but there is a little bit of create a user, get a token, make a call logic that currently lives only in keystonemiddleware/auth_token; Its a solvable problem. This approach will support the straight Javascript approach that Richard Jones discussed; Keystone behind a proxy will work this way without CORS support. If CORS can be sorted out for the other services, we can do straight Javascript without the Proxy. I see it as phased approach with this being the first phase. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org mailto:OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org mailto: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
