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
On 09/17/2014 11:56 AM, Matthieu Huin wrote:
Hi,
- Original Message -
From: "Adam Young"
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
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
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
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" 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
Re: [openstack-dev] [Keystone][Horizon] CORS and Federation
Hi,
- Original Message -
> From: "Adam Young"
> 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,
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
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
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 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
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
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
I had the same thought :) Config option or some documentation that outlines changes in policy.json. Either way, we should support both. David Chadwick wrote on 09/17/2014 10:07:43 AM: > From: David Chadwick > 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
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
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 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
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
++ to your suggestion David, I think making the list of trusted IdPs publicly available makes sense. - Steve David Chadwick wrote on 09/17/2014 09:37:21 AM: > From: David Chadwick > To: openstack-dev@lists.openstack.org, Kristy Siu , > 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
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
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
>
> * https://review.openstack.org/#/c/120964/
>
> On 17 September 2014 08:59, 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.
>>
>> 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 service
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 <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.openst
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
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
* https://review.openstack.org/#/c/120964/
On 17 September 2014 08:59, 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.
>
> 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 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
[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
