settingsLogin | Registersettings

[openstack-dev] [Keystone][Horizon] CORS and Federation

0 votes

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.

asked Sep 16, 2014 in openstack-dev by Adam_Young (19,940 points)   2 7 9
retagged Jan 28, 2015 by admin

33 Responses

0 votes

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:ayoung at 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 at lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Sep 16, 2014 by Gabriel_Hurley (860 points)   1
0 votes

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.

Richard

On 17 September 2014 08:59, Gabriel Hurley <Gabriel.Hurley at 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:ayoung at 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 at lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


OpenStack-dev mailing list
OpenStack-dev at lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL:

responded Sep 17, 2014 by Richard_Jones (6,400 points)   2 4 5
0 votes

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:ayoung at 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 at lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

OpenStack-dev mailing list
OpenStack-dev at lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Sep 17, 2014 by Adam_Young (19,940 points)   2 7 9
0 votes

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

On 17 September 2014 08:59, Gabriel Hurley <Gabriel.Hurley at nebula.com
<mailto:Gabriel.Hurley at 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:ayoung at redhat.com
<mailto:ayoung at 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 at lists.openstack.org
<mailto:OpenStack-dev at lists.openstack.org>
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

_______________________________________________
OpenStack-dev mailing list
OpenStack-dev at lists.openstack.org
<mailto:OpenStack-dev at lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


OpenStack-dev mailing list
OpenStack-dev at lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL:

responded Sep 17, 2014 by Adam_Young (19,940 points)   2 7 9
0 votes

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 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

On 17 September 2014 08:59, Gabriel Hurley <Gabriel.Hurley at 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:ayoung at 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 at lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


OpenStack-dev mailing list
OpenStack-dev at lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


OpenStack-dev mailing listOpenStack-dev at lists.openstack.orghttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


OpenStack-dev mailing list
OpenStack-dev at lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL:

responded Sep 17, 2014 by Richard_Jones (6,400 points)   2 4 5
0 votes

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 at lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Sep 17, 2014 by David_Chadwick (3,360 points)   3 3
0 votes

An HTML attachment was scrubbed...
URL:

responded Sep 17, 2014 by Steve_Martinelli (6,500 points)   1 3 4
0 votes

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.

responded Sep 17, 2014 by Marek_Denis (940 points)   1 3
0 votes

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 at lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Sep 17, 2014 by David_Chadwick (3,360 points)   3 3
0 votes

Has Kristy's patch made it into Juno ?

Tim

-----Original Message-----
From: David Chadwick [mailto:d.w.chadwick at kent.ac.uk]
Sent: 17 September 2014 15:37
To: openstack-dev at 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 at lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


OpenStack-dev mailing list
OpenStack-dev at lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Sep 17, 2014 by Tim_Bell (16,440 points)   1 5 10
...