[openstack-dev] [horizon] [keystone] [requirements] [rpm-packaging] [deb-packaging] Merging Django OpenStack Auth with Horizon

[Rob Cresswell]

Apologies in advance for so many tags, hoping this is seen by the appropriate 
people.

I've put up a patch to merge Django OpenStack Auth (DOA) into the Horizon tree: 
https://review.openstack.org/#/c/482561/ There is a blueprint to track any 
further changes / issues here: 
https://blueprints.launchpad.net/horizon/+spec/merge-openstack-auth

This has been suggested for quite a while, but we've only recently got round to 
it. Historically, the design was supposed to allow for multiple auth plugins 
(years ago, we also had Django OpenStack Auth Kerberos).

However, it's currently highly coupled with Horizon (its sole consumer, as far 
as I know) and the separation seems increasingly arbitrary. Almost all new 
features to Keystone / auth support require changes to both repos (with an 
intermerdiary release of DOA) and it causes a good deal of confusion when 
people try and debug issues too. Merging the two would reduce release and 
packaging work, reduce translation overhead, reduce debugging time and cut down 
on review time needed to make changes that affect auth.

I'd like to see if there are any thoughts or concerns from the wider community.

Thanks,
Rob
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [horizon] [keystone] [federated auth] [ocata] federated users with "admin" role not authorized for nova, cinder, neutron admin panels

[Boris Bobrov]

Hi,

Oh wow, for some reason my message was not sent to the list.

On 03/20/2017 09:03 PM, Evan Bollig PhD wrote:
> Hey Boris,
> 
> Any updates on this?
> 
> Cheers,
> -E
> --
> Evan F. Bollig, PhD
> Scientific Computing Consultant, Application Developer | Scientific
> Computing Solutions (SCS)
> Minnesota Supercomputing Institute | msi.umn.edu
> University of Minnesota | umn.edu
> boll0...@umn.edu | 612-624-1447 | Walter Lib Rm 556
> 
> 
> On Thu, Mar 9, 2017 at 4:08 PM, Evan Bollig PhD  wrote:
>> Hey Boris,
>>
>> Which mapping? Hope you were looking for the shibboleth user
>> mapping. Also, hope this is the right way to share the paste (first
>> time using this):
>> http://paste.openstack.org/show/3snCb31GRZfAuQxdRouy/

This is probably part of bug
https://bugs.launchpad.net/keystone/+bug/1589993 . I am not 100% sure
though. Could you please file new bugreport?

As for now, you could try doing auto-provisioning using new capabilities
from Ocata:
https://docs.openstack.org/developer/keystone/federation/mapping_combinations.html#auto-provisioning

>> Cheers,
>> -E
>> --
>> Evan F. Bollig, PhD
>> Scientific Computing Consultant, Application Developer | Scientific
>> Computing Solutions (SCS)
>> Minnesota Supercomputing Institute | msi.umn.edu
>> University of Minnesota | umn.edu
>> boll0...@umn.edu | 612-624-1447 | Walter Lib Rm 556
>>
>>
>> On Thu, Mar 9, 2017 at 7:50 AM, Boris Bobrov  wrote:
>>> Hi,
>>>
>>> Please paste your mapping to paste.openstack.org
>>>
>>> On 03/09/2017 02:07 AM, Evan Bollig PhD wrote:
 I am on Ocata with Shibboleth auth enabled. I noticed that Federated
 users with the admin role no longer have authorization to use the
 Admin** panels in Horizon related to Nova, Cinder and Neutron. All
 regular Identity and Project tabs function, and there are no problems
 with authorization for local admin users.

 -
 These Admin tabs work: Hypervisors, Host Aggregates, Flavors, Images,
 Defaults, Metadata, System Information

 These result in logout: Instances, Volumes, Networks, Routers, Floating IPs

 This is not present: Overview
 -

 The policies are vanilla from the CentOS/RDO openstack-dashboard RPMs:
 openstack-dashboard-11.0.0-1.el7.noarch
 python-django-horizon-11.0.0-1.el7.noarch
 python2-keystonemiddleware-4.14.0-1.el7.noarch
 python2-keystoneclient-3.10.0-1.el7.noarch
 openstack-keystone-11.0.0-1.el7.noarch
 python2-keystoneauth1-2.18.0-1.el7.noarch
 python-keystone-11.0.0-1.el7.noarch

 The errors I see in logs are similar to:

 ==> /var/log/horizon/horizon.log <==
 2017-03-07 18:24:54,961 13745 ERROR horizon.exceptions Unauthorized:
 Traceback (most recent call last):
   File 
 "/usr/share/openstack-dashboard/openstack_dashboard/dashboards/admin/floating_ips/views.py",
 line 53, in get_tenant_list
 tenants, has_more = api.keystone.tenant_list(request)
   File 
 "/usr/share/openstack-dashboard/openstack_dashboard/api/keystone.py",
 line 351, in tenant_list
 manager = VERSIONS.get_project_manager(request, admin=admin)
   File 
 "/usr/share/openstack-dashboard/openstack_dashboard/api/keystone.py",
 line 61, in get_project_manager
 manager = keystoneclient(*args, **kwargs).projects
   File 
 "/usr/share/openstack-dashboard/openstack_dashboard/api/keystone.py",
 line 170, in keystoneclient
 raise exceptions.NotAuthorized
 NotAuthorized

 Cheers,
 -E
 --
 Evan F. Bollig, PhD
 Scientific Computing Consultant, Application Developer | Scientific
 Computing Solutions (SCS)
 Minnesota Supercomputing Institute | msi.umn.edu
 University of Minnesota | umn.edu
 boll0...@umn.edu | 612-624-1447 | Walter Lib Rm 556

 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

>>>
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [horizon] [keystone] [federated auth] [ocata] federated users with "admin" role not authorized for nova, cinder, neutron admin panels

[Boris Bobrov]

Hi,

Oh wow, for some reason my message was not sent to the list.

On 03/20/2017 09:03 PM, Evan Bollig PhD wrote:
> Hey Boris,
> 
> Any updates on this?
> 
> Cheers,
> -E
> --
> Evan F. Bollig, PhD
> Scientific Computing Consultant, Application Developer | Scientific
> Computing Solutions (SCS)
> Minnesota Supercomputing Institute | msi.umn.edu
> University of Minnesota | umn.edu
> boll0...@umn.edu | 612-624-1447 | Walter Lib Rm 556
> 
> 
> On Thu, Mar 9, 2017 at 4:08 PM, Evan Bollig PhD  wrote:
>> Hey Boris,
>>
>> Which mapping? Hope you were looking for the shibboleth user
>> mapping. Also, hope this is the right way to share the paste (first
>> time using this):
>> http://paste.openstack.org/show/3snCb31GRZfAuQxdRouy/

This is probably part of bug
https://bugs.launchpad.net/keystone/+bug/1589993 . I am not 100% sure
though. Could you please file new bugreport?

As for now, you could try doing auto-provisioning using new capabilities
from Ocata:
https://docs.openstack.org/developer/keystone/federation/mapping_combinations.html#auto-provisioning

>> Cheers,
>> -E
>> --
>> Evan F. Bollig, PhD
>> Scientific Computing Consultant, Application Developer | Scientific
>> Computing Solutions (SCS)
>> Minnesota Supercomputing Institute | msi.umn.edu
>> University of Minnesota | umn.edu
>> boll0...@umn.edu | 612-624-1447 | Walter Lib Rm 556
>>
>>
>> On Thu, Mar 9, 2017 at 7:50 AM, Boris Bobrov  wrote:
>>> Hi,
>>>
>>> Please paste your mapping to paste.openstack.org
>>>
>>> On 03/09/2017 02:07 AM, Evan Bollig PhD wrote:
 I am on Ocata with Shibboleth auth enabled. I noticed that Federated
 users with the admin role no longer have authorization to use the
 Admin** panels in Horizon related to Nova, Cinder and Neutron. All
 regular Identity and Project tabs function, and there are no problems
 with authorization for local admin users.

 -
 These Admin tabs work: Hypervisors, Host Aggregates, Flavors, Images,
 Defaults, Metadata, System Information

 These result in logout: Instances, Volumes, Networks, Routers, Floating IPs

 This is not present: Overview
 -

 The policies are vanilla from the CentOS/RDO openstack-dashboard RPMs:
 openstack-dashboard-11.0.0-1.el7.noarch
 python-django-horizon-11.0.0-1.el7.noarch
 python2-keystonemiddleware-4.14.0-1.el7.noarch
 python2-keystoneclient-3.10.0-1.el7.noarch
 openstack-keystone-11.0.0-1.el7.noarch
 python2-keystoneauth1-2.18.0-1.el7.noarch
 python-keystone-11.0.0-1.el7.noarch

 The errors I see in logs are similar to:

 ==> /var/log/horizon/horizon.log <==
 2017-03-07 18:24:54,961 13745 ERROR horizon.exceptions Unauthorized:
 Traceback (most recent call last):
   File 
 "/usr/share/openstack-dashboard/openstack_dashboard/dashboards/admin/floating_ips/views.py",
 line 53, in get_tenant_list
 tenants, has_more = api.keystone.tenant_list(request)
   File 
 "/usr/share/openstack-dashboard/openstack_dashboard/api/keystone.py",
 line 351, in tenant_list
 manager = VERSIONS.get_project_manager(request, admin=admin)
   File 
 "/usr/share/openstack-dashboard/openstack_dashboard/api/keystone.py",
 line 61, in get_project_manager
 manager = keystoneclient(*args, **kwargs).projects
   File 
 "/usr/share/openstack-dashboard/openstack_dashboard/api/keystone.py",
 line 170, in keystoneclient
 raise exceptions.NotAuthorized
 NotAuthorized

 Cheers,
 -E
 --
 Evan F. Bollig, PhD
 Scientific Computing Consultant, Application Developer | Scientific
 Computing Solutions (SCS)
 Minnesota Supercomputing Institute | msi.umn.edu
 University of Minnesota | umn.edu
 boll0...@umn.edu | 612-624-1447 | Walter Lib Rm 556

 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

>>>
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [horizon] [keystone] [federated auth] [ocata] federated users with "admin" role not authorized for nova, cinder, neutron admin panels

[Evan Bollig PhD]

Hey Boris,

Any updates on this?

Cheers,
-E
--
Evan F. Bollig, PhD
Scientific Computing Consultant, Application Developer | Scientific
Computing Solutions (SCS)
Minnesota Supercomputing Institute | msi.umn.edu
University of Minnesota | umn.edu
boll0...@umn.edu | 612-624-1447 | Walter Lib Rm 556


On Thu, Mar 9, 2017 at 4:08 PM, Evan Bollig PhD  wrote:
> Hey Boris,
>
> Which mapping? Hope you were looking for the shibboleth user
> mapping. Also, hope this is the right way to share the paste (first
> time using this):
> http://paste.openstack.org/show/3snCb31GRZfAuQxdRouy/
>
> Cheers,
> -E
> --
> Evan F. Bollig, PhD
> Scientific Computing Consultant, Application Developer | Scientific
> Computing Solutions (SCS)
> Minnesota Supercomputing Institute | msi.umn.edu
> University of Minnesota | umn.edu
> boll0...@umn.edu | 612-624-1447 | Walter Lib Rm 556
>
>
> On Thu, Mar 9, 2017 at 7:50 AM, Boris Bobrov  wrote:
>> Hi,
>>
>> Please paste your mapping to paste.openstack.org
>>
>> On 03/09/2017 02:07 AM, Evan Bollig PhD wrote:
>>> I am on Ocata with Shibboleth auth enabled. I noticed that Federated
>>> users with the admin role no longer have authorization to use the
>>> Admin** panels in Horizon related to Nova, Cinder and Neutron. All
>>> regular Identity and Project tabs function, and there are no problems
>>> with authorization for local admin users.
>>>
>>> -
>>> These Admin tabs work: Hypervisors, Host Aggregates, Flavors, Images,
>>> Defaults, Metadata, System Information
>>>
>>> These result in logout: Instances, Volumes, Networks, Routers, Floating IPs
>>>
>>> This is not present: Overview
>>> -
>>>
>>> The policies are vanilla from the CentOS/RDO openstack-dashboard RPMs:
>>> openstack-dashboard-11.0.0-1.el7.noarch
>>> python-django-horizon-11.0.0-1.el7.noarch
>>> python2-keystonemiddleware-4.14.0-1.el7.noarch
>>> python2-keystoneclient-3.10.0-1.el7.noarch
>>> openstack-keystone-11.0.0-1.el7.noarch
>>> python2-keystoneauth1-2.18.0-1.el7.noarch
>>> python-keystone-11.0.0-1.el7.noarch
>>>
>>> The errors I see in logs are similar to:
>>>
>>> ==> /var/log/horizon/horizon.log <==
>>> 2017-03-07 18:24:54,961 13745 ERROR horizon.exceptions Unauthorized:
>>> Traceback (most recent call last):
>>>   File 
>>> "/usr/share/openstack-dashboard/openstack_dashboard/dashboards/admin/floating_ips/views.py",
>>> line 53, in get_tenant_list
>>> tenants, has_more = api.keystone.tenant_list(request)
>>>   File "/usr/share/openstack-dashboard/openstack_dashboard/api/keystone.py",
>>> line 351, in tenant_list
>>> manager = VERSIONS.get_project_manager(request, admin=admin)
>>>   File "/usr/share/openstack-dashboard/openstack_dashboard/api/keystone.py",
>>> line 61, in get_project_manager
>>> manager = keystoneclient(*args, **kwargs).projects
>>>   File "/usr/share/openstack-dashboard/openstack_dashboard/api/keystone.py",
>>> line 170, in keystoneclient
>>> raise exceptions.NotAuthorized
>>> NotAuthorized
>>>
>>> Cheers,
>>> -E
>>> --
>>> Evan F. Bollig, PhD
>>> Scientific Computing Consultant, Application Developer | Scientific
>>> Computing Solutions (SCS)
>>> Minnesota Supercomputing Institute | msi.umn.edu
>>> University of Minnesota | umn.edu
>>> boll0...@umn.edu | 612-624-1447 | Walter Lib Rm 556
>>>
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [horizon] [keystone] [federated auth] [ocata] federated users with "admin" role not authorized for nova, cinder, neutron admin panels

[Evan Bollig PhD]

Hey Boris,

Which mapping? Hope you were looking for the shibboleth user
mapping. Also, hope this is the right way to share the paste (first
time using this):
http://paste.openstack.org/show/3snCb31GRZfAuQxdRouy/

Cheers,
-E
--
Evan F. Bollig, PhD
Scientific Computing Consultant, Application Developer | Scientific
Computing Solutions (SCS)
Minnesota Supercomputing Institute | msi.umn.edu
University of Minnesota | umn.edu
boll0...@umn.edu | 612-624-1447 | Walter Lib Rm 556


On Thu, Mar 9, 2017 at 7:50 AM, Boris Bobrov  wrote:
> Hi,
>
> Please paste your mapping to paste.openstack.org
>
> On 03/09/2017 02:07 AM, Evan Bollig PhD wrote:
>> I am on Ocata with Shibboleth auth enabled. I noticed that Federated
>> users with the admin role no longer have authorization to use the
>> Admin** panels in Horizon related to Nova, Cinder and Neutron. All
>> regular Identity and Project tabs function, and there are no problems
>> with authorization for local admin users.
>>
>> -
>> These Admin tabs work: Hypervisors, Host Aggregates, Flavors, Images,
>> Defaults, Metadata, System Information
>>
>> These result in logout: Instances, Volumes, Networks, Routers, Floating IPs
>>
>> This is not present: Overview
>> -
>>
>> The policies are vanilla from the CentOS/RDO openstack-dashboard RPMs:
>> openstack-dashboard-11.0.0-1.el7.noarch
>> python-django-horizon-11.0.0-1.el7.noarch
>> python2-keystonemiddleware-4.14.0-1.el7.noarch
>> python2-keystoneclient-3.10.0-1.el7.noarch
>> openstack-keystone-11.0.0-1.el7.noarch
>> python2-keystoneauth1-2.18.0-1.el7.noarch
>> python-keystone-11.0.0-1.el7.noarch
>>
>> The errors I see in logs are similar to:
>>
>> ==> /var/log/horizon/horizon.log <==
>> 2017-03-07 18:24:54,961 13745 ERROR horizon.exceptions Unauthorized:
>> Traceback (most recent call last):
>>   File 
>> "/usr/share/openstack-dashboard/openstack_dashboard/dashboards/admin/floating_ips/views.py",
>> line 53, in get_tenant_list
>> tenants, has_more = api.keystone.tenant_list(request)
>>   File "/usr/share/openstack-dashboard/openstack_dashboard/api/keystone.py",
>> line 351, in tenant_list
>> manager = VERSIONS.get_project_manager(request, admin=admin)
>>   File "/usr/share/openstack-dashboard/openstack_dashboard/api/keystone.py",
>> line 61, in get_project_manager
>> manager = keystoneclient(*args, **kwargs).projects
>>   File "/usr/share/openstack-dashboard/openstack_dashboard/api/keystone.py",
>> line 170, in keystoneclient
>> raise exceptions.NotAuthorized
>> NotAuthorized
>>
>> Cheers,
>> -E
>> --
>> Evan F. Bollig, PhD
>> Scientific Computing Consultant, Application Developer | Scientific
>> Computing Solutions (SCS)
>> Minnesota Supercomputing Institute | msi.umn.edu
>> University of Minnesota | umn.edu
>> boll0...@umn.edu | 612-624-1447 | Walter Lib Rm 556
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [horizon] [keystone] [federated auth] [ocata] federated users with "admin" role not authorized for nova, cinder, neutron admin panels

[Boris Bobrov]

Hi,

Please paste your mapping to paste.openstack.org

On 03/09/2017 02:07 AM, Evan Bollig PhD wrote:
> I am on Ocata with Shibboleth auth enabled. I noticed that Federated
> users with the admin role no longer have authorization to use the
> Admin** panels in Horizon related to Nova, Cinder and Neutron. All
> regular Identity and Project tabs function, and there are no problems
> with authorization for local admin users.
> 
> -
> These Admin tabs work: Hypervisors, Host Aggregates, Flavors, Images,
> Defaults, Metadata, System Information
> 
> These result in logout: Instances, Volumes, Networks, Routers, Floating IPs
> 
> This is not present: Overview
> -
> 
> The policies are vanilla from the CentOS/RDO openstack-dashboard RPMs:
> openstack-dashboard-11.0.0-1.el7.noarch
> python-django-horizon-11.0.0-1.el7.noarch
> python2-keystonemiddleware-4.14.0-1.el7.noarch
> python2-keystoneclient-3.10.0-1.el7.noarch
> openstack-keystone-11.0.0-1.el7.noarch
> python2-keystoneauth1-2.18.0-1.el7.noarch
> python-keystone-11.0.0-1.el7.noarch
> 
> The errors I see in logs are similar to:
> 
> ==> /var/log/horizon/horizon.log <==
> 2017-03-07 18:24:54,961 13745 ERROR horizon.exceptions Unauthorized:
> Traceback (most recent call last):
>   File 
> "/usr/share/openstack-dashboard/openstack_dashboard/dashboards/admin/floating_ips/views.py",
> line 53, in get_tenant_list
> tenants, has_more = api.keystone.tenant_list(request)
>   File "/usr/share/openstack-dashboard/openstack_dashboard/api/keystone.py",
> line 351, in tenant_list
> manager = VERSIONS.get_project_manager(request, admin=admin)
>   File "/usr/share/openstack-dashboard/openstack_dashboard/api/keystone.py",
> line 61, in get_project_manager
> manager = keystoneclient(*args, **kwargs).projects
>   File "/usr/share/openstack-dashboard/openstack_dashboard/api/keystone.py",
> line 170, in keystoneclient
> raise exceptions.NotAuthorized
> NotAuthorized
> 
> Cheers,
> -E
> --
> Evan F. Bollig, PhD
> Scientific Computing Consultant, Application Developer | Scientific
> Computing Solutions (SCS)
> Minnesota Supercomputing Institute | msi.umn.edu
> University of Minnesota | umn.edu
> boll0...@umn.edu | 612-624-1447 | Walter Lib Rm 556
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [horizon] [keystone] [federated auth] [ocata] federated users with "admin" role not authorized for nova, cinder, neutron admin panels

[Evan Bollig PhD]

I am on Ocata with Shibboleth auth enabled. I noticed that Federated
users with the admin role no longer have authorization to use the
Admin** panels in Horizon related to Nova, Cinder and Neutron. All
regular Identity and Project tabs function, and there are no problems
with authorization for local admin users.

-
These Admin tabs work: Hypervisors, Host Aggregates, Flavors, Images,
Defaults, Metadata, System Information

These result in logout: Instances, Volumes, Networks, Routers, Floating IPs

This is not present: Overview
-

The policies are vanilla from the CentOS/RDO openstack-dashboard RPMs:
openstack-dashboard-11.0.0-1.el7.noarch
python-django-horizon-11.0.0-1.el7.noarch
python2-keystonemiddleware-4.14.0-1.el7.noarch
python2-keystoneclient-3.10.0-1.el7.noarch
openstack-keystone-11.0.0-1.el7.noarch
python2-keystoneauth1-2.18.0-1.el7.noarch
python-keystone-11.0.0-1.el7.noarch

The errors I see in logs are similar to:

==> /var/log/horizon/horizon.log <==
2017-03-07 18:24:54,961 13745 ERROR horizon.exceptions Unauthorized:
Traceback (most recent call last):
  File 
"/usr/share/openstack-dashboard/openstack_dashboard/dashboards/admin/floating_ips/views.py",
line 53, in get_tenant_list
tenants, has_more = api.keystone.tenant_list(request)
  File "/usr/share/openstack-dashboard/openstack_dashboard/api/keystone.py",
line 351, in tenant_list
manager = VERSIONS.get_project_manager(request, admin=admin)
  File "/usr/share/openstack-dashboard/openstack_dashboard/api/keystone.py",
line 61, in get_project_manager
manager = keystoneclient(*args, **kwargs).projects
  File "/usr/share/openstack-dashboard/openstack_dashboard/api/keystone.py",
line 170, in keystoneclient
raise exceptions.NotAuthorized
NotAuthorized

Cheers,
-E
--
Evan F. Bollig, PhD
Scientific Computing Consultant, Application Developer | Scientific
Computing Solutions (SCS)
Minnesota Supercomputing Institute | msi.umn.edu
University of Minnesota | umn.edu
boll0...@umn.edu | 612-624-1447 | Walter Lib Rm 556

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [horizon] [keystone] No Keystone-Horizon cross project meeting today

[Rob Cresswell]

Hey everyone,

Sorry for the late notice, but there will be no Horizon-Keystone cross project 
meeting this week, as we've little to discuss with the PTG so recent. The 
meeting will resume as normal next week.

For those interested in joining, see 
http://eavesdrop.openstack.org/#Keystone/Horizon_Collaboration_Meeting

Rob
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [horizon] [keystone] Cross-Project Meeting

[Rob Cresswell]

Hey everyone,

Quick reminder about the Keystone-Horizon meeting at 2000 UTC (about 1h45 from 
this email being sent). You can see the details and add it to your calendar via 
http://eavesdrop.openstack.org/#Keystone/Horizon_Collaboration_Meeting

I'd like to keep up these meetings for the foreseeable future, as they were 
really useful in solving some complex long standing issues in Horizon.

There will also be a Keystone/Horizon cross project session at the PTG; 
Wednesday at 2:30 - 3:20 in Savannah. The details are listed on the Keystone 
PTG etherpad (https://etherpad.openstack.org/p/keystone-pike-ptg) in case this 
changes.

Rob
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Horizon][Keystone] Weekly meeting log (2016/12/1)

[Richard Jones]

Hi folks,

The meeting bot disappeared during the meeting so the record is
incomplete. The last 20 minutes are still in the channel log here:

http://eavesdrop.openstack.org/irclogs/%23openstack-meeting-cp/%23openstack-meeting-cp.2016-12-01.log.html#t2016-12-01T20:42:08


Richard

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Horizon] [Keystone] cross-project meeting Thursday 1st December 2000UTC

[Richard Jones]

Hi folks,

The next Keystone/Horizon cross-project meeting is this Thursday, 1st
December at 2000UTC in #openstack-meeting-cp

The agenda is https://etherpad.openstack.org/p/ocata-keystone-horizon

Please update that document if you're working on one of the items.


 Richard

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Horizon][Keystone] No Horizon/Keystone cross-project meeting this week

[Richard Jones]

Hi folks,

Since so many key people are away on vacation, we'll skip this week's
meeting (November 24th).


 Richard

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Horizon] [Keystone] Inaugural weekly cross-project meeting summary

[Richard Jones]

Hi folks,

Today we had the first of what will be a regular cross-project meeting
series for Horizon and Keystone developers[1].

It was a very productive meeting, and we resolved to continue to keep
our ongoing notes and status summaries in the etherpad[2] while still
ensuring that BPs or bugs cover the actual work being done.

The new, official timeslot will be Thursday at 2000 UTC[3]


 Richard

[1] 
http://eavesdrop.openstack.org/meetings/horizon_keystone/2016/horizon_keystone.2016-11-08-20.01.html
[2] https://etherpad.openstack.org/p/ocata-keystone-horizon
[3] http://eavesdrop.openstack.org/#Keystone/Horizon_Collaboration_Meeting

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [horizon][keystone] retiring python-keystoneclient-kerberos

[Steve Martinelli]

Hi there,

I would like to retire the python-keystoneclient-kerberos repo [1]. The
repo was pretty basic, it had a single auth plugin. The logic has since
been copied over to keystoneauth1 and provided you have kerberos libraries
installed the plugin will be available to you. The last release of
python-keystoneclient-kerberos  was on May 23rd 2016, which included a
deprecation warning. Note that the last release was version 0.3, so we're
talking very pre-1.0.

AFAICT, nothing uses the library any longer [2]. The only consumer that did
use it is django-openstack-auth-kerberos, which is switched over to
keystoneauth1, but has not been released in quite some time (Jun 9, 2015).
[3]

Selfishly, from a keystone perspective, I think we're in the clear and can
retire the repo. But I'm tagging horizon here to see what their plans are
for the django-openstack-auth-kerberos repo.

I think we need another release of django-openstack-auth-kerberos or a new
release of django_openstack_auth that also uses setuptools to optionally
install the kerberos libraries (this is what we did in keystoneauth).

Thoughts?
stevemar

[1] https://github.com/openstack/python-keystoneclient-kerberos
[2]
http://codesearch.openstack.org/?q=keystoneclient_kerberos=nope==
[3]
https://github.com/openstack/django-openstack-auth-kerberos/blob/master/requirements.txt#L9
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [horizon][keystone] Getting Auth Token from Horizon when using Federation

[Edmund Rhudy (BLOOMBERG/ 120 PARK)]

I flubbed my description of what I had in mind - I was thinking of GitHub 
personal access tokens as a model, _not_ OAuth tokens. I believe the normal 
excuse is "inadequate caffeine".

From: dolph.math...@gmail.com 
Subject: Re: [openstack-dev] [horizon][keystone] Getting Auth Token from 
Horizon when using Federation

On Thu, May 12, 2016 at 8:10 AM Edmund Rhudy (BLOOMBERG/ 120 PARK) 
<erh...@bloomberg.net> wrote:

+1 on desiring OAuth-style tokens in Keystone.

OAuth 1.0a has been supported by keystone since the havana release, you just 
have to turn it on and use it:

  http://docs.openstack.org/developer/keystone/configuration.html#oauth1-1-0a 
-- 
-Dolph

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [horizon][keystone] Getting Auth Token from Horizon when using Federation

[Dolph Mathews]

On Thu, May 12, 2016 at 8:10 AM Edmund Rhudy (BLOOMBERG/ 120 PARK) <
erh...@bloomberg.net> wrote:

> +1 on desiring OAuth-style tokens in Keystone.
>

OAuth 1.0a has been supported by keystone since the havana release, you
just have to turn it on and use it:


http://docs.openstack.org/developer/keystone/configuration.html#oauth1-1-0a
-- 
-Dolph
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [horizon][keystone] Getting Auth Token from Horizon when using Federation

[Adam Young]

On 05/12/2016 09:07 AM, Edmund Rhudy (BLOOMBERG/ 120 PARK) wrote:
+1 on desiring OAuth-style tokens in Keystone. The use cases that come 
up here are people wanting to be able to execute jobs that use the 
APIs (Jenkins, Terraform, Vagrant, etc.) without having to save their 
personal credentials in plaintext somewhere, and also wanting to be 
able to associate credentials with a project instead of a specific 
person, so that if a person leaves or rotates their password it 
doesn't blow up their team's carefully crafted automation.
We can sort of work around it with LDAP service accounts as mentioned 
previously, but the concern around those is the lack of speedy 
revocability in the event of a compromise, and the service accounts 
could possibly be used to get to non-OpenStack places until they get 
shut down. One thought I had to try to keep the auth domain 
constrained to only OpenStack was using the EC2 API because at least 
that means you're not saving LDAP passwords on disk and the access 
keys are useless beyond that particular Keystone installation, but you 
run into impedance mismatches between the Nova API and AWS EC2 API, 
and we'd like people to use the native OpenStack APIs. (Turns out the 
notion of using AWS's EC2 API to talk to a private cloud is strange to 
people not steeped in cloudy things.)
So Service accounts and OAuth consumers are two different names for the 
same abstract construct. IN both cases, the important thing is limiting 
the access each one has.



Horizon is for the interactive use case, though, and should not be using 
either, except as a front to define workflows, and in that case, the 
same work should be possible from the command line.


ECP should make that possible, assuming your IdP supports ECP (EIEIO!).




From: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [horizon][keystone] Getting Auth Token 
from Horizon when using Federation


Hi Dolph, On Mon, 2016-04-18 at 17:50 -0500, Dolph Mathews wrote:
> > On Mon, Apr 18, 2016 at 11:34 AM, Martin Millnert
<mar...@millnert.se <mailto:mar...@millnert.se>> > wrote: > Hi, >
> we're deploying Liberty (soon Mitaka) with heavy reliance on >
the SAML2 > Federation system by Keystone where we're a Service
Provider > (SP). > > The problem in this situation is getting a
token for direct > API > access.(*) > > There are conceptually two
methods to use the CLI: > 1) Modify ones (each customer -- in our
case O(100)) IdP to > add support > for a feature called ECP(**),
and then use keystoneauth with > SAML2 > plugin, > 2) Go to (for
example) "Access & Security / API Access / View > Credentials" in
Horizon, and check out a token from there. > > > With a default
configuration, this token would only last a short > period of
time, so this would be incredibly repetitive (and thus > tedious). 

Assuming all that is setup, the user should be unaware of the re-init to 
the SAML IdP to get a new assertion for a new token. Why is this a problem?




Indeed. > So, I assume you mean some sort of long-lived API
tokens? Right. > API tokens, including keystone's UUID, PKI, PKIZ,
and Fernet tokens > are all bearer tokens, so we force a short
lifetime by default, > because there are always multiple parties
capable of compromising the > integrity of a token. OAuth would be
a counter example, where OAuth > access tokens can (theoretically)
live forever. 



Still think that is a security violation.



This does sound very interesting. As long as the end user gets
something useful to plug into the openstack auth libraries/APIs,
we're home free (modulo security considerations, etc). > 2) isn't
implemented. 1) is a complete blocker for many > customers. > >
Are there any principal and fundamental reasons why 2 is not >
doable? > What I imagine needs to happen: > A) User is
authenticated (see *) in Horizon, > B) User uses said
authentication (token) to request another > token from > Keystone,
which is displayed under the "API Access" tab on > "Access & >
Security". > > > The (token) here could be an OAuth access token.
Will look into this (also as per our discussion in Austin). The
one issue that has appeared in our continued discussions at home,
is the contrast against "service user accounts", that seems a
relatively prevalent/common among deployers today, which basically
use username/password as the api key credentials, e.g. the authZ
of the issued token: If AdminNameless is Domain Admin in their
domain, won't their OAuth access token yield keystone tokens with
the same authZ as they otherwise have? My presumptive answer being
'yes', brought me to the realization that, if o

Re: [openstack-dev] [horizon][keystone] Getting Auth Token from Horizon when using Federation

[Edmund Rhudy (BLOOMBERG/ 120 PARK)]

+1 on desiring OAuth-style tokens in Keystone. The use cases that come up here 
are people wanting to be able to execute jobs that use the APIs (Jenkins, 
Terraform, Vagrant, etc.) without having to save their personal credentials in 
plaintext somewhere, and also wanting to be able to associate credentials with 
a project instead of a specific person, so that if a person leaves or rotates 
their password it doesn't blow up their team's carefully crafted automation.

We can sort of work around it with LDAP service accounts as mentioned 
previously, but the concern around those is the lack of speedy revocability in 
the event of a compromise, and the service accounts could possibly be used to 
get to non-OpenStack places until they get shut down. One thought I had to try 
to keep the auth domain constrained to only OpenStack was using the EC2 API 
because at least that means you're not saving LDAP passwords on disk and the 
access keys are useless beyond that particular Keystone installation, but you 
run into impedance mismatches between the Nova API and AWS EC2 API, and we'd 
like people to use the native OpenStack APIs. (Turns out the notion of using 
AWS's EC2 API to talk to a private cloud is strange to people not steeped in 
cloudy things.)

From: openstack-dev@lists.openstack.org 
Subject: Re: [openstack-dev] [horizon][keystone] Getting Auth Token from 
Horizon when using Federation

Hi Dolph,

On Mon, 2016-04-18 at 17:50 -0500, Dolph Mathews wrote:
> 
> On Mon, Apr 18, 2016 at 11:34 AM, Martin Millnert <mar...@millnert.se>
> wrote:
> Hi,
> 
> we're deploying Liberty (soon Mitaka) with heavy reliance on
> the SAML2
> Federation system by Keystone where we're a Service Provider
> (SP).
> 
> The problem in this situation is getting a token for direct
> API
> access.(*)
> 
> There are conceptually two methods to use the CLI:
>  1) Modify ones (each customer -- in our case O(100)) IdP to
> add support
> for a feature called ECP(**), and then use keystoneauth with
> SAML2
> plugin,
>  2) Go to (for example) "Access & Security / API Access / View
> Credentials" in Horizon, and check out a token from there.
> 
> 
> With a default configuration, this token would only last a short
> period of time, so this would be incredibly repetitive (and thus
> tedious).

Indeed.

> So, I assume you mean some sort of long-lived API tokens?

Right.

> API tokens, including keystone's UUID, PKI, PKIZ, and Fernet tokens
> are all bearer tokens, so we force a short lifetime by default,
> because there are always multiple parties capable of compromising the
> integrity of a token. OAuth would be a counter example, where OAuth
> access tokens can (theoretically) live forever.

This does sound very interesting. As long as the end user gets something
useful to plug into the openstack auth libraries/APIs, we're home free
(modulo security considerations, etc).

> 2) isn't implemented. 1) is a complete blocker for many
> customers.
> 
> Are there any principal and fundamental reasons why 2 is not
> doable?
> What I imagine needs to happen:
>   A) User is authenticated (see *) in Horizon,
>   B) User uses said authentication (token) to request another
> token from
> Keystone, which is displayed under the "API Access" tab on
> "Access &
> Security".
> 
> 
> The (token) here could be an OAuth access token.

Will look into this (also as per our discussion in Austin).

The one issue that has appeared in our continued discussions at home, is
the contrast against "service user accounts", that seems a relatively
prevalent/common among deployers today, which basically use
username/password as the api key credentials, e.g. the authZ of the
issued token:

If AdminNameless is Domain Admin in their domain, won't their OAuth
access token yield keystone tokens with the same authZ as they otherwise
have?

My presumptive answer being 'yes', brought me to the realization that,
if one wants to avoid going the way of "service user accounts" but still
reduce authZ, one would like to be able to get OAuth access tokens for a
specific project, with a specific role (e.g. "user", or [project-]admin)
and the authZ this entails. This would keep the traceability, which is
one of the main issues with non-personal accounts.

How feasible is this last bit?


In general, the primary use case is:
 - I as a user of openstack on my personal computer retrieve a token to
manage openstack client operations without the need of storing my
Federation-username/password in local config (nor typing the password in
o

Re: [openstack-dev] [horizon][keystone] Getting Auth Token from Horizon when using Federation

[Martin Millnert]

Hi Dolph,

On Mon, 2016-04-18 at 17:50 -0500, Dolph Mathews wrote:
> 
> On Mon, Apr 18, 2016 at 11:34 AM, Martin Millnert 
> wrote:
> Hi,
> 
> we're deploying Liberty (soon Mitaka) with heavy reliance on
> the SAML2
> Federation system by Keystone where we're a Service Provider
> (SP).
> 
> The problem in this situation is getting a token for direct
> API
> access.(*)
> 
> There are conceptually two methods to use the CLI:
>  1) Modify ones (each customer -- in our case O(100)) IdP to
> add support
> for a feature called ECP(**), and then use keystoneauth with
> SAML2
> plugin,
>  2) Go to (for example) "Access & Security / API Access / View
> Credentials" in Horizon, and check out a token from there.
> 
> 
> With a default configuration, this token would only last a short
> period of time, so this would be incredibly repetitive (and thus
> tedious).

Indeed.

> So, I assume you mean some sort of long-lived API tokens?

Right.

> API tokens, including keystone's UUID, PKI, PKIZ, and Fernet tokens
> are all bearer tokens, so we force a short lifetime by default,
> because there are always multiple parties capable of compromising the
> integrity of a token. OAuth would be a counter example, where OAuth
> access tokens can (theoretically) live forever.

This does sound very interesting. As long as the end user gets something
useful to plug into the openstack auth libraries/APIs, we're home free
(modulo security considerations, etc).

> 2) isn't implemented. 1) is a complete blocker for many
> customers.
> 
> Are there any principal and fundamental reasons why 2 is not
> doable?
> What I imagine needs to happen:
>   A) User is authenticated (see *) in Horizon,
>   B) User uses said authentication (token) to request another
> token from
> Keystone, which is displayed under the "API Access" tab on
> "Access &
> Security".
> 
> 
> The (token) here could be an OAuth access token.

Will look into this (also as per our discussion in Austin).

The one issue that has appeared in our continued discussions at home, is
the contrast against "service user accounts", that seems a relatively
prevalent/common among deployers today, which basically use
username/password as the api key credentials, e.g. the authZ of the
issued token:

If AdminNameless is Domain Admin in their domain, won't their OAuth
access token yield keystone tokens with the same authZ as they otherwise
have?

My presumptive answer being 'yes', brought me to the realization that,
if one wants to avoid going the way of "service user accounts" but still
reduce authZ, one would like to be able to get OAuth access tokens for a
specific project, with a specific role (e.g. "user", or [project-]admin)
and the authZ this entails. This would keep the traceability, which is
one of the main issues with non-personal accounts.

How feasible is this last bit?


In general, the primary use case is:
 - I as a user of openstack on my personal computer retrieve a token to
manage openstack client operations without the need of storing my
Federation-username/password in local config (nor typing the password in
on the keyboard).

An extended use case definition of this being:
 - I as a user of openstack can provision an automated system with these
credentials, that can continue to operate as an openstack client for a
very long time without maintenance (i.e., either token renewal or
VeryLongLifetime).

Best,
Martin


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [horizon][keystone] Getting Auth Token from Horizon when using Federation

[Marco Fargetta]

On Thu, Apr 21, 2016 at 10:22:46AM -0400, John Dennis wrote:
> On 04/18/2016 12:34 PM, Martin Millnert wrote:
> >(** ECP is a new feature, not supported by all IdP's, that at (second)
> >best requires reconfiguration of core authentication services at each
> >customer, and at worst requires customers to change IdP software
> >completely. This is a varying degree of showstopper for various
> >customers.)
> 
> The majority of work to support ECP is in the SP, not the IdP. In fact IdP's
> are mostly agnostic with respect to ECP, there is nothing ECP specific an
> IdP must implement other than supporting the SOAP binding for the
> SingleSignOnService which is trivial. I've yet to encounter an IdP that does
> not support the SOAP binding.
> 
> What IdP are you utilizing which is incapable of receiving an AuthnRequest
> via the SOAP binding?
> 

I would disagree on this. Last year in EduGAIN, the European
interfederation including hundreds of IdPs, only a very small amount
were supporting ECP. I did a check on the metadata.


Additionally, some IdP implementations do not support ECP
out-of-the-box and for the one providing such support, it requires a
different authentication mechanism compared to the one used for the
redirect or post profile so many IdPs are not supporting this
mechanism.

The work to support ECP is equally distributed among the IdP and SP
although it is getting more common in the IdPs with last release of
IdPs software such as shibboleth IdP v3.

Marco



> 
> -- 
> John
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




smime.p7s
Description: S/MIME cryptographic signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [horizon][keystone] Getting Auth Token from Horizon when using Federation

[John Dennis]

On 04/18/2016 12:34 PM, Martin Millnert wrote:

(** ECP is a new feature, not supported by all IdP's, that at (second)
best requires reconfiguration of core authentication services at each
customer, and at worst requires customers to change IdP software
completely. This is a varying degree of showstopper for various
customers.)


The majority of work to support ECP is in the SP, not the IdP. In fact 
IdP's are mostly agnostic with respect to ECP, there is nothing ECP 
specific an IdP must implement other than supporting the SOAP binding 
for the SingleSignOnService which is trivial. I've yet to encounter an 
IdP that does not support the SOAP binding.


What IdP are you utilizing which is incapable of receiving an 
AuthnRequest via the SOAP binding?



--
John

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [horizon][keystone] Getting Auth Token from Horizon when using Federation

[Adam Young]

On 04/18/2016 12:34 PM, Martin Millnert wrote:

Hi,

we're deploying Liberty (soon Mitaka) with heavy reliance on the SAML2
Federation system by Keystone where we're a Service Provider (SP).

The problem in this situation is getting a token for direct API
access.(*)

There are conceptually two methods to use the CLI:
  1) Modify ones (each customer -- in our case O(100)) IdP to add support
for a feature called ECP(**), and then use keystoneauth with SAML2
plugin,
We have this working.  Your SAML provider might not.  What Are you 
working with?




  2) Go to (for example) "Access & Security / API Access / View
Credentials" in Horizon, and check out a token from there.

Insecure as all get out.  Please no.



2) isn't implemented. 1) is a complete blocker for many customers.

Are there any principal and fundamental reasons why 2 is not doable?
What I imagine needs to happen:
   A) User is authenticated (see *) in Horizon,
   B) User uses said authentication (token) to request another token from
Keystone, which is displayed under the "API Access" tab on "Access &
Security".

 From a general perspective, I can't see why this shouldn't work.


Let me explain.   A Token is a symmetric shared secret.  You should not 
be copyuing it around, etc.  You don't make it readable in a Web UI.  
You control it, and ideally, never let it see the light of day.




Whatever scoping the user currently has should be sufficient to check
out a similarly-or-lesser scoped token.

Anyway, we will, if this is at all doable, bolt this onto our local
deployment. I do, A) believe we're not alone with this use case (***),
B) look for input on doability.

We'll be around in Austin for discussion with Horizon/Keystone regarding
this if necessary.

Regards,
Martin Millnert

(* The reason this is a problem: With Federation, there are no local
users and passwords in the Keystone database. When authenticating to
Horizon in this setup, Keystone (I think) redirects the user to an HTTP
page on the home site's Identity Provider (IdP), which performs the
authentication. The IdP then signs a set of entitlements about this
identity, and sends these back to Keystone. Passwords stay at home. Epic
Win.)

(** ECP is a new feature, not supported by all IdP's, that at (second)
best requires reconfiguration of core authentication services at each
customer, and at worst requires customers to change IdP software
completely. This is a varying degree of showstopper for various
customers.)

(***
https://stackoverflow.com/questions/20034143/getting-auth-token-from-keystone-in-horizon
https://ask.openstack.org/en/question/51072/get-keystone-auth-token-via-horizon-url/
)


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [horizon][keystone] Getting Auth Token from Horizon when using Federation

[Dolph Mathews]

On Mon, Apr 18, 2016 at 11:34 AM, Martin Millnert 
wrote:

> Hi,
>
> we're deploying Liberty (soon Mitaka) with heavy reliance on the SAML2
> Federation system by Keystone where we're a Service Provider (SP).
>
> The problem in this situation is getting a token for direct API
> access.(*)
>
> There are conceptually two methods to use the CLI:
>  1) Modify ones (each customer -- in our case O(100)) IdP to add support
> for a feature called ECP(**), and then use keystoneauth with SAML2
> plugin,
>  2) Go to (for example) "Access & Security / API Access / View
> Credentials" in Horizon, and check out a token from there.
>

With a default configuration, this token would only last a short period of
time, so this would be incredibly repetitive (and thus tedious).

So, I assume you mean some sort of long-lived API tokens? API tokens,
including keystone's UUID, PKI, PKIZ, and Fernet tokens are all bearer
tokens, so we force a short lifetime by default, because there are always
multiple parties capable of compromising the integrity of a token. OAuth
would be a counter example, where OAuth access tokens can (theoretically)
live forever.


>
> 2) isn't implemented. 1) is a complete blocker for many customers.
>
> Are there any principal and fundamental reasons why 2 is not doable?
> What I imagine needs to happen:
>   A) User is authenticated (see *) in Horizon,
>   B) User uses said authentication (token) to request another token from
> Keystone, which is displayed under the "API Access" tab on "Access &
> Security".
>

The (token) here could be an OAuth access token.


>
> From a general perspective, I can't see why this shouldn't work.
>
> Whatever scoping the user currently has should be sufficient to check
> out a similarly-or-lesser scoped token.
>
> Anyway, we will, if this is at all doable, bolt this onto our local
> deployment. I do, A) believe we're not alone with this use case (***),
> B) look for input on doability.
>
> We'll be around in Austin for discussion with Horizon/Keystone regarding
> this if necessary.
>
> Regards,
> Martin Millnert
>
> (* The reason this is a problem: With Federation, there are no local
> users and passwords in the Keystone database. When authenticating to
> Horizon in this setup, Keystone (I think) redirects the user to an HTTP
> page on the home site's Identity Provider (IdP), which performs the
> authentication. The IdP then signs a set of entitlements about this
> identity, and sends these back to Keystone. Passwords stay at home. Epic
> Win.)
>
> (** ECP is a new feature, not supported by all IdP's, that at (second)
> best requires reconfiguration of core authentication services at each
> customer, and at worst requires customers to change IdP software
> completely. This is a varying degree of showstopper for various
> customers.)
>
> (***
>
> https://stackoverflow.com/questions/20034143/getting-auth-token-from-keystone-in-horizon
>
> https://ask.openstack.org/en/question/51072/get-keystone-auth-token-via-horizon-url/
> )
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [horizon][keystone] Getting Auth Token from Horizon when using Federation

[Martin Millnert]

Hi,

we're deploying Liberty (soon Mitaka) with heavy reliance on the SAML2
Federation system by Keystone where we're a Service Provider (SP).

The problem in this situation is getting a token for direct API
access.(*)

There are conceptually two methods to use the CLI:
 1) Modify ones (each customer -- in our case O(100)) IdP to add support
for a feature called ECP(**), and then use keystoneauth with SAML2
plugin,
 2) Go to (for example) "Access & Security / API Access / View
Credentials" in Horizon, and check out a token from there.

2) isn't implemented. 1) is a complete blocker for many customers.

Are there any principal and fundamental reasons why 2 is not doable?
What I imagine needs to happen:
  A) User is authenticated (see *) in Horizon,
  B) User uses said authentication (token) to request another token from
Keystone, which is displayed under the "API Access" tab on "Access &
Security".

>From a general perspective, I can't see why this shouldn't work.

Whatever scoping the user currently has should be sufficient to check
out a similarly-or-lesser scoped token.

Anyway, we will, if this is at all doable, bolt this onto our local
deployment. I do, A) believe we're not alone with this use case (***),
B) look for input on doability.

We'll be around in Austin for discussion with Horizon/Keystone regarding
this if necessary.

Regards,
Martin Millnert

(* The reason this is a problem: With Federation, there are no local
users and passwords in the Keystone database. When authenticating to
Horizon in this setup, Keystone (I think) redirects the user to an HTTP
page on the home site's Identity Provider (IdP), which performs the
authentication. The IdP then signs a set of entitlements about this
identity, and sends these back to Keystone. Passwords stay at home. Epic
Win.)

(** ECP is a new feature, not supported by all IdP's, that at (second)
best requires reconfiguration of core authentication services at each
customer, and at worst requires customers to change IdP software
completely. This is a varying degree of showstopper for various
customers.)

(*** 
https://stackoverflow.com/questions/20034143/getting-auth-token-from-keystone-in-horizon
https://ask.openstack.org/en/question/51072/get-keystone-auth-token-via-horizon-url/
 
)


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Horizon][Keystone]Re: Keystone 'adminURL' option to fallback to 'internalURL' within Horizon api/keystone.py?

[Dolph Mathews]

You can use the public URL as a fallback to the internal URL; however, the
admin URL is assumed to be the only privileged API endpoint.

The details are buried in API documentation (and perhaps history), but I
tried to summarize the intended design here as I understand it:

  http://dolphm.com/openstack-keystone-service-catalog/

On Thu, Apr 7, 2016 at 1:39 PM, Brad Pokorny 
wrote:

> Hi Brian,
>
> Copying to the general list, as this is something I've wondered about, and
> others probably are as well.
>
> Please see below. I'm not an expert on this topic, but I've looked at it a
> little bit.
>
> On 4/7/16, 11:02 AM, "Tully, Brian"  wrote:
>
> >Hi there -
> >
> >I'm reaching out to ask for some clarification on what the difference is
> >between adminURL and internalURL as it pertains to the keystoneclient ‹
> >specifically in api/keystone.py
> >(
> http://git.openstack.org/cgit/openstack/horizon/tree/openstack_dashboard/
> >a
> >pi/keystone.py#n163) whereby if the user is logged in as an admin, the api
> >will specify 'adminURL' as the endpoint type.
> >
> >We have a scenario where our admin interface and internal interface are on
> >2 separate networks, and therefore the adminURL is not accessible by
> >Horizon.
>
> I think the original intent of having separate URL types was this exact
> purpose - having them on different networks/ports that can be locked down
> to protect admin operations. This was briefly mentioned in a recent ML
> post:
> http://openstack.markmail.org/message/2in7yab2jvvptg3h?q=%5Bkeystone%5D+ord
> er:date-backward=1
>
> It sounds like operations were locked down for the v2 identity API, but
> maybe not for v3 (which I'm assuming is what you're using).
>
> >When using the openstack CLI, we can specify the endpoint type as
> >internal and do not see any perceived reduction in functionality as an
> >admin user.
>
> If everything can be done via the CLI with the internal URL anyway, then
> what's the point of protecting the admin URL on a separate network? Sounds
> like this is what your question below is getting at.
>
> >Are there certain functions that can only be accessed through
> >the adminURL?
>
> This is what I'm not sure of.
>
> >
> >
> >For our use case, we think we can workaround this by adding a new config
> >setting, e.g., IDENTITY_ADMIN_ENDPOINT_TYPE and setting it to
> >'internalURL' in local_settings.py:
> >
> ># IDENTITY_ADMIN_ENDPOINT_TYPE specifies the admin endpoint type to use in
> >the
> ># case that the default admin interface in the Keystone service catalog
> ># is not accessible by Horizon. Use this setting when Horizon cannot
> ># access the identity endpoint at the default 'adminURL' and set it to
> ># 'internalURL'.
> >#IDENTITY_ADMIN_ENDPOINT_TYPE = "internalURL"
> >
> >
> >then in api/keystone.py we can change
> >
> >endpoint_type = 'adminURL'
> >
> >to
> >
> >endpoint_type = getattr(settings,
> >'IDENTITY_ADMIN_ENDPOINT_TYPE',
> >'adminURL')
> >
> >which will use 'adminURL' as the default, but allow user customizable
> >endpoint type for identity
> >
> >
> >Does this seem even remotely useful upstream? Let me know...
>
> I would think if the internal URL can do everything the admin URL can do,
> and if that's how things are supposed to remain long term, there's no
> reason to have internal and admin on separate networks.
>
> >
> >Thanks!
> >
> >Brian Tully
> >Software Engineer
> >HPE
> >
> >
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Horizon][Keystone]Re: Keystone 'adminURL' option to fallback to 'internalURL' within Horizon api/keystone.py?

[McLellan, Steven]

Hi,

I think Brad's spot on. See inline, but short version - the special case
is only required if the KS catalog returns v2.0 endpoints.

On 4/7/16, 1:39 PM, "Brad Pokorny"  wrote:

>Hi Brian,
>
>Copying to the general list, as this is something I've wondered about, and
>others probably are as well.
>
>Please see below. I'm not an expert on this topic, but I've looked at it a
>little bit.
>
>On 4/7/16, 11:02 AM, "Tully, Brian"  wrote:
>
>>Hi there -
>>
>>I'm reaching out to ask for some clarification on what the difference is
>>between adminURL and internalURL as it pertains to the keystoneclient ‹
>>specifically in api/keystone.py
>>(http://git.openstack.org/cgit/openstack/horizon/tree/openstack_dashboard
>>/
>>a
>>pi/keystone.py#n163) whereby if the user is logged in as an admin, the
>>api
>>will specify 'adminURL' as the endpoint type.
>>
>>We have a scenario where our admin interface and internal interface are
>>on
>>2 separate networks, and therefore the adminURL is not accessible by
>>Horizon. 
>
>I think the original intent of having separate URL types was this exact
>purpose - having them on different networks/ports that can be locked down
>to protect admin operations. This was briefly mentioned in a recent ML
>post: 
>http://openstack.markmail.org/message/2in7yab2jvvptg3h?q=%5Bkeystone%5D+or
>d
>er:date-backward=1
>
>It sounds like operations were locked down for the v2 identity API, but
>maybe not for v3 (which I'm assuming is what you're using).
>
>>When using the openstack CLI, we can specify the endpoint type as
>>internal and do not see any perceived reduction in functionality as an
>>admin user. 
>
>If everything can be done via the CLI with the internal URL anyway, then
>what's the point of protecting the admin URL on a separate network? Sounds
>like this is what your question below is getting at.
>
>>Are there certain functions that can only be accessed through
>>the adminURL?
>
>This is what I'm not sure of.



Note that the endpoint used will be the one the keystone catalog returns,
not whatever's configured in local_settings, but under v2.0, if instead of
using the admin port on 35357 you use port 5000 you'll get 404s from some
identity management functions:

# V3
curl -H"x-auth-token: $token"
http://192.168.235.128:5000/v3/users/719319cc0f9d47b9b9ce512b77ae5da6
{"user": {"id": "719319cc0f9d47b9b9ce512b77ae5da6", "enabled": true,
"domain_id": "default", "links": {"self":
"http://192.168.235.128:5000/v3/users/719319cc0f9d47b9b9ce512b77ae5da6"},
"name": "admin"}}


# V2.0
curl -H"x-auth-token: $token"
http://192.168.235.128:5000/v2.0/users/719319cc0f9d47b9b9ce512b77ae5da6
{"error": {"message": "The resource could not be found.", "code": 404,
"title": "Not Found"}}


If the catalog returns v3, this special case isn't needed; if it's v2.0,
it is.




>
>> 
>>
>>For our use case, we think we can workaround this by adding a new config
>>setting, e.g., IDENTITY_ADMIN_ENDPOINT_TYPE and setting it to
>>'internalURL' in local_settings.py:
>>
>># IDENTITY_ADMIN_ENDPOINT_TYPE specifies the admin endpoint type to use
>>in
>>the
>># case that the default admin interface in the Keystone service catalog
>># is not accessible by Horizon. Use this setting when Horizon cannot
>># access the identity endpoint at the default 'adminURL' and set it to
>># 'internalURL'.
>>#IDENTITY_ADMIN_ENDPOINT_TYPE = "internalURL"
>>
>>
>>then in api/keystone.py we can change
>>
>>endpoint_type = 'adminURL'
>>
>>to
>>
>>endpoint_type = getattr(settings,
>>'IDENTITY_ADMIN_ENDPOINT_TYPE',
>>'adminURL')
>>
>>which will use 'adminURL' as the default, but allow user customizable
>>endpoint type for identity
>>
>>
>>Does this seem even remotely useful upstream? Let me know...
>
>I would think if the internal URL can do everything the admin URL can do,
>and if that's how things are supposed to remain long term, there's no
>reason to have internal and admin on separate networks.
>
>>
>>Thanks!
>>
>>Brian Tully
>>Software Engineer
>>HPE
>>
>>
>

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Horizon][Keystone]Re: Keystone 'adminURL' option to fallback to 'internalURL' within Horizon api/keystone.py?

[Brad Pokorny]

Hi Brian,

Copying to the general list, as this is something I've wondered about, and
others probably are as well.

Please see below. I'm not an expert on this topic, but I've looked at it a
little bit.

On 4/7/16, 11:02 AM, "Tully, Brian"  wrote:

>Hi there -
>
>I'm reaching out to ask for some clarification on what the difference is
>between adminURL and internalURL as it pertains to the keystoneclient ‹
>specifically in api/keystone.py
>(http://git.openstack.org/cgit/openstack/horizon/tree/openstack_dashboard/
>a
>pi/keystone.py#n163) whereby if the user is logged in as an admin, the api
>will specify 'adminURL' as the endpoint type.
>
>We have a scenario where our admin interface and internal interface are on
>2 separate networks, and therefore the adminURL is not accessible by
>Horizon. 

I think the original intent of having separate URL types was this exact
purpose - having them on different networks/ports that can be locked down
to protect admin operations. This was briefly mentioned in a recent ML
post: 
http://openstack.markmail.org/message/2in7yab2jvvptg3h?q=%5Bkeystone%5D+ord
er:date-backward=1

It sounds like operations were locked down for the v2 identity API, but
maybe not for v3 (which I'm assuming is what you're using).

>When using the openstack CLI, we can specify the endpoint type as
>internal and do not see any perceived reduction in functionality as an
>admin user. 

If everything can be done via the CLI with the internal URL anyway, then
what's the point of protecting the admin URL on a separate network? Sounds
like this is what your question below is getting at.

>Are there certain functions that can only be accessed through
>the adminURL?

This is what I'm not sure of.

> 
>
>For our use case, we think we can workaround this by adding a new config
>setting, e.g., IDENTITY_ADMIN_ENDPOINT_TYPE and setting it to
>'internalURL' in local_settings.py:
>
># IDENTITY_ADMIN_ENDPOINT_TYPE specifies the admin endpoint type to use in
>the
># case that the default admin interface in the Keystone service catalog
># is not accessible by Horizon. Use this setting when Horizon cannot
># access the identity endpoint at the default 'adminURL' and set it to
># 'internalURL'.
>#IDENTITY_ADMIN_ENDPOINT_TYPE = "internalURL"
>
>
>then in api/keystone.py we can change
>
>endpoint_type = 'adminURL'
>
>to
>
>endpoint_type = getattr(settings,
>'IDENTITY_ADMIN_ENDPOINT_TYPE',
>'adminURL')
>
>which will use 'adminURL' as the default, but allow user customizable
>endpoint type for identity
>
>
>Does this seem even remotely useful upstream? Let me know...

I would think if the internal URL can do everything the admin URL can do,
and if that's how things are supposed to remain long term, there's no
reason to have internal and admin on separate networks.

>
>Thanks!
>
>Brian Tully
>Software Engineer
>HPE
>
>


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [horizon][keystone]

[David Chadwick]

Hi Lin

I am submitting the code and dissertation links to the mailing list so
that I only need to do it once for everyone.

Since these are large files, I have sent them to Dropbox. They are
public access, available as follows:

Brida_Final Dissertation.pdf (3.5Mb)
(https://www.dropbox.com/s/ugyrffgjkmq1a3s/Brinda_Final%20Dissertation.pdf?dl=0)

and

Corpus.zip  (12.7Mb)
(https://www.dropbox.com/s/98fp2c9194n198j/corpus.zip?dl=0)

regards

David

On 14/11/2015 02:59, Lin Hua Cheng wrote:
> David, 
> 
> FYI, I've submitted a patch to enable registering Identity Providers in
> horizon:
> 
> https://review.openstack.org/#/c/244991/
> 
> The next logical step for this is to look at the IdP mapping.
> 
> I can follow-up on the work by Anton to add that support for horizon. 
> 
> Can you send me the code and documents you may have related to this?
> 
> Thanks,
> Lin
> 
> 
> 
> On Wed, Oct 7, 2015 at 11:12 AM, David Chadwick <d.w.chadw...@kent.ac.uk
> <mailto:d.w.chadw...@kent.ac.uk>> wrote:
> 
> 
> 
> On 07/10/2015 18:29, Adam Young wrote:
> > On 10/07/2015 11:51 AM, Adam Young wrote:
> >> Send me what you have, and I will post it as a Work in progress review
> >> against Horizon.  That way at least it will be available for others to
> >> look at and potentially adopt.
> >
> > Review has been posted here
> > https://review.openstack.org/232114
> >
> 
> thanks Adam
> 
> >
> > I made a best guess as far as where it it should be placed in the source
> > tree.  I have not tested the code.
> >
> > David and I have both signed the CLA. I am fairly certon Anton did not.
> > It would be easiest for OpenStack to accept this code if he did, as
> > there would be no question about copyright or licensing.
> 
> Legally speaking it is not necessary, since any code produced by
> students as part of their degree course does not belong to them.
> However, it would be courteous of us to ask him, so I have done this.
> 
> >
> > David also provided me with a PDF version of Anton's dissertation. I do
> > not know what the status of that document, but it would be a great
> > resource to anyone that wants to take this code and get it integrated
> > into Horizon.
> 
> This can be made publicly available after the exam board next month.
> Until then I will give out personal copies for private study.
> 
> regards
> 
> David
> 
> >
> > This does not look like a radical stretch.  It would be a decent
> > opportunity for anyone looking to get involved with OpenStack to step
> > into something immediately.
> >
> >
> >
> >
> >>
> >>
> >>
> >> On 10/07/2015 11:37 AM, David Chadwick wrote:
> >>> Hi Douglas
> >>>
> >>> we are happy for you (or someone else) to submit the code in 3
> names:
> >>> theirs, mine and Anton's. Then this third person can do all the work
> >>> necessary to get it approved. In this way it is legitimate,
> since the
> >>> third person will have contributed to the overall effort.
> >>>
> >>> I dont have any spare time yet for another month or so. After that I
> >>> could submit it, but having never done it before for Horizon,
> there will
> >>> be a big learning curve. And I might not have time to learn it
> >>>
> >>> regards
> >>>
> >>> David
> >>>
> >>> On 07/10/2015 16:05, Douglas Fish wrote:
> >>>> Hi David,
> >>>>   This sounds like a great set of code, I'm sure we are going to
> >>>> realize
> >>>> we want it sooner or later! Unfortunately I can't consume code
> in this
> >>>> way (I can't propose code written by somebody else) and I can't
> spend
> >>>> significant time on it right now.
> >>>>   Would you or Anton be willing to propose whatever code and
> >>>> documentation
> >>>> you have to Horizon? It doesn't have to be complete; it doesn't
> need to
> >>>> have grammar cleaned up or anything like that. You could mark
> it as a
> >>>> "Work in progress", and make it clear in the commit message
> that you
> >>>> aren't planning further work on this, so the patch is ava

Re: [openstack-dev] [horizon][keystone]

[Lin Hua Cheng]

 it sooner or later! Unfortunately I can't consume code
> > in this
> > >>>> way (I can't propose code written by somebody else) and I can't
> > spend
> > >>>> significant time on it right now.
> > >>>>   Would you or Anton be willing to propose whatever code and
> > >>>> documentation
> > >>>> you have to Horizon? It doesn't have to be complete; it doesn't
> > need to
> > >>>> have grammar cleaned up or anything like that. You could mark
> > it as a
> > >>>> "Work in progress", and make it clear in the commit message
> > that you
> > >>>> aren't planning further work on this, so the patch is available
> for
> > >>>> adoption. That way somebody else may be able to pick this up and
> > >>>> work on
> > >>>> it in the future, but Anton could get credit for the work he
> > has done.
> > >>>>
> > >>>> Doug Fish
> > >>>>
> > >>>>  - Original message -
> > >>>>  From: David Chadwick <d.w.chadw...@kent.ac.uk
> > <mailto:d.w.chadw...@kent.ac.uk>>
> > >>>>  To: OpenStack Development Mailing List
> > >>>>  <openstack-dev@lists.openstack.org
> > <mailto:openstack-dev@lists.openstack.org>>
> > >>>>  Cc:
> > >>>>  Subject: [openstack-dev] [horizon][keystone]
> > >>>>  Date: Tue, Oct 6, 2015 2:13 PM
> > >>>>Dear All
> > >>>>
> > >>>>  One of my students, Anton Brida, has developed an Attribute
> > >>>> Mapping GUI
> > >>>>  for Horizon as part of his MSc project. Attribute mappings
> > are an
> > >>>>  essential, though complex, part of federated Keystone.
> > >>>> Currently they
> > >>>>  can only be created as JSON objects in the config file. The
> > >>>> Horizon code
> > >>>>  allows them to be dynamically created via an easy to use
> GUI.
> > >>>>
> > >>>>  Since Anton has now left the university for full time
> > >>>> employment, he is
> > >>>>  not able to go through the process of submitting his code
> to
> > >>>> the next
> > >>>>  release of Horizon. His design however was submitted to
> > >>>> InVision and
> > >>>>  commented on by various people at the time of the
> development.
> > >>>>
> > >>>>  I am now looking for someone who would like to take a copy
> of
> > >>>> this code
> > >>>>  and go through the process of submitting this to the next
> > >>>> release of
> > >>>>  Horizon. I have a copy of Anton's MSc dissertation as well
> > which
> > >>>>  explains the work that he has done.
> > >>>>
> > >>>>  All the attribute mapping features are supported in
> > Anton's code
> > >>>>  (groups, users, direct mapping, multiple attribute values
> > etc.)
> > >>>>  However the whitelist/blacklist feature is not, since this
> was
> > >>>> not fully
> > >>>>  incorporated into Keystone when Anton was doing his
> > >>>> implementation. (I
> > >>>>  am still not sure if it has been.)
> > >>>>
> > >>>>  The code has a couple of known bugs:
> > >>>>
> > >>>>  1. when a user tries to enter an email address into an
> > >>>> attribute value
> > >>>>  (i.e. usern...@example.com <mailto:usern...@example.com>)
> > and saves the mapping rule into the
> > >>>>  database, after reloading the new list of mappings rules
> the
> > >>>> interface
> > >>>>  does not work as intended. The particular reason why this
> is
> > >>>> happening
> > >>>>  is yet unknown. The only way to avoid

Re: [openstack-dev] [horizon][keystone]

[Lin Hua Cheng]

David,

FYI, I've submitted a patch to enable registering Identity Providers in
horizon:

https://review.openstack.org/#/c/244991/

The next logical step for this is to look at the IdP mapping.

I can follow-up on the work by Anton to add that support for horizon.

Can you send me the code and documents you may have related to this?

Thanks,
Lin



On Wed, Oct 7, 2015 at 11:12 AM, David Chadwick <d.w.chadw...@kent.ac.uk>
wrote:

>
>
> On 07/10/2015 18:29, Adam Young wrote:
> > On 10/07/2015 11:51 AM, Adam Young wrote:
> >> Send me what you have, and I will post it as a Work in progress review
> >> against Horizon.  That way at least it will be available for others to
> >> look at and potentially adopt.
> >
> > Review has been posted here
> > https://review.openstack.org/232114
> >
>
> thanks Adam
>
> >
> > I made a best guess as far as where it it should be placed in the source
> > tree.  I have not tested the code.
> >
> > David and I have both signed the CLA. I am fairly certon Anton did not.
> > It would be easiest for OpenStack to accept this code if he did, as
> > there would be no question about copyright or licensing.
>
> Legally speaking it is not necessary, since any code produced by
> students as part of their degree course does not belong to them.
> However, it would be courteous of us to ask him, so I have done this.
>
> >
> > David also provided me with a PDF version of Anton's dissertation. I do
> > not know what the status of that document, but it would be a great
> > resource to anyone that wants to take this code and get it integrated
> > into Horizon.
>
> This can be made publicly available after the exam board next month.
> Until then I will give out personal copies for private study.
>
> regards
>
> David
>
> >
> > This does not look like a radical stretch.  It would be a decent
> > opportunity for anyone looking to get involved with OpenStack to step
> > into something immediately.
> >
> >
> >
> >
> >>
> >>
> >>
> >> On 10/07/2015 11:37 AM, David Chadwick wrote:
> >>> Hi Douglas
> >>>
> >>> we are happy for you (or someone else) to submit the code in 3 names:
> >>> theirs, mine and Anton's. Then this third person can do all the work
> >>> necessary to get it approved. In this way it is legitimate, since the
> >>> third person will have contributed to the overall effort.
> >>>
> >>> I dont have any spare time yet for another month or so. After that I
> >>> could submit it, but having never done it before for Horizon, there
> will
> >>> be a big learning curve. And I might not have time to learn it
> >>>
> >>> regards
> >>>
> >>> David
> >>>
> >>> On 07/10/2015 16:05, Douglas Fish wrote:
> >>>> Hi David,
> >>>>   This sounds like a great set of code, I'm sure we are going to
> >>>> realize
> >>>> we want it sooner or later! Unfortunately I can't consume code in this
> >>>> way (I can't propose code written by somebody else) and I can't spend
> >>>> significant time on it right now.
> >>>>   Would you or Anton be willing to propose whatever code and
> >>>> documentation
> >>>> you have to Horizon? It doesn't have to be complete; it doesn't need
> to
> >>>> have grammar cleaned up or anything like that. You could mark it as a
> >>>> "Work in progress", and make it clear in the commit message that you
> >>>> aren't planning further work on this, so the patch is available for
> >>>> adoption. That way somebody else may be able to pick this up and
> >>>> work on
> >>>> it in the future, but Anton could get credit for the work he has done.
> >>>>
> >>>> Doug Fish
> >>>>
> >>>>  - Original message -
> >>>>  From: David Chadwick <d.w.chadw...@kent.ac.uk>
> >>>>  To: OpenStack Development Mailing List
> >>>>  <openstack-dev@lists.openstack.org>
> >>>>  Cc:
> >>>>  Subject: [openstack-dev] [horizon][keystone]
> >>>>  Date: Tue, Oct 6, 2015 2:13 PM
> >>>>Dear All
> >>>>
> >>>>  One of my students, Anton Brida, has developed an Attribute
> >>>> Mapping GUI
> >>>>  for Horizon as part of his MSc pro

Re: [openstack-dev] [horizon][keystone]

[Douglas Fish]

Hi David,
 
This sounds like a great set of code, I'm sure we are going to realize we want it sooner or later! Unfortunately I can't consume code in this way (I can't propose code written by somebody else) and I can't spend significant time on it right now.
 
Would you or Anton be willing to propose whatever code and documentation you have to Horizon? It doesn't have to be complete; it doesn't need to have grammar cleaned up or anything like that. You could mark it as a "Work in progress", and make it clear in the commit message that you aren't planning further work on this, so the patch is available for adoption. That way somebody else may be able to pick this up and work on it in the future, but Anton could get credit for the work he has done.
Doug Fish
 
 
- Original message -From: David Chadwick <d.w.chadw...@kent.ac.uk>To: OpenStack Development Mailing List <openstack-dev@lists.openstack.org>Cc:Subject: [openstack-dev] [horizon][keystone]Date: Tue, Oct 6, 2015 2:13 PM 
Dear AllOne of my students, Anton Brida, has developed an Attribute Mapping GUIfor Horizon as part of his MSc project. Attribute mappings are anessential, though complex, part of federated Keystone. Currently theycan only be created as JSON objects in the config file. The Horizon codeallows them to be dynamically created via an easy to use GUI.Since Anton has now left the university for full time employment, he isnot able to go through the process of submitting his code to the nextrelease of Horizon. His design however was submitted to InVision andcommented on by various people at the time of the development.I am now looking for someone who would like to take a copy of this codeand go through the process of submitting this to the next release ofHorizon. I have a copy of Anton's MSc dissertation as well whichexplains the work that he has done.All the attribute mapping features are supported in Anton's code(groups, users, direct mapping, multiple attribute values etc.)However the whitelist/blacklist feature is not, since this was not fullyincorporated into Keystone when Anton was doing his implementation. (Iam still not sure if it has been.)The code has a couple of known bugs:1. when a user tries to enter an email address into an attribute value(i.e. usern...@example.com) and saves the mapping rule into thedatabase, after reloading the new list of mappings rules the interfacedoes not work as intended. The particular reason why this is happeningis yet unknown. The only way to avoid such disruption is to delete thefaulty mapping rule from the table. After removing the faulty rule theinterface works as intended.2. Some of the descriptive text needs improvement due to incorrect grammar.There is also the following suggested enhancement which can be added later:1. After the mapping rules are created with the GUI, when they aredisplayed, they are still in JSON format. It would be nice to be able todisplay the rules in a table or similar.If you would like to take on the job of submitting this code to Horizonfor review and incorporation, please contact meregardsDavid__OpenStack Development Mailing List (not for usage questions)Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev 


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [horizon][keystone]

[Adam Young]

On 10/07/2015 11:51 AM, Adam Young wrote:
Send me what you have, and I will post it as a Work in progress review 
against Horizon.  That way at least it will be available for others to 
look at and potentially adopt.


Review has been posted here
https://review.openstack.org/232114


I made a best guess as far as where it it should be placed in the source 
tree.  I have not tested the code.


David and I have both signed the CLA. I am fairly certon Anton did not.  
It would be easiest for OpenStack to accept this code if he did, as 
there would be no question about copyright or licensing.


David also provided me with a PDF version of Anton's dissertation. I do 
not know what the status of that document, but it would be a great 
resource to anyone that wants to take this code and get it integrated 
into Horizon.


This does not look like a radical stretch.  It would be a decent 
opportunity for anyone looking to get involved with OpenStack to step 
into something immediately.









On 10/07/2015 11:37 AM, David Chadwick wrote:

Hi Douglas

we are happy for you (or someone else) to submit the code in 3 names:
theirs, mine and Anton's. Then this third person can do all the work
necessary to get it approved. In this way it is legitimate, since the
third person will have contributed to the overall effort.

I dont have any spare time yet for another month or so. After that I
could submit it, but having never done it before for Horizon, there will
be a big learning curve. And I might not have time to learn it

regards

David

On 07/10/2015 16:05, Douglas Fish wrote:

Hi David,
  This sounds like a great set of code, I'm sure we are going to 
realize

we want it sooner or later! Unfortunately I can't consume code in this
way (I can't propose code written by somebody else) and I can't spend
significant time on it right now.
  Would you or Anton be willing to propose whatever code and 
documentation

you have to Horizon? It doesn't have to be complete; it doesn't need to
have grammar cleaned up or anything like that. You could mark it as a
"Work in progress", and make it clear in the commit message that you
aren't planning further work on this, so the patch is available for
adoption. That way somebody else may be able to pick this up and 
work on

it in the future, but Anton could get credit for the work he has done.

Doug Fish

 - Original message -
 From: David Chadwick <d.w.chadw...@kent.ac.uk>
 To: OpenStack Development Mailing List
 <openstack-dev@lists.openstack.org>
     Cc:
     Subject: [openstack-dev] [horizon][keystone]
 Date: Tue, Oct 6, 2015 2:13 PM
   Dear All

 One of my students, Anton Brida, has developed an Attribute 
Mapping GUI

 for Horizon as part of his MSc project. Attribute mappings are an
 essential, though complex, part of federated Keystone. 
Currently they
 can only be created as JSON objects in the config file. The 
Horizon code

 allows them to be dynamically created via an easy to use GUI.

 Since Anton has now left the university for full time 
employment, he is
 not able to go through the process of submitting his code to 
the next
 release of Horizon. His design however was submitted to 
InVision and

 commented on by various people at the time of the development.

 I am now looking for someone who would like to take a copy of 
this code
 and go through the process of submitting this to the next 
release of

 Horizon. I have a copy of Anton's MSc dissertation as well which
 explains the work that he has done.

 All the attribute mapping features are supported in Anton's code
 (groups, users, direct mapping, multiple attribute values etc.)
 However the whitelist/blacklist feature is not, since this was 
not fully
 incorporated into Keystone when Anton was doing his 
implementation. (I

 am still not sure if it has been.)

 The code has a couple of known bugs:

 1. when a user tries to enter an email address into an 
attribute value

 (i.e. usern...@example.com) and saves the mapping rule into the
 database, after reloading the new list of mappings rules the 
interface
 does not work as intended. The particular reason why this is 
happening
 is yet unknown. The only way to avoid such disruption is to 
delete the
 faulty mapping rule from the table. After removing the faulty 
rule the

 interface works as intended.

 2. Some of the descriptive text needs improvement due to incorrect
 grammar.

 There is also the following suggested enhancement which can be 
added

 later:

 1. After the mapping rules are created with the GUI, when they are
 displayed, they are still in JSON format. It would be nice to 
be able to

 display the rules in a table or similar.

 If you would like to take on the job of submitting this code to 
Horizon

 for review and incorporation, please contact me

  

Re: [openstack-dev] [horizon][keystone]

[Adam Young]

Send me what you have, and I will post it as a Work in progress review 
against Horizon.  That way at least it will be available for others to 
look at and potentially adopt.




On 10/07/2015 11:37 AM, David Chadwick wrote:

Hi Douglas

we are happy for you (or someone else) to submit the code in 3 names:
theirs, mine and Anton's. Then this third person can do all the work
necessary to get it approved. In this way it is legitimate, since the
third person will have contributed to the overall effort.

I dont have any spare time yet for another month or so. After that I
could submit it, but having never done it before for Horizon, there will
be a big learning curve. And I might not have time to learn it

regards

David

On 07/10/2015 16:05, Douglas Fish wrote:

Hi David,
  
This sounds like a great set of code, I'm sure we are going to realize

we want it sooner or later! Unfortunately I can't consume code in this
way (I can't propose code written by somebody else) and I can't spend
significant time on it right now.
  
Would you or Anton be willing to propose whatever code and documentation

you have to Horizon? It doesn't have to be complete; it doesn't need to
have grammar cleaned up or anything like that. You could mark it as a
"Work in progress", and make it clear in the commit message that you
aren't planning further work on this, so the patch is available for
adoption. That way somebody else may be able to pick this up and work on
it in the future, but Anton could get credit for the work he has done.

Doug Fish
  
  


 - Original message -
 From: David Chadwick <d.w.chadw...@kent.ac.uk>
 To: OpenStack Development Mailing List
 <openstack-dev@lists.openstack.org>
     Cc:
     Subject: [openstack-dev] [horizon][keystone]
 Date: Tue, Oct 6, 2015 2:13 PM
  
 Dear All


 One of my students, Anton Brida, has developed an Attribute Mapping GUI
 for Horizon as part of his MSc project. Attribute mappings are an
 essential, though complex, part of federated Keystone. Currently they
 can only be created as JSON objects in the config file. The Horizon code
 allows them to be dynamically created via an easy to use GUI.

 Since Anton has now left the university for full time employment, he is
 not able to go through the process of submitting his code to the next
 release of Horizon. His design however was submitted to InVision and
 commented on by various people at the time of the development.

 I am now looking for someone who would like to take a copy of this code
 and go through the process of submitting this to the next release of
 Horizon. I have a copy of Anton's MSc dissertation as well which
 explains the work that he has done.

 All the attribute mapping features are supported in Anton's code
 (groups, users, direct mapping, multiple attribute values etc.)
 However the whitelist/blacklist feature is not, since this was not fully
 incorporated into Keystone when Anton was doing his implementation. (I
 am still not sure if it has been.)

 The code has a couple of known bugs:

 1. when a user tries to enter an email address into an attribute value
 (i.e. usern...@example.com) and saves the mapping rule into the
 database, after reloading the new list of mappings rules the interface
 does not work as intended. The particular reason why this is happening
 is yet unknown. The only way to avoid such disruption is to delete the
 faulty mapping rule from the table. After removing the faulty rule the
 interface works as intended.

 2. Some of the descriptive text needs improvement due to incorrect
 grammar.

 There is also the following suggested enhancement which can be added
 later:

 1. After the mapping rules are created with the GUI, when they are
 displayed, they are still in JSON format. It would be nice to be able to
 display the rules in a table or similar.

 If you would like to take on the job of submitting this code to Horizon
 for review and incorporation, please contact me

 regards

 David

 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe:
 openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
  





__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists

Re: [openstack-dev] [horizon][keystone]

[David Chadwick]

Hi Douglas

we are happy for you (or someone else) to submit the code in 3 names:
theirs, mine and Anton's. Then this third person can do all the work
necessary to get it approved. In this way it is legitimate, since the
third person will have contributed to the overall effort.

I dont have any spare time yet for another month or so. After that I
could submit it, but having never done it before for Horizon, there will
be a big learning curve. And I might not have time to learn it

regards

David

On 07/10/2015 16:05, Douglas Fish wrote:
> Hi David,
>  
> This sounds like a great set of code, I'm sure we are going to realize
> we want it sooner or later! Unfortunately I can't consume code in this
> way (I can't propose code written by somebody else) and I can't spend
> significant time on it right now.
>  
> Would you or Anton be willing to propose whatever code and documentation
> you have to Horizon? It doesn't have to be complete; it doesn't need to
> have grammar cleaned up or anything like that. You could mark it as a
> "Work in progress", and make it clear in the commit message that you
> aren't planning further work on this, so the patch is available for
> adoption. That way somebody else may be able to pick this up and work on
> it in the future, but Anton could get credit for the work he has done.
> 
> Doug Fish
>  
>  
> 
> - Original message -
> From: David Chadwick <d.w.chadw...@kent.ac.uk>
> To: OpenStack Development Mailing List
> <openstack-dev@lists.openstack.org>
> Cc:
> Subject: [openstack-dev] [horizon][keystone]
> Date: Tue, Oct 6, 2015 2:13 PM
>  
> Dear All
> 
> One of my students, Anton Brida, has developed an Attribute Mapping GUI
> for Horizon as part of his MSc project. Attribute mappings are an
> essential, though complex, part of federated Keystone. Currently they
> can only be created as JSON objects in the config file. The Horizon code
> allows them to be dynamically created via an easy to use GUI.
> 
> Since Anton has now left the university for full time employment, he is
> not able to go through the process of submitting his code to the next
> release of Horizon. His design however was submitted to InVision and
> commented on by various people at the time of the development.
> 
> I am now looking for someone who would like to take a copy of this code
> and go through the process of submitting this to the next release of
> Horizon. I have a copy of Anton's MSc dissertation as well which
> explains the work that he has done.
> 
> All the attribute mapping features are supported in Anton's code
> (groups, users, direct mapping, multiple attribute values etc.)
> However the whitelist/blacklist feature is not, since this was not fully
> incorporated into Keystone when Anton was doing his implementation. (I
> am still not sure if it has been.)
> 
> The code has a couple of known bugs:
> 
> 1. when a user tries to enter an email address into an attribute value
> (i.e. usern...@example.com) and saves the mapping rule into the
> database, after reloading the new list of mappings rules the interface
> does not work as intended. The particular reason why this is happening
> is yet unknown. The only way to avoid such disruption is to delete the
> faulty mapping rule from the table. After removing the faulty rule the
> interface works as intended.
> 
> 2. Some of the descriptive text needs improvement due to incorrect
> grammar.
> 
> There is also the following suggested enhancement which can be added
> later:
> 
> 1. After the mapping rules are created with the GUI, when they are
> displayed, they are still in JSON format. It would be nice to be able to
> display the rules in a table or similar.
> 
> If you would like to take on the job of submitting this code to Horizon
> for review and incorporation, please contact me
> 
> regards
> 
> David
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>  
> 
> 
> 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [horizon][keystone]

[David Chadwick]

Hi Adam

will do (by separate email, so that the list does not receive it)

thanks

David

On 07/10/2015 16:51, Adam Young wrote:
> Send me what you have, and I will post it as a Work in progress review
> against Horizon.  That way at least it will be available for others to
> look at and potentially adopt.
> 
> 
> 
> On 10/07/2015 11:37 AM, David Chadwick wrote:
>> Hi Douglas
>>
>> we are happy for you (or someone else) to submit the code in 3 names:
>> theirs, mine and Anton's. Then this third person can do all the work
>> necessary to get it approved. In this way it is legitimate, since the
>> third person will have contributed to the overall effort.
>>
>> I dont have any spare time yet for another month or so. After that I
>> could submit it, but having never done it before for Horizon, there will
>> be a big learning curve. And I might not have time to learn it
>>
>> regards
>>
>> David
>>
>> On 07/10/2015 16:05, Douglas Fish wrote:
>>> Hi David,
>>>   This sounds like a great set of code, I'm sure we are going to realize
>>> we want it sooner or later! Unfortunately I can't consume code in this
>>> way (I can't propose code written by somebody else) and I can't spend
>>> significant time on it right now.
>>>   Would you or Anton be willing to propose whatever code and
>>> documentation
>>> you have to Horizon? It doesn't have to be complete; it doesn't need to
>>> have grammar cleaned up or anything like that. You could mark it as a
>>> "Work in progress", and make it clear in the commit message that you
>>> aren't planning further work on this, so the patch is available for
>>> adoption. That way somebody else may be able to pick this up and work on
>>> it in the future, but Anton could get credit for the work he has done.
>>>
>>> Doug Fish
>>>
>>>  - Original message -
>>>  From: David Chadwick <d.w.chadw...@kent.ac.uk>
>>>  To: OpenStack Development Mailing List
>>>  <openstack-dev@lists.openstack.org>
>>>  Cc:
>>>  Subject: [openstack-dev] [horizon][keystone]
>>>  Date: Tue, Oct 6, 2015 2:13 PM
>>>Dear All
>>>
>>>  One of my students, Anton Brida, has developed an Attribute
>>> Mapping GUI
>>>  for Horizon as part of his MSc project. Attribute mappings are an
>>>  essential, though complex, part of federated Keystone. Currently
>>> they
>>>  can only be created as JSON objects in the config file. The
>>> Horizon code
>>>  allows them to be dynamically created via an easy to use GUI.
>>>
>>>  Since Anton has now left the university for full time
>>> employment, he is
>>>  not able to go through the process of submitting his code to the
>>> next
>>>  release of Horizon. His design however was submitted to InVision
>>> and
>>>  commented on by various people at the time of the development.
>>>
>>>  I am now looking for someone who would like to take a copy of
>>> this code
>>>  and go through the process of submitting this to the next
>>> release of
>>>  Horizon. I have a copy of Anton's MSc dissertation as well which
>>>  explains the work that he has done.
>>>
>>>  All the attribute mapping features are supported in Anton's code
>>>  (groups, users, direct mapping, multiple attribute values etc.)
>>>  However the whitelist/blacklist feature is not, since this was
>>> not fully
>>>  incorporated into Keystone when Anton was doing his
>>> implementation. (I
>>>  am still not sure if it has been.)
>>>
>>>  The code has a couple of known bugs:
>>>
>>>  1. when a user tries to enter an email address into an attribute
>>> value
>>>  (i.e. usern...@example.com) and saves the mapping rule into the
>>>  database, after reloading the new list of mappings rules the
>>> interface
>>>  does not work as intended. The particular reason why this is
>>> happening
>>>  is yet unknown. The only way to avoid such disruption is to
>>> delete the
>>>  faulty mapping rule from the table. After removing the faulty
>>> rule the
>>>  interface works as intended.
>>>
>>>  2. Some of the descriptive text needs improvement due to incorrect
>>>  grammar.
>>>
>&

Re: [openstack-dev] [horizon][keystone]

[David Chadwick]

On 07/10/2015 18:29, Adam Young wrote:
> On 10/07/2015 11:51 AM, Adam Young wrote:
>> Send me what you have, and I will post it as a Work in progress review
>> against Horizon.  That way at least it will be available for others to
>> look at and potentially adopt.
> 
> Review has been posted here
> https://review.openstack.org/232114
> 

thanks Adam

> 
> I made a best guess as far as where it it should be placed in the source
> tree.  I have not tested the code.
> 
> David and I have both signed the CLA. I am fairly certon Anton did not. 
> It would be easiest for OpenStack to accept this code if he did, as
> there would be no question about copyright or licensing.

Legally speaking it is not necessary, since any code produced by
students as part of their degree course does not belong to them.
However, it would be courteous of us to ask him, so I have done this.

> 
> David also provided me with a PDF version of Anton's dissertation. I do
> not know what the status of that document, but it would be a great
> resource to anyone that wants to take this code and get it integrated
> into Horizon.

This can be made publicly available after the exam board next month.
Until then I will give out personal copies for private study.

regards

David

> 
> This does not look like a radical stretch.  It would be a decent
> opportunity for anyone looking to get involved with OpenStack to step
> into something immediately.
> 
> 
> 
> 
>>
>>
>>
>> On 10/07/2015 11:37 AM, David Chadwick wrote:
>>> Hi Douglas
>>>
>>> we are happy for you (or someone else) to submit the code in 3 names:
>>> theirs, mine and Anton's. Then this third person can do all the work
>>> necessary to get it approved. In this way it is legitimate, since the
>>> third person will have contributed to the overall effort.
>>>
>>> I dont have any spare time yet for another month or so. After that I
>>> could submit it, but having never done it before for Horizon, there will
>>> be a big learning curve. And I might not have time to learn it
>>>
>>> regards
>>>
>>> David
>>>
>>> On 07/10/2015 16:05, Douglas Fish wrote:
>>>> Hi David,
>>>>   This sounds like a great set of code, I'm sure we are going to
>>>> realize
>>>> we want it sooner or later! Unfortunately I can't consume code in this
>>>> way (I can't propose code written by somebody else) and I can't spend
>>>> significant time on it right now.
>>>>   Would you or Anton be willing to propose whatever code and
>>>> documentation
>>>> you have to Horizon? It doesn't have to be complete; it doesn't need to
>>>> have grammar cleaned up or anything like that. You could mark it as a
>>>> "Work in progress", and make it clear in the commit message that you
>>>> aren't planning further work on this, so the patch is available for
>>>> adoption. That way somebody else may be able to pick this up and
>>>> work on
>>>> it in the future, but Anton could get credit for the work he has done.
>>>>
>>>> Doug Fish
>>>>
>>>>  - Original message -
>>>>  From: David Chadwick <d.w.chadw...@kent.ac.uk>
>>>>  To: OpenStack Development Mailing List
>>>>  <openstack-dev@lists.openstack.org>
>>>>  Cc:
>>>>  Subject: [openstack-dev] [horizon][keystone]
>>>>  Date: Tue, Oct 6, 2015 2:13 PM
>>>>Dear All
>>>>
>>>>  One of my students, Anton Brida, has developed an Attribute
>>>> Mapping GUI
>>>>  for Horizon as part of his MSc project. Attribute mappings are an
>>>>  essential, though complex, part of federated Keystone.
>>>> Currently they
>>>>  can only be created as JSON objects in the config file. The
>>>> Horizon code
>>>>  allows them to be dynamically created via an easy to use GUI.
>>>>
>>>>  Since Anton has now left the university for full time
>>>> employment, he is
>>>>  not able to go through the process of submitting his code to
>>>> the next
>>>>  release of Horizon. His design however was submitted to
>>>> InVision and
>>>>  commented on by various people at the time of the development.
>>>>
>>>>  I am now looking for someone who would like to take a copy of
>>>> this code
>>>>  and 

[openstack-dev] [horizon][keystone]

[David Chadwick]

Dear All

One of my students, Anton Brida, has developed an Attribute Mapping GUI
for Horizon as part of his MSc project. Attribute mappings are an
essential, though complex, part of federated Keystone. Currently they
can only be created as JSON objects in the config file. The Horizon code
allows them to be dynamically created via an easy to use GUI.

Since Anton has now left the university for full time employment, he is
not able to go through the process of submitting his code to the next
release of Horizon. His design however was submitted to InVision and
commented on by various people at the time of the development.

I am now looking for someone who would like to take a copy of this code
and go through the process of submitting this to the next release of
Horizon. I have a copy of Anton's MSc dissertation as well which
explains the work that he has done.

All the attribute mapping features are supported in Anton's code
(groups, users, direct mapping, multiple attribute values etc.)
However the whitelist/blacklist feature is not, since this was not fully
incorporated into Keystone when Anton was doing his implementation. (I
am still not sure if it has been.)

The code has a couple of known bugs:

1. when a user tries to enter an email address into an attribute value
(i.e. usern...@example.com) and saves the mapping rule into the
database, after reloading the new list of mappings rules the interface
does not work as intended. The particular reason why this is happening
is yet unknown. The only way to avoid such disruption is to delete the
faulty mapping rule from the table. After removing the faulty rule the
interface works as intended.

2. Some of the descriptive text needs improvement due to incorrect grammar.

There is also the following suggested enhancement which can be added later:

1. After the mapping rules are created with the GUI, when they are
displayed, they are still in JSON format. It would be nice to be able to
display the rules in a table or similar.

If you would like to take on the job of submitting this code to Horizon
for review and incorporation, please contact me

regards

David

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [horizon] [keystone] [docs] Two kinds of 'region' entity: finding better names for them

[Timur Sufiev]

I went forward and filed a bug for this issue (since we agreed that it
should be fixed): https://bugs.launchpad.net/horizon/+bug/1494251
The code is already in gerrit (see links in bug), feel free to review.

On Fri, Jul 10, 2015 at 1:51 AM Douglas Fish <drf...@us.ibm.com> wrote:

> I think another important question is how to represent this to the user on
> the login screen. "Keystone Endpoint:" matches the setting, but seems like
> a weird choice to me. Is there a better terminology to use for the label
> for this on the login screen?
>
> I see the related selector has no label at all in the header. Maybe using
> the same label there would be a good idea.
>
> Doug
>
> Thai Q Tran/Silicon Valley/IBM@IBMUS wrote on 07/08/2015 01:05:53 PM:
>
> > From: Thai Q Tran/Silicon Valley/IBM@IBMUS
> > To: "OpenStack Development Mailing List \(not for usage questions\)"
> > <openstack-dev@lists.openstack.org>
> > Date: 07/09/2015 01:17 PM
> > Subject: Re: [openstack-dev] [horizon] [keystone] [docs] Two kinds
> > of 'region' entity: finding better names for them
> >
> > Had the same issue when I worked on the context selection menu for
> > switching domain and project. I think it make sense to rename it to
> > AVAILABLE_KEYSTONE_ENDPOINTS. Since it is local_settings.py, its
> > going to affect some folks (maybe even break) until they also update
> > their setting, something that would have to be done manually.
> >
> > -Jay Pipes <jaypi...@gmail.com> wrote: -----
> > To: openstack-dev@lists.openstack.org
> > From: Jay Pipes <jaypi...@gmail.com>
> > Date: 07/08/2015 07:14AM
> > Subject: Re: [openstack-dev] [horizon] [keystone] [docs] Two kinds
> > of 'region' entity: finding better names for them
>
> > Got it, thanks for the excellent explanation, Timur! Yeah, I think
> > renaming to AVAILABLE_KEYSTONE_ENDPOINTS would be a good solution.
> >
> > Best,
> > -jay
> >
> > On 07/08/2015 09:53 AM, Timur Sufiev wrote:
> > > Hi, Jay!
> > >
> > > As Doug said, Horizon regions are just different Keystone endpoints
> that
> > > Horizon could use to authorize against (and retrieve the whole catalog
> > > from any of them afterwards).
> > >
> > > Another example of how complicated things could be: imagine that
> Horizon
> > > config has two Keystone endpoints inside AVAILABLE_REGIONS setting,
> > > http://keystone.europe and http://keystone.asia, each of them hosting
> a
> > > different catalog with service endpoint pointing to Europe/Asia located
> > > services. For European Keystone all Europe-based services are marked as
> > > 'RegionOne', for Asian Keystone all its Asia-based services are marked
> > > as 'RegionOne'. Then, imagine that each Keystone also has 'RegionTwo'
> > > region, for European Keystone the Asian services are marked so, for
> > > Asian Keystone the opposite is true. One of customers did roughly the
> > > same thing (with both Keystones using common LDAP backend), and
> > > understanding what exactly in Horizon didn't work well was a puzzling
> > > experience.
> > >
> > > On Wed, Jul 8, 2015 at 4:37 PM Jay Pipes <jaypi...@gmail.com
> > > <mailto:jaypi...@gmail.com>> wrote:
> > >
> > > On 07/08/2015 08:50 AM, Timur Sufiev wrote:
> > >  > Hello, folks!
> > >  >
> > >  > Somehow it happened that we have 2 different kinds of regions:
> the
> > >  > service regions inside Keystone catalog and AVAILABLE_REGIONS
> setting
> > >  > inside Horizon, yet use the same name 'regions' for both of
> them.
> > > That
> > >  > creates a lot of confusion when solving some
> region-relatedissues at
> > >  > the Horizon/Keystone junction, even explaining what is exactly
> being
> > >  > broken poses a serious challenge when our common language has
> > > such a flaw!
> > >  >
> > >  > I propose to invent 2 distinct terms for these entities, so at
> > > least we
> > >  > won't be terminologically challenged when fixing the related
> bugs.
> > >
> > > Hi!
> > >
> > > I understand what the Keystone region represents: a simple,
> > > non-geographically-connotated division of the entire OpenStack
> > > deployment.
> > >
> > > Unfortunately, I don't know what the Horizon regions represent.
> Could
> > > you explain?
> > >

Re: [openstack-dev] [horizon] [keystone] [docs] Two kinds of 'region' entity: finding better names for them

[Douglas Fish]

I think another important question is how to represent this to the user on
the login screen. Keystone Endpoint: matches the setting, but seems like
a weird choice to me. Is there a better terminology to use for the label
for this on the login screen?

I see the related selector has no label at all in the header. Maybe using
the same label there would be a good idea.

Doug

Thai Q Tran/Silicon Valley/IBM@IBMUS wrote on 07/08/2015 01:05:53 PM:

 From: Thai Q Tran/Silicon Valley/IBM@IBMUS
 To: OpenStack Development Mailing List \(not for usage questions\)
 openstack-dev@lists.openstack.org
 Date: 07/09/2015 01:17 PM
 Subject: Re: [openstack-dev] [horizon] [keystone] [docs] Two kinds
 of 'region' entity: finding better names for them

 Had the same issue when I worked on the context selection menu for
 switching domain and project. I think it make sense to rename it to
 AVAILABLE_KEYSTONE_ENDPOINTS. Since it is local_settings.py, its
 going to affect some folks (maybe even break) until they also update
 their setting, something that would have to be done manually.

 -Jay Pipes jaypi...@gmail.com wrote: -
 To: openstack-dev@lists.openstack.org
 From: Jay Pipes jaypi...@gmail.com
 Date: 07/08/2015 07:14AM
 Subject: Re: [openstack-dev] [horizon] [keystone] [docs] Two kinds
 of 'region' entity: finding better names for them

 Got it, thanks for the excellent explanation, Timur! Yeah, I think
 renaming to AVAILABLE_KEYSTONE_ENDPOINTS would be a good solution.

 Best,
 -jay

 On 07/08/2015 09:53 AM, Timur Sufiev wrote:
  Hi, Jay!
 
  As Doug said, Horizon regions are just different Keystone endpoints
that
  Horizon could use to authorize against (and retrieve the whole catalog
  from any of them afterwards).
 
  Another example of how complicated things could be: imagine that
Horizon
  config has two Keystone endpoints inside AVAILABLE_REGIONS setting,
  http://keystone.europe and http://keystone.asia, each of them hosting a
  different catalog with service endpoint pointing to Europe/Asia located
  services. For European Keystone all Europe-based services are marked as
  'RegionOne', for Asian Keystone all its Asia-based services are marked
  as 'RegionOne'. Then, imagine that each Keystone also has 'RegionTwo'
  region, for European Keystone the Asian services are marked so, for
  Asian Keystone the opposite is true. One of customers did roughly the
  same thing (with both Keystones using common LDAP backend), and
  understanding what exactly in Horizon didn't work well was a puzzling
  experience.
 
  On Wed, Jul 8, 2015 at 4:37 PM Jay Pipes jaypi...@gmail.com
  mailto:jaypi...@gmail.com wrote:
 
  On 07/08/2015 08:50 AM, Timur Sufiev wrote:
Hello, folks!
   
Somehow it happened that we have 2 different kinds of regions:
the
service regions inside Keystone catalog and AVAILABLE_REGIONS
setting
inside Horizon, yet use the same name 'regions' for both of
them.
  That
creates a lot of confusion when solving some
region-relatedissues at
the Horizon/Keystone junction, even explaining what is exactly
being
broken poses a serious challenge when our common language has
  such a flaw!
   
I propose to invent 2 distinct terms for these entities, so at
  least we
won't be terminologically challenged when fixing the related
bugs.
 
  Hi!
 
  I understand what the Keystone region represents: a simple,
  non-geographically-connotated division of the entire OpenStack
  deployment.
 
  Unfortunately, I don't know what the Horizon regions represent.
Could
  you explain?
 
  Best,
  -jay
 
 

__
  OpenStack Development Mailing List (not for usage questions)
  Unsubscribe:
  openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 
http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 
 
 
 
__
  OpenStack Development Mailing List (not for usage questions)
  Unsubscribe:
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 


__
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe:
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe:
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__
OpenStack Development

Re: [openstack-dev] [horizon] [keystone] [docs] Two kinds of 'region' entity: finding better names for them

[Timur Sufiev]

Hi, Jay!

As Doug said, Horizon regions are just different Keystone endpoints that
Horizon could use to authorize against (and retrieve the whole catalog from
any of them afterwards).

Another example of how complicated things could be: imagine that Horizon
config has two Keystone endpoints inside AVAILABLE_REGIONS setting,
http://keystone.europe and http://keystone.asia, each of them hosting a
different catalog with service endpoint pointing to Europe/Asia located
services. For European Keystone all Europe-based services are marked as
'RegionOne', for Asian Keystone all its Asia-based services are marked as
'RegionOne'. Then, imagine that each Keystone also has 'RegionTwo' region,
for European Keystone the Asian services are marked so, for Asian Keystone
the opposite is true. One of customers did roughly the same thing (with
both Keystones using common LDAP backend), and understanding what exactly
in Horizon didn't work well was a puzzling experience.

On Wed, Jul 8, 2015 at 4:37 PM Jay Pipes jaypi...@gmail.com wrote:

 On 07/08/2015 08:50 AM, Timur Sufiev wrote:
  Hello, folks!
 
  Somehow it happened that we have 2 different kinds of regions: the
  service regions inside Keystone catalog and AVAILABLE_REGIONS setting
  inside Horizon, yet use the same name 'regions' for both of them. That
  creates a lot of confusion when solving some region-related issues at
  the Horizon/Keystone junction, even explaining what is exactly being
  broken poses a serious challenge when our common language has such a
 flaw!
 
  I propose to invent 2 distinct terms for these entities, so at least we
  won't be terminologically challenged when fixing the related bugs.

 Hi!

 I understand what the Keystone region represents: a simple,
 non-geographically-connotated division of the entire OpenStack deployment.

 Unfortunately, I don't know what the Horizon regions represent. Could
 you explain?

 Best,
 -jay

 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [horizon][keystone][heat] Are AVAILABLE_REGIONS and multi-region service catalog mutually exclusive?

[Douglas Fish]

Anne Gentle annegen...@justwriteclick.com wrote on 05/14/2015 09:47:25
AM:

 From: Anne Gentle annegen...@justwriteclick.com
 To: OpenStack Development Mailing List (not for usage questions)
 openstack-dev@lists.openstack.org
 Date: 05/14/2015 10:08 AM
 Subject: Re: [openstack-dev] [horizon][keystone][heat] Are
 AVAILABLE_REGIONS and multi-region service catalog mutually exclusive?

 On Thu, May 14, 2015 at 9:39 AM, Geoff Arnold ge...@geoffarnold.com
wrote:
 +1

 There seems to be a significant disconnect between Heat, Horizon and
 Keystone on the subject of multi-region configurations, and the
 documentation isn’t helpful. At the very least, it would be useful
 if discussions at the summit could result in a decent Wiki page on
 the subject.

 We have a cross-project session and spec started about the service
catalog:

 https://review.openstack.org/#/c/181393/

 http://sched.co/3BL3

 I hope more than a wiki page comes of it. :)
 Anne


 Geoff

 On May 13, 2015, at 9:49 PM, Morgan Fainberg morgan.fainb...@gmail.com
  wrote:


 On May 13, 2015, at 21:34, David Lyle dkly...@gmail.com wrote:


 On Wed, May 13, 2015 at 3:24 PM, Mathieu Gagné mga...@iweb.com wrote:
 When using AVAILABLE_REGIONS, you get a dropdown at login time to choose
 your region which is in fact your keystone endpoint.

 Once logged in, you get a new dropdown at the top right to switch
 between the keystone endpoints. This means you can configure an
 Horizon installation to login to multiple independent OpenStack
 installations.

 So I don't fully understand what enhancing the multi-region support in
 Keystone would mean. Would you be able to configure Horizon to login to
 multiple independent OpenStack installations?

 Mathieu

 On 2015-05-13 5:06 PM, Geoff Arnold wrote:
  Further digging suggests that we might consider deprecating
  AVAILABLE_REGIONS in Horizon and enhancing the multi-region support in
  Keystone. It wouldn’t take a lot; the main points:
 
    * Implement the Regions API discussed back in the Havana time period
      - https://etherpad.openstack.org/p/havana-availability-zone-
 and-region-management -
      but with full CRUD
    * Enhance the Endpoints API to allow filtering by region
 
  Supporting two different multi region models is problematic if we’re
  serious about things like multi-region Heat.
 
  Thoughts?
 
  Geoff
 
  On May 13, 2015, at 12:01 PM, Geoff Arnold ge...@geoffarnold.com
  mailto:ge...@geoffarnold.com wrote:
 
  I’m looking at implementing dynamically-configured multi-region
  support for service federation, and the prior art on multi-region
  support in Horizon is pretty sketchy. This thread:
 
http://lists.openstack.org/pipermail/openstack/2014-January/004372.html
  is the only real discussion I’ve found, and it’s pretty inconclusive.
 
  More precisely, if I configure a single Horizon with AVAILABLE_REGIONS
  pointing at two different Keystones with region names “X” and “Y, and
  each of those Keystones returns a service catalog with multiple
  regions (“A” and “B” for one, “P”, “Q”, and “R” for the other), what’s
  Horizon going to do? Or rather, what’s it expected to do?
 
  Yes, I’m being lazy: I could actually configure this to see what
  happens, but hopefully it was considered during the design.
 
  Geoff
 
  PS I’ve added Heat to the subject, because from a quick read of
  https://wiki.openstack.org/wiki/Heat/Blueprints/
 Multi_Region_Support_for_Heat
  it looks as if Heat won’t support the AVAILABLE_REGIONS model. That
  seems like an unfortunate disconnect.
 
 
 

 Horizon only supports authenticating to one keystone endpoint at a
 time, specifically to one of the entries in AVAILABLE_REGIONS as
 defined in settings.py. Once you have an authenticated session in
 Horizon, the region selection support is merely for filtering
 between regions registered with the keystone endpoint you
 authenticated to, where the list of regions is determined by parsing
 the service catalog returned to you with your token.

 What's really unclear to me is what you are intending to ask.

 AVAILABLE_REGIONS is merely a list of keystone endpoints. They can
 be backed by a different IdP per endpoint and thus not share a token
 store. Or, they can just be keystone endpoints that are
 geographically different but backed by the same IdP, which may or
 may not share a token store. The funny thing is, for Horizon, it
 doesn't matter. They are all supported.  But as one keystone
 endpoint may not know about another, unless nested, this has to be
 done with settings as it's not typically discoverable.

 If you are asking about token sharing between keystones which the
 thread you linked seems to indicate. Then yes, you can have a synced
 token store. But that is an exercise left to the operator.

 I'd like to quickly go on record and say that a token store sync
 like this is not recommended. It is possible to work around this in
 Kilo with some limited data sync (resource, assignment) and the use
 of Fernet tokens

Re: [openstack-dev] [horizon][keystone][heat] Are AVAILABLE_REGIONS and multi-region service catalog mutually exclusive?

[Geoff Arnold]

+1

There seems to be a significant disconnect between Heat, Horizon and Keystone 
on the subject of multi-region configurations, and the documentation isn’t 
helpful. At the very least, it would be useful if discussions at the summit 
could result in a decent Wiki page on the subject.

Geoff

 On May 13, 2015, at 9:49 PM, Morgan Fainberg morgan.fainb...@gmail.com 
 wrote:
 
 
 
 On May 13, 2015, at 21:34, David Lyle dkly...@gmail.com 
 mailto:dkly...@gmail.com wrote:
 
 
 On Wed, May 13, 2015 at 3:24 PM, Mathieu Gagné mga...@iweb.com 
 mailto:mga...@iweb.com wrote:
 When using AVAILABLE_REGIONS, you get a dropdown at login time to choose
 your region which is in fact your keystone endpoint.
 
 Once logged in, you get a new dropdown at the top right to switch
 between the keystone endpoints. This means you can configure an
 Horizon installation to login to multiple independent OpenStack
 installations.
 
 So I don't fully understand what enhancing the multi-region support in
 Keystone would mean. Would you be able to configure Horizon to login to
 multiple independent OpenStack installations?
 
 Mathieu
 
 On 2015-05-13 5:06 PM, Geoff Arnold wrote:
  Further digging suggests that we might consider deprecating
  AVAILABLE_REGIONS in Horizon and enhancing the multi-region support in
  Keystone. It wouldn’t take a lot; the main points:
 
* Implement the Regions API discussed back in the Havana time period
  - 
  https://etherpad.openstack.org/p/havana-availability-zone-and-region-management
   
  https://etherpad.openstack.org/p/havana-availability-zone-and-region-management
   -
  but with full CRUD
* Enhance the Endpoints API to allow filtering by region
 
  Supporting two different multi region models is problematic if we’re
  serious about things like multi-region Heat.
 
  Thoughts?
 
  Geoff
 
  On May 13, 2015, at 12:01 PM, Geoff Arnold ge...@geoffarnold.com 
  mailto:ge...@geoffarnold.com
  mailto:ge...@geoffarnold.com mailto:ge...@geoffarnold.com wrote:
 
  I’m looking at implementing dynamically-configured multi-region
  support for service federation, and the prior art on multi-region
  support in Horizon is pretty sketchy. This thread:
  http://lists.openstack.org/pipermail/openstack/2014-January/004372.html 
  http://lists.openstack.org/pipermail/openstack/2014-January/004372.html
  is the only real discussion I’ve found, and it’s pretty inconclusive.
 
  More precisely, if I configure a single Horizon with AVAILABLE_REGIONS
  pointing at two different Keystones with region names “X” and “Y, and
  each of those Keystones returns a service catalog with multiple
  regions (“A” and “B” for one, “P”, “Q”, and “R” for the other), what’s
  Horizon going to do? Or rather, what’s it expected to do?
 
  Yes, I’m being lazy: I could actually configure this to see what
  happens, but hopefully it was considered during the design.
 
  Geoff
 
  PS I’ve added Heat to the subject, because from a quick read of
  https://wiki.openstack.org/wiki/Heat/Blueprints/Multi_Region_Support_for_Heat
   
  https://wiki.openstack.org/wiki/Heat/Blueprints/Multi_Region_Support_for_Heat
  it looks as if Heat won’t support the AVAILABLE_REGIONS model. That
  seems like an unfortunate disconnect.
 
 
 
  
 Horizon only supports authenticating to one keystone endpoint at a time, 
 specifically to one of the entries in AVAILABLE_REGIONS as defined in 
 settings.py. Once you have an authenticated session in Horizon, the region 
 selection support is merely for filtering between regions registered with 
 the keystone endpoint you authenticated to, where the list of regions is 
 determined by parsing the service catalog returned to you with your token. 
 
 What's really unclear to me is what you are intending to ask.
 
 AVAILABLE_REGIONS is merely a list of keystone endpoints. They can be backed 
 by a different IdP per endpoint and thus not share a token store. Or, they 
 can just be keystone endpoints that are geographically different but backed 
 by the same IdP, which may or may not share a token store. The funny thing 
 is, for Horizon, it doesn't matter. They are all supported.  But as one 
 keystone endpoint may not know about another, unless nested, this has to be 
 done with settings as it's not typically discoverable.
 
 If you are asking about token sharing between keystones which the thread you 
 linked seems to indicate. Then yes, you can have a synced token store. But 
 that is an exercise left to the operator.
 
 
 I'd like to quickly go on record and say that a token store sync like this is 
 not recommended. It is possible to work around this in Kilo with some limited 
 data sync (resource, assignment) and the use of Fernet tokens. However, as 
 you introduce higher latencies and WAN transit this type of syncing becomes 
 more and more prone to error. 
 
 It would be possible to make DOA multi keystone aware, but before we dive too 
 far into this I'd like to get a clear view of what exactly the use 

Re: [openstack-dev] [horizon][keystone][heat] Are AVAILABLE_REGIONS and multi-region service catalog mutually exclusive?

[Geoff Arnold]

That’s interesting, because I wasn’t aware that “cloud” was part of the formal 
OpenStack taxonomy. Historically, we defined a region as a set of endpoints, 
supplied by an instance of Keystone.  You seem to be saying that a cloud is a 
collection of regions configured in the same Keystone. [citation needed]

Puzzled.

Geoff

 On May 14, 2015, at 7:56 AM, Zane Bitter zbit...@redhat.com wrote:
 
 On 14/05/15 10:39, Geoff Arnold wrote:
 +1
 
 There seems to be a significant disconnect between Heat, Horizon and
 Keystone on the subject of multi-region configurations, and the
 documentation isn’t helpful. At the very least, it would be useful if
 discussions at the summit could result in a decent Wiki page on the subject.
 
 The terminology I (and Heat) have always used is that regions are sets of 
 endpoints configured in the same Keystone. Where you have a different 
 Keystone auth URL that is straight up a separate cloud, no matter how you 
 slice it.
 
 The confusion here seems to be that Horizon is using the name 
 AVAILABLE_REGIONS to denote available Keystone auth URLS - i.e. different 
 clouds, not different regions at all.
 
 Looked at through that lens, things seem a bit easier to understand.
 
 Heat supports multi-region trees of stacks (i.e. you can created a nested 
 stack in another region). Multi-cloud support has been considered, but afaik 
 has not yet landed. Figuring out where to store the credentials securely is 
 tricky.
 
 cheers,
 Zane.
 
 Geoff
 
 On May 13, 2015, at 9:49 PM, Morgan Fainberg
 morgan.fainb...@gmail.com mailto:morgan.fainb...@gmail.com wrote:
 
 
 
 On May 13, 2015, at 21:34, David Lyle dkly...@gmail.com
 mailto:dkly...@gmail.com wrote:
 
 
 On Wed, May 13, 2015 at 3:24 PM, Mathieu Gagné mga...@iweb.com
 mailto:mga...@iweb.com wrote:
 
When using AVAILABLE_REGIONS, you get a dropdown at login time to
choose
your region which is in fact your keystone endpoint.
 
Once logged in, you get a new dropdown at the top right to switch
between the keystone endpoints. This means you can configure an
Horizon installation to login to multiple independent OpenStack
installations.
 
So I don't fully understand what enhancing the multi-region
support in
Keystone would mean. Would you be able to configure Horizon to
login to
multiple independent OpenStack installations?
 
Mathieu
 
On 2015-05-13 5:06 PM, Geoff Arnold wrote:
 Further digging suggests that we might consider deprecating
 AVAILABLE_REGIONS in Horizon and enhancing the multi-region support in
 Keystone. It wouldn’t take a lot; the main points:

   * Implement the Regions API discussed back in the Havana time
period
 
 -https://etherpad.openstack.org/p/havana-availability-zone-and-region-management
-
 but with full CRUD
   * Enhance the Endpoints API to allow filtering by region

 Supporting two different multi region models is problematic if we’re
 serious about things like multi-region Heat.

 Thoughts?

 Geoff

 On May 13, 2015, at 12:01 PM, Geoff Arnold ge...@geoffarnold.com 
 mailto:ge...@geoffarnold.com
 mailto:ge...@geoffarnold.com mailto:ge...@geoffarnold.com
wrote:

 I’m looking at implementing dynamically-configured multi-region
 support for service federation, and the prior art on multi-region
 support in Horizon is pretty sketchy. This thread:

http://lists.openstack.org/pipermail/openstack/2014-January/004372.html
 is the only real discussion I’ve found, and it’s pretty
inconclusive.

 More precisely, if I configure a single Horizon with
AVAILABLE_REGIONS
 pointing at two different Keystones with region names “X” and
“Y, and
 each of those Keystones returns a service catalog with multiple
 regions (“A” and “B” for one, “P”, “Q”, and “R” for the
other), what’s
 Horizon going to do? Or rather, what’s it expected to do?

 Yes, I’m being lazy: I could actually configure this to see what
 happens, but hopefully it was considered during the design.

 Geoff

 PS I’ve added Heat to the subject, because from a quick read of


 https://wiki.openstack.org/wiki/Heat/Blueprints/Multi_Region_Support_for_Heat
 it looks as if Heat won’t support the AVAILABLE_REGIONS model.
That
 seems like an unfortunate disconnect.



 
 Horizon only supports authenticating to one keystone endpoint at a
 time, specifically to one of the entries in AVAILABLE_REGIONS as
 defined in settings.py. Once you have an authenticated session in
 Horizon, the region selection support is merely for filtering between
 regions registered with the keystone endpoint you authenticated to,
 where the list of regions is determined by parsing the service
 catalog returned to you with your token.
 
 What's really unclear to me is what you are intending to ask.
 
 AVAILABLE_REGIONS is merely a 

Re: [openstack-dev] [horizon][keystone][heat] Are AVAILABLE_REGIONS and multi-region service catalog mutually exclusive?

[Geoff Arnold]

+1

A wiki page laying out a mutually agreeable taxonomy seems like a good starting 
point.

Geoff

 On May 14, 2015, at 7:47 AM, Anne Gentle annegen...@justwriteclick.com 
 wrote:
 
 
 
 On Thu, May 14, 2015 at 9:39 AM, Geoff Arnold ge...@geoffarnold.com 
 mailto:ge...@geoffarnold.com wrote:
 +1
 
 There seems to be a significant disconnect between Heat, Horizon and Keystone 
 on the subject of multi-region configurations, and the documentation isn’t 
 helpful. At the very least, it would be useful if discussions at the summit 
 could result in a decent Wiki page on the subject.
 
 We have a cross-project session and spec started about the service catalog:
 
 https://review.openstack.org/#/c/181393/ 
 https://review.openstack.org/#/c/181393/
 
 http://sched.co/3BL3 http://sched.co/3BL3
 
 I hope more than a wiki page comes of it. :)
 Anne
  
 
 Geoff
 
 On May 13, 2015, at 9:49 PM, Morgan Fainberg morgan.fainb...@gmail.com 
 mailto:morgan.fainb...@gmail.com wrote:
 
 
 
 On May 13, 2015, at 21:34, David Lyle dkly...@gmail.com 
 mailto:dkly...@gmail.com wrote:
 
 
 On Wed, May 13, 2015 at 3:24 PM, Mathieu Gagné mga...@iweb.com 
 mailto:mga...@iweb.com wrote:
 When using AVAILABLE_REGIONS, you get a dropdown at login time to choose
 your region which is in fact your keystone endpoint.
 
 Once logged in, you get a new dropdown at the top right to switch
 between the keystone endpoints. This means you can configure an
 Horizon installation to login to multiple independent OpenStack
 installations.
 
 So I don't fully understand what enhancing the multi-region support in
 Keystone would mean. Would you be able to configure Horizon to login to
 multiple independent OpenStack installations?
 
 Mathieu
 
 On 2015-05-13 5:06 PM, Geoff Arnold wrote:
  Further digging suggests that we might consider deprecating
  AVAILABLE_REGIONS in Horizon and enhancing the multi-region support in
  Keystone. It wouldn’t take a lot; the main points:
 
* Implement the Regions API discussed back in the Havana time period
  - 
  https://etherpad.openstack.org/p/havana-availability-zone-and-region-management
   
  https://etherpad.openstack.org/p/havana-availability-zone-and-region-management
   -
  but with full CRUD
* Enhance the Endpoints API to allow filtering by region
 
  Supporting two different multi region models is problematic if we’re
  serious about things like multi-region Heat.
 
  Thoughts?
 
  Geoff
 
  On May 13, 2015, at 12:01 PM, Geoff Arnold ge...@geoffarnold.com 
  mailto:ge...@geoffarnold.com
  mailto:ge...@geoffarnold.com mailto:ge...@geoffarnold.com wrote:
 
  I’m looking at implementing dynamically-configured multi-region
  support for service federation, and the prior art on multi-region
  support in Horizon is pretty sketchy. This thread:
  http://lists.openstack.org/pipermail/openstack/2014-January/004372.html 
  http://lists.openstack.org/pipermail/openstack/2014-January/004372.html
  is the only real discussion I’ve found, and it’s pretty inconclusive.
 
  More precisely, if I configure a single Horizon with AVAILABLE_REGIONS
  pointing at two different Keystones with region names “X” and “Y, and
  each of those Keystones returns a service catalog with multiple
  regions (“A” and “B” for one, “P”, “Q”, and “R” for the other), what’s
  Horizon going to do? Or rather, what’s it expected to do?
 
  Yes, I’m being lazy: I could actually configure this to see what
  happens, but hopefully it was considered during the design.
 
  Geoff
 
  PS I’ve added Heat to the subject, because from a quick read of
  https://wiki.openstack.org/wiki/Heat/Blueprints/Multi_Region_Support_for_Heat
   
  https://wiki.openstack.org/wiki/Heat/Blueprints/Multi_Region_Support_for_Heat
  it looks as if Heat won’t support the AVAILABLE_REGIONS model. That
  seems like an unfortunate disconnect.
 
 
 
  
 Horizon only supports authenticating to one keystone endpoint at a time, 
 specifically to one of the entries in AVAILABLE_REGIONS as defined in 
 settings.py. Once you have an authenticated session in Horizon, the region 
 selection support is merely for filtering between regions registered with 
 the keystone endpoint you authenticated to, where the list of regions is 
 determined by parsing the service catalog returned to you with your token. 
 
 What's really unclear to me is what you are intending to ask.
 
 AVAILABLE_REGIONS is merely a list of keystone endpoints. They can be 
 backed by a different IdP per endpoint and thus not share a token store. 
 Or, they can just be keystone endpoints that are geographically different 
 but backed by the same IdP, which may or may not share a token store. The 
 funny thing is, for Horizon, it doesn't matter. They are all supported.  
 But as one keystone endpoint may not know about another, unless nested, 
 this has to be done with settings as it's not typically discoverable.
 
 If you are asking about token sharing between keystones which the thread 
 you linked seems to 

Re: [openstack-dev] [horizon][keystone][heat] Are AVAILABLE_REGIONS and multi-region service catalog mutually exclusive?

[Anne Gentle]

On Thu, May 14, 2015 at 9:39 AM, Geoff Arnold ge...@geoffarnold.com wrote:

 +1

 There seems to be a significant disconnect between Heat, Horizon and
 Keystone on the subject of multi-region configurations, and the
 documentation isn’t helpful. At the very least, it would be useful if
 discussions at the summit could result in a decent Wiki page on the subject.


We have a cross-project session and spec started about the service catalog:

https://review.openstack.org/#/c/181393/

http://sched.co/3BL3

I hope more than a wiki page comes of it. :)
Anne



 Geoff

 On May 13, 2015, at 9:49 PM, Morgan Fainberg morgan.fainb...@gmail.com
 wrote:



 On May 13, 2015, at 21:34, David Lyle dkly...@gmail.com wrote:


 On Wed, May 13, 2015 at 3:24 PM, Mathieu Gagné mga...@iweb.com wrote:

 When using AVAILABLE_REGIONS, you get a dropdown at login time to choose
 your region which is in fact your keystone endpoint.

 Once logged in, you get a new dropdown at the top right to switch
 between the keystone endpoints. This means you can configure an
 Horizon installation to login to multiple independent OpenStack
 installations.

 So I don't fully understand what enhancing the multi-region support in
 Keystone would mean. Would you be able to configure Horizon to login to
 multiple independent OpenStack installations?

 Mathieu

 On 2015-05-13 5:06 PM, Geoff Arnold wrote:
  Further digging suggests that we might consider deprecating
  AVAILABLE_REGIONS in Horizon and enhancing the multi-region support in
  Keystone. It wouldn’t take a lot; the main points:
 
* Implement the Regions API discussed back in the Havana time period
  -
 https://etherpad.openstack.org/p/havana-availability-zone-and-region-management
 -
  but with full CRUD
* Enhance the Endpoints API to allow filtering by region
 
  Supporting two different multi region models is problematic if we’re
  serious about things like multi-region Heat.
 
  Thoughts?
 
  Geoff
 
  On May 13, 2015, at 12:01 PM, Geoff Arnold ge...@geoffarnold.com
  mailto:ge...@geoffarnold.com wrote:
 
  I’m looking at implementing dynamically-configured multi-region
  support for service federation, and the prior art on multi-region
  support in Horizon is pretty sketchy. This thread:
 
 http://lists.openstack.org/pipermail/openstack/2014-January/004372.html
  is the only real discussion I’ve found, and it’s pretty inconclusive.
 
  More precisely, if I configure a single Horizon with AVAILABLE_REGIONS
  pointing at two different Keystones with region names “X” and “Y, and
  each of those Keystones returns a service catalog with multiple
  regions (“A” and “B” for one, “P”, “Q”, and “R” for the other), what’s
  Horizon going to do? Or rather, what’s it expected to do?
 
  Yes, I’m being lazy: I could actually configure this to see what
  happens, but hopefully it was considered during the design.
 
  Geoff
 
  PS I’ve added Heat to the subject, because from a quick read of
 
 https://wiki.openstack.org/wiki/Heat/Blueprints/Multi_Region_Support_for_Heat
  it looks as if Heat won’t support the AVAILABLE_REGIONS model. That
  seems like an unfortunate disconnect.
 
 
 


 Horizon only supports authenticating to one keystone endpoint at a time,
 specifically to one of the entries in AVAILABLE_REGIONS as defined in
 settings.py. Once you have an authenticated session in Horizon, the region
 selection support is merely for filtering between regions registered with
 the keystone endpoint you authenticated to, where the list of regions is
 determined by parsing the service catalog returned to you with your token.

 What's really unclear to me is what you are intending to ask.

 AVAILABLE_REGIONS is merely a list of keystone endpoints. They can be
 backed by a different IdP per endpoint and thus not share a token store.
 Or, they can just be keystone endpoints that are geographically different
 but backed by the same IdP, which may or may not share a token store. The
 funny thing is, for Horizon, it doesn't matter. They are all supported.
 But as one keystone endpoint may not know about another, unless nested,
 this has to be done with settings as it's not typically discoverable.

 If you are asking about token sharing between keystones which the thread
 you linked seems to indicate. Then yes, you can have a synced token store.
 But that is an exercise left to the operator.


 I'd like to quickly go on record and say that a token store sync like this
 is not recommended. It is possible to work around this in Kilo with some
 limited data sync (resource, assignment) and the use of Fernet tokens.
 However, as you introduce higher latencies and WAN transit this type of
 syncing becomes more and more prone to error.

 It would be possible to make DOA multi keystone aware, but before we dive
 too far into this I'd like to get a clear view of what exactly the use case
 (and goal is); let's do this at the summit (since it is happening soon).
 Having a clear view will make this easier 

Re: [openstack-dev] [horizon][keystone][heat] Are AVAILABLE_REGIONS and multi-region service catalog mutually exclusive?

[Zane Bitter]

On 14/05/15 10:39, Geoff Arnold wrote:

+1

There seems to be a significant disconnect between Heat, Horizon and
Keystone on the subject of multi-region configurations, and the
documentation isn’t helpful. At the very least, it would be useful if
discussions at the summit could result in a decent Wiki page on the subject.


The terminology I (and Heat) have always used is that regions are sets 
of endpoints configured in the same Keystone. Where you have a different 
Keystone auth URL that is straight up a separate cloud, no matter how 
you slice it.


The confusion here seems to be that Horizon is using the name 
AVAILABLE_REGIONS to denote available Keystone auth URLS - i.e. 
different clouds, not different regions at all.


Looked at through that lens, things seem a bit easier to understand.

Heat supports multi-region trees of stacks (i.e. you can created a 
nested stack in another region). Multi-cloud support has been 
considered, but afaik has not yet landed. Figuring out where to store 
the credentials securely is tricky.


cheers,
Zane.


Geoff


On May 13, 2015, at 9:49 PM, Morgan Fainberg
morgan.fainb...@gmail.com mailto:morgan.fainb...@gmail.com wrote:



On May 13, 2015, at 21:34, David Lyle dkly...@gmail.com
mailto:dkly...@gmail.com wrote:



On Wed, May 13, 2015 at 3:24 PM, Mathieu Gagné mga...@iweb.com
mailto:mga...@iweb.com wrote:

When using AVAILABLE_REGIONS, you get a dropdown at login time to
choose
your region which is in fact your keystone endpoint.

Once logged in, you get a new dropdown at the top right to switch
between the keystone endpoints. This means you can configure an
Horizon installation to login to multiple independent OpenStack
installations.

So I don't fully understand what enhancing the multi-region
support in
Keystone would mean. Would you be able to configure Horizon to
login to
multiple independent OpenStack installations?

Mathieu

On 2015-05-13 5:06 PM, Geoff Arnold wrote:
 Further digging suggests that we might consider deprecating
 AVAILABLE_REGIONS in Horizon and enhancing the multi-region support in
 Keystone. It wouldn’t take a lot; the main points:

   * Implement the Regions API discussed back in the Havana time
period
 
-https://etherpad.openstack.org/p/havana-availability-zone-and-region-management
-
 but with full CRUD
   * Enhance the Endpoints API to allow filtering by region

 Supporting two different multi region models is problematic if we’re
 serious about things like multi-region Heat.

 Thoughts?

 Geoff

 On May 13, 2015, at 12:01 PM, Geoff Arnold ge...@geoffarnold.com 
mailto:ge...@geoffarnold.com
 mailto:ge...@geoffarnold.com mailto:ge...@geoffarnold.com
wrote:

 I’m looking at implementing dynamically-configured multi-region
 support for service federation, and the prior art on multi-region
 support in Horizon is pretty sketchy. This thread:

http://lists.openstack.org/pipermail/openstack/2014-January/004372.html
 is the only real discussion I’ve found, and it’s pretty
inconclusive.

 More precisely, if I configure a single Horizon with
AVAILABLE_REGIONS
 pointing at two different Keystones with region names “X” and
“Y, and
 each of those Keystones returns a service catalog with multiple
 regions (“A” and “B” for one, “P”, “Q”, and “R” for the
other), what’s
 Horizon going to do? Or rather, what’s it expected to do?

 Yes, I’m being lazy: I could actually configure this to see what
 happens, but hopefully it was considered during the design.

 Geoff

 PS I’ve added Heat to the subject, because from a quick read of


https://wiki.openstack.org/wiki/Heat/Blueprints/Multi_Region_Support_for_Heat
 it looks as if Heat won’t support the AVAILABLE_REGIONS model.
That
 seems like an unfortunate disconnect.




Horizon only supports authenticating to one keystone endpoint at a
time, specifically to one of the entries in AVAILABLE_REGIONS as
defined in settings.py. Once you have an authenticated session in
Horizon, the region selection support is merely for filtering between
regions registered with the keystone endpoint you authenticated to,
where the list of regions is determined by parsing the service
catalog returned to you with your token.

What's really unclear to me is what you are intending to ask.

AVAILABLE_REGIONS is merely a list of keystone endpoints. They can be
backed by a different IdP per endpoint and thus not share a token
store. Or, they can just be keystone endpoints that are
geographically different but backed by the same IdP, which may or may
not share a token store. The funny thing is, for Horizon, it doesn't
matter. They are all supported.  But as one keystone endpoint may not
know about another, unless nested, this has to be done with settings
as it's not 

Re: [openstack-dev] [horizon][keystone][heat] Are AVAILABLE_REGIONS and multi-region service catalog mutually exclusive?

[Morgan Fainberg]

On Thursday, May 14, 2015, Anne Gentle annegen...@justwriteclick.com
wrote:



 On Thu, May 14, 2015 at 9:39 AM, Geoff Arnold ge...@geoffarnold.com
 javascript:_e(%7B%7D,'cvml','ge...@geoffarnold.com'); wrote:

 +1

 There seems to be a significant disconnect between Heat, Horizon and
 Keystone on the subject of multi-region configurations, and the
 documentation isn’t helpful. At the very least, it would be useful if
 discussions at the summit could result in a decent Wiki page on the subject.


 We have a cross-project session and spec started about the service catalog:

 https://review.openstack.org/#/c/181393/

 http://sched.co/3BL3

 I hope more than a wiki page comes of it. :)
 Anne



I, for one, am already planning on being there :)



 Geoff

 On May 13, 2015, at 9:49 PM, Morgan Fainberg morgan.fainb...@gmail.com
 javascript:_e(%7B%7D,'cvml','morgan.fainb...@gmail.com'); wrote:



 On May 13, 2015, at 21:34, David Lyle dkly...@gmail.com
 javascript:_e(%7B%7D,'cvml','dkly...@gmail.com'); wrote:


 On Wed, May 13, 2015 at 3:24 PM, Mathieu Gagné mga...@iweb.com
 javascript:_e(%7B%7D,'cvml','mga...@iweb.com'); wrote:

 When using AVAILABLE_REGIONS, you get a dropdown at login time to choose
 your region which is in fact your keystone endpoint.

 Once logged in, you get a new dropdown at the top right to switch
 between the keystone endpoints. This means you can configure an
 Horizon installation to login to multiple independent OpenStack
 installations.

 So I don't fully understand what enhancing the multi-region support in
 Keystone would mean. Would you be able to configure Horizon to login to
 multiple independent OpenStack installations?

 Mathieu

 On 2015-05-13 5:06 PM, Geoff Arnold wrote:
  Further digging suggests that we might consider deprecating
  AVAILABLE_REGIONS in Horizon and enhancing the multi-region support in
  Keystone. It wouldn’t take a lot; the main points:
 
* Implement the Regions API discussed back in the Havana time period
  -
 https://etherpad.openstack.org/p/havana-availability-zone-and-region-management
 -
  but with full CRUD
* Enhance the Endpoints API to allow filtering by region
 
  Supporting two different multi region models is problematic if we’re
  serious about things like multi-region Heat.
 
  Thoughts?
 
  Geoff
 
  On May 13, 2015, at 12:01 PM, Geoff Arnold ge...@geoffarnold.com
 javascript:_e(%7B%7D,'cvml','ge...@geoffarnold.com');
  mailto:ge...@geoffarnold.com
 javascript:_e(%7B%7D,'cvml','ge...@geoffarnold.com'); wrote:
 
  I’m looking at implementing dynamically-configured multi-region
  support for service federation, and the prior art on multi-region
  support in Horizon is pretty sketchy. This thread:
 
 http://lists.openstack.org/pipermail/openstack/2014-January/004372.html
  is the only real discussion I’ve found, and it’s pretty inconclusive.
 
  More precisely, if I configure a single Horizon with AVAILABLE_REGIONS
  pointing at two different Keystones with region names “X” and “Y, and
  each of those Keystones returns a service catalog with multiple
  regions (“A” and “B” for one, “P”, “Q”, and “R” for the other), what’s
  Horizon going to do? Or rather, what’s it expected to do?
 
  Yes, I’m being lazy: I could actually configure this to see what
  happens, but hopefully it was considered during the design.
 
  Geoff
 
  PS I’ve added Heat to the subject, because from a quick read of
 
 https://wiki.openstack.org/wiki/Heat/Blueprints/Multi_Region_Support_for_Heat
  it looks as if Heat won’t support the AVAILABLE_REGIONS model. That
  seems like an unfortunate disconnect.
 
 
 


 Horizon only supports authenticating to one keystone endpoint at a time,
 specifically to one of the entries in AVAILABLE_REGIONS as defined in
 settings.py. Once you have an authenticated session in Horizon, the region
 selection support is merely for filtering between regions registered with
 the keystone endpoint you authenticated to, where the list of regions is
 determined by parsing the service catalog returned to you with your token.

 What's really unclear to me is what you are intending to ask.

 AVAILABLE_REGIONS is merely a list of keystone endpoints. They can be
 backed by a different IdP per endpoint and thus not share a token store.
 Or, they can just be keystone endpoints that are geographically different
 but backed by the same IdP, which may or may not share a token store. The
 funny thing is, for Horizon, it doesn't matter. They are all supported.
 But as one keystone endpoint may not know about another, unless nested,
 this has to be done with settings as it's not typically discoverable.

 If you are asking about token sharing between keystones which the thread
 you linked seems to indicate. Then yes, you can have a synced token store.
 But that is an exercise left to the operator.


 I'd like to quickly go on record and say that a token store sync like
 this is not recommended. It is possible to work around this in Kilo with
 some 

Re: [openstack-dev] [horizon][keystone][heat] Are AVAILABLE_REGIONS and multi-region service catalog mutually exclusive?

[Mathieu Gagné]

On 2015-05-14 12:34 AM, David Lyle wrote:
  
 Horizon only supports authenticating to one keystone endpoint at a time,
 specifically to one of the entries in AVAILABLE_REGIONS as defined in
 settings.py. Once you have an authenticated session in Horizon, the
 region selection support is merely for filtering between regions
 registered with the keystone endpoint you authenticated to, where the
 list of regions is determined by parsing the service catalog returned to
 you with your token. 
 
 What's really unclear to me is what you are intending to ask.

I'm asking to NOT remove the feature provided by AVAILABLE_REGIONS which
is what you described: support for multiple keystone endpoint (or
OpenStack installations) in one Horizon installation.

 If you are asking about token sharing between keystones which the thread
 you linked seems to indicate. Then yes, you can have a synced token
 store. But that is an exercise left to the operator.

I'm not suggesting token sharing. I'm merely trying to explain that
AVAILABLE_REGIONS answers a different need than multi-regions in the
same keystone endpoint which Horizon already supports fine.

Those are 2 features answering different needs and AVAILABLE_REGIONS
shouldn't be removed as suggested previously: we might consider
deprecating AVAILABLE_REGIONS in Horizon.

-- 
Mathieu

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [horizon][keystone][heat] Are AVAILABLE_REGIONS and multi-region service catalog mutually exclusive?

[Fox, Kevin M]

The keystone api has had regions as part of the api for a long time I think. 
This would imply the one keystone, multiple regions definition.

Thanks,
Kevin

From: Geoff Arnold [ge...@geoffarnold.com]
Sent: Thursday, May 14, 2015 11:41 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [horizon][keystone][heat] Are  
AVAILABLE_REGIONS and multi-region service catalog mutually   exclusive?

That’s interesting, because I wasn’t aware that “cloud” was part of the formal 
OpenStack taxonomy. Historically, we defined a region as a set of endpoints, 
supplied by an instance of Keystone.  You seem to be saying that a cloud is a 
collection of regions configured in the same Keystone. [citation needed]

Puzzled.

Geoff

 On May 14, 2015, at 7:56 AM, Zane Bitter zbit...@redhat.com wrote:

 On 14/05/15 10:39, Geoff Arnold wrote:
 +1

 There seems to be a significant disconnect between Heat, Horizon and
 Keystone on the subject of multi-region configurations, and the
 documentation isn’t helpful. At the very least, it would be useful if
 discussions at the summit could result in a decent Wiki page on the subject.

 The terminology I (and Heat) have always used is that regions are sets of 
 endpoints configured in the same Keystone. Where you have a different 
 Keystone auth URL that is straight up a separate cloud, no matter how you 
 slice it.

 The confusion here seems to be that Horizon is using the name 
 AVAILABLE_REGIONS to denote available Keystone auth URLS - i.e. different 
 clouds, not different regions at all.

 Looked at through that lens, things seem a bit easier to understand.

 Heat supports multi-region trees of stacks (i.e. you can created a nested 
 stack in another region). Multi-cloud support has been considered, but afaik 
 has not yet landed. Figuring out where to store the credentials securely is 
 tricky.

 cheers,
 Zane.

 Geoff

 On May 13, 2015, at 9:49 PM, Morgan Fainberg
 morgan.fainb...@gmail.com mailto:morgan.fainb...@gmail.com wrote:



 On May 13, 2015, at 21:34, David Lyle dkly...@gmail.com
 mailto:dkly...@gmail.com wrote:


 On Wed, May 13, 2015 at 3:24 PM, Mathieu Gagné mga...@iweb.com
 mailto:mga...@iweb.com wrote:

When using AVAILABLE_REGIONS, you get a dropdown at login time to
choose
your region which is in fact your keystone endpoint.

Once logged in, you get a new dropdown at the top right to switch
between the keystone endpoints. This means you can configure an
Horizon installation to login to multiple independent OpenStack
installations.

So I don't fully understand what enhancing the multi-region
support in
Keystone would mean. Would you be able to configure Horizon to
login to
multiple independent OpenStack installations?

Mathieu

On 2015-05-13 5:06 PM, Geoff Arnold wrote:
 Further digging suggests that we might consider deprecating
 AVAILABLE_REGIONS in Horizon and enhancing the multi-region support in
 Keystone. It wouldn’t take a lot; the main points:

   * Implement the Regions API discussed back in the Havana time
period
 
 -https://etherpad.openstack.org/p/havana-availability-zone-and-region-management
-
 but with full CRUD
   * Enhance the Endpoints API to allow filtering by region

 Supporting two different multi region models is problematic if we’re
 serious about things like multi-region Heat.

 Thoughts?

 Geoff

 On May 13, 2015, at 12:01 PM, Geoff Arnold ge...@geoffarnold.com 
 mailto:ge...@geoffarnold.com
 mailto:ge...@geoffarnold.com mailto:ge...@geoffarnold.com
wrote:

 I’m looking at implementing dynamically-configured multi-region
 support for service federation, and the prior art on multi-region
 support in Horizon is pretty sketchy. This thread:

http://lists.openstack.org/pipermail/openstack/2014-January/004372.html
 is the only real discussion I’ve found, and it’s pretty
inconclusive.

 More precisely, if I configure a single Horizon with
AVAILABLE_REGIONS
 pointing at two different Keystones with region names “X” and
“Y, and
 each of those Keystones returns a service catalog with multiple
 regions (“A” and “B” for one, “P”, “Q”, and “R” for the
other), what’s
 Horizon going to do? Or rather, what’s it expected to do?

 Yes, I’m being lazy: I could actually configure this to see what
 happens, but hopefully it was considered during the design.

 Geoff

 PS I’ve added Heat to the subject, because from a quick read of


 https://wiki.openstack.org/wiki/Heat/Blueprints/Multi_Region_Support_for_Heat
 it looks as if Heat won’t support the AVAILABLE_REGIONS model.
That
 seems like an unfortunate disconnect.




 Horizon only supports authenticating to one keystone endpoint at a
 time

Re: [openstack-dev] [horizon][keystone][heat] Are AVAILABLE_REGIONS and multi-region service catalog mutually exclusive?

[Zane Bitter]

On 14/05/15 14:41, Geoff Arnold wrote:

That’s interesting, because I wasn’t aware that “cloud” was part of the formal 
OpenStack taxonomy.


Um, OK. AWS, Rackspace and Helion are all different clouds, even though 
the last two both run OpenStack. Do we really need a formal taxonomy for 
that?


Likewise, if you install OpenStack twice, you get two different clouds. 
Each of which may or may not be split into multiple regions.



Historically, we defined a region as a set of endpoints, supplied by an 
instance of Keystone.


Right.


You seem to be saying that a cloud is a collection of regions configured in the 
same Keystone.


Yes, that's what I'm saying. How is that different?


[citation needed]


Seriously, this is not nearly as complicated as you are making out.


Puzzled.


Two regions that don't appear in the same Keystone catalog are not part 
of the same cloud. Horizon offers support for dealing with multiple 
regions within a single cloud. It also offers an option to switch 
between multiple different clouds using an option unfortunately called 
AVAILABLE_REGIONS, which is a total misnomer.


- ZB



Geoff


On May 14, 2015, at 7:56 AM, Zane Bitter zbit...@redhat.com wrote:

On 14/05/15 10:39, Geoff Arnold wrote:

+1

There seems to be a significant disconnect between Heat, Horizon and
Keystone on the subject of multi-region configurations, and the
documentation isn’t helpful. At the very least, it would be useful if
discussions at the summit could result in a decent Wiki page on the subject.


The terminology I (and Heat) have always used is that regions are sets of 
endpoints configured in the same Keystone. Where you have a different Keystone 
auth URL that is straight up a separate cloud, no matter how you slice it.

The confusion here seems to be that Horizon is using the name AVAILABLE_REGIONS 
to denote available Keystone auth URLS - i.e. different clouds, not different 
regions at all.

Looked at through that lens, things seem a bit easier to understand.

Heat supports multi-region trees of stacks (i.e. you can created a nested stack 
in another region). Multi-cloud support has been considered, but afaik has not 
yet landed. Figuring out where to store the credentials securely is tricky.

cheers,
Zane.


Geoff


On May 13, 2015, at 9:49 PM, Morgan Fainberg
morgan.fainb...@gmail.com mailto:morgan.fainb...@gmail.com wrote:



On May 13, 2015, at 21:34, David Lyle dkly...@gmail.com
mailto:dkly...@gmail.com wrote:



On Wed, May 13, 2015 at 3:24 PM, Mathieu Gagné mga...@iweb.com
mailto:mga...@iweb.com wrote:

When using AVAILABLE_REGIONS, you get a dropdown at login time to
choose
your region which is in fact your keystone endpoint.

Once logged in, you get a new dropdown at the top right to switch
between the keystone endpoints. This means you can configure an
Horizon installation to login to multiple independent OpenStack
installations.

So I don't fully understand what enhancing the multi-region
support in
Keystone would mean. Would you be able to configure Horizon to
login to
multiple independent OpenStack installations?

Mathieu

On 2015-05-13 5:06 PM, Geoff Arnold wrote:
 Further digging suggests that we might consider deprecating
 AVAILABLE_REGIONS in Horizon and enhancing the multi-region support in
 Keystone. It wouldn’t take a lot; the main points:

   * Implement the Regions API discussed back in the Havana time
period
 
-https://etherpad.openstack.org/p/havana-availability-zone-and-region-management
-
 but with full CRUD
   * Enhance the Endpoints API to allow filtering by region

 Supporting two different multi region models is problematic if we’re
 serious about things like multi-region Heat.

 Thoughts?

 Geoff

 On May 13, 2015, at 12:01 PM, Geoff Arnold ge...@geoffarnold.com 
mailto:ge...@geoffarnold.com
 mailto:ge...@geoffarnold.com mailto:ge...@geoffarnold.com
wrote:

 I’m looking at implementing dynamically-configured multi-region
 support for service federation, and the prior art on multi-region
 support in Horizon is pretty sketchy. This thread:

http://lists.openstack.org/pipermail/openstack/2014-January/004372.html
 is the only real discussion I’ve found, and it’s pretty
inconclusive.

 More precisely, if I configure a single Horizon with
AVAILABLE_REGIONS
 pointing at two different Keystones with region names “X” and
“Y, and
 each of those Keystones returns a service catalog with multiple
 regions (“A” and “B” for one, “P”, “Q”, and “R” for the
other), what’s
 Horizon going to do? Or rather, what’s it expected to do?

 Yes, I’m being lazy: I could actually configure this to see what
 happens, but hopefully it was considered during the design.

 Geoff

 PS I’ve added Heat to the subject, because from a quick read of

Re: [openstack-dev] [horizon][keystone][heat] Are AVAILABLE_REGIONS and multi-region service catalog mutually exclusive?

[Geoff Arnold]

If we don’t want to deprecate AVAILABLE_REGIONS, we certainly need to clean up 
the ambiguity. And to be honest, the existing documentation for both 
multi-region” schemes (AVAILABLE_REGIONS and Keystone based) is completely 
inadequate. 

Geoff

 On May 14, 2015, at 1:13 PM, Mathieu Gagné mga...@iweb.com wrote:
 
 On 2015-05-14 12:34 AM, David Lyle wrote:
 
 Horizon only supports authenticating to one keystone endpoint at a time,
 specifically to one of the entries in AVAILABLE_REGIONS as defined in
 settings.py. Once you have an authenticated session in Horizon, the
 region selection support is merely for filtering between regions
 registered with the keystone endpoint you authenticated to, where the
 list of regions is determined by parsing the service catalog returned to
 you with your token. 
 
 What's really unclear to me is what you are intending to ask.
 
 I'm asking to NOT remove the feature provided by AVAILABLE_REGIONS which
 is what you described: support for multiple keystone endpoint (or
 OpenStack installations) in one Horizon installation.
 
 If you are asking about token sharing between keystones which the thread
 you linked seems to indicate. Then yes, you can have a synced token
 store. But that is an exercise left to the operator.
 
 I'm not suggesting token sharing. I'm merely trying to explain that
 AVAILABLE_REGIONS answers a different need than multi-regions in the
 same keystone endpoint which Horizon already supports fine.
 
 Those are 2 features answering different needs and AVAILABLE_REGIONS
 shouldn't be removed as suggested previously: we might consider
 deprecating AVAILABLE_REGIONS in Horizon.
 
 -- 
 Mathieu
 
 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [horizon][keystone][heat] Are AVAILABLE_REGIONS and multi-region service catalog mutually exclusive?

[Morgan Fainberg]

 On May 13, 2015, at 21:34, David Lyle dkly...@gmail.com wrote:
 
 
 On Wed, May 13, 2015 at 3:24 PM, Mathieu Gagné mga...@iweb.com wrote:
 When using AVAILABLE_REGIONS, you get a dropdown at login time to choose
 your region which is in fact your keystone endpoint.
 
 Once logged in, you get a new dropdown at the top right to switch
 between the keystone endpoints. This means you can configure an
 Horizon installation to login to multiple independent OpenStack
 installations.
 
 So I don't fully understand what enhancing the multi-region support in
 Keystone would mean. Would you be able to configure Horizon to login to
 multiple independent OpenStack installations?
 
 Mathieu
 
 On 2015-05-13 5:06 PM, Geoff Arnold wrote:
  Further digging suggests that we might consider deprecating
  AVAILABLE_REGIONS in Horizon and enhancing the multi-region support in
  Keystone. It wouldn’t take a lot; the main points:
 
* Implement the Regions API discussed back in the Havana time period
  - 
  https://etherpad.openstack.org/p/havana-availability-zone-and-region-management
   -
  but with full CRUD
* Enhance the Endpoints API to allow filtering by region
 
  Supporting two different multi region models is problematic if we’re
  serious about things like multi-region Heat.
 
  Thoughts?
 
  Geoff
 
  On May 13, 2015, at 12:01 PM, Geoff Arnold ge...@geoffarnold.com
  mailto:ge...@geoffarnold.com wrote:
 
  I’m looking at implementing dynamically-configured multi-region
  support for service federation, and the prior art on multi-region
  support in Horizon is pretty sketchy. This thread:
  http://lists.openstack.org/pipermail/openstack/2014-January/004372.html
  is the only real discussion I’ve found, and it’s pretty inconclusive.
 
  More precisely, if I configure a single Horizon with AVAILABLE_REGIONS
  pointing at two different Keystones with region names “X” and “Y, and
  each of those Keystones returns a service catalog with multiple
  regions (“A” and “B” for one, “P”, “Q”, and “R” for the other), what’s
  Horizon going to do? Or rather, what’s it expected to do?
 
  Yes, I’m being lazy: I could actually configure this to see what
  happens, but hopefully it was considered during the design.
 
  Geoff
 
  PS I’ve added Heat to the subject, because from a quick read of
  https://wiki.openstack.org/wiki/Heat/Blueprints/Multi_Region_Support_for_Heat
  it looks as if Heat won’t support the AVAILABLE_REGIONS model. That
  seems like an unfortunate disconnect.
 
 
 
  
 Horizon only supports authenticating to one keystone endpoint at a time, 
 specifically to one of the entries in AVAILABLE_REGIONS as defined in 
 settings.py. Once you have an authenticated session in Horizon, the region 
 selection support is merely for filtering between regions registered with the 
 keystone endpoint you authenticated to, where the list of regions is 
 determined by parsing the service catalog returned to you with your token. 
 
 What's really unclear to me is what you are intending to ask.
 
 AVAILABLE_REGIONS is merely a list of keystone endpoints. They can be backed 
 by a different IdP per endpoint and thus not share a token store. Or, they 
 can just be keystone endpoints that are geographically different but backed 
 by the same IdP, which may or may not share a token store. The funny thing 
 is, for Horizon, it doesn't matter. They are all supported.  But as one 
 keystone endpoint may not know about another, unless nested, this has to be 
 done with settings as it's not typically discoverable.
 
 If you are asking about token sharing between keystones which the thread you 
 linked seems to indicate. Then yes, you can have a synced token store. But 
 that is an exercise left to the operator.
 

I'd like to quickly go on record and say that a token store sync like this is 
not recommended. It is possible to work around this in Kilo with some limited 
data sync (resource, assignment) and the use of Fernet tokens. However, as you 
introduce higher latencies and WAN transit this type of syncing becomes more 
and more prone to error. 

It would be possible to make DOA multi keystone aware, but before we dive too 
far into this I'd like to get a clear view of what exactly the use case (and 
goal is); let's do this at the summit (since it is happening soon). Having a 
clear view will make this easier to determine if AVAILABLE_REGIONS or another 
mechanism is/will be better suited. We can then summarize and report the 
results back to this thread to keep everyone apprised of the direction. 

--Morgan__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [horizon][keystone][heat] Are AVAILABLE_REGIONS and multi-region service catalog mutually exclusive?

[Mathieu Gagné]

When using AVAILABLE_REGIONS, you get a dropdown at login time to choose
your region which is in fact your keystone endpoint.

Once logged in, you get a new dropdown at the top right to switch
between the keystone endpoints. This means you can configure an
Horizon installation to login to multiple independent OpenStack
installations.

So I don't fully understand what enhancing the multi-region support in
Keystone would mean. Would you be able to configure Horizon to login to
multiple independent OpenStack installations?

Mathieu

On 2015-05-13 5:06 PM, Geoff Arnold wrote:
 Further digging suggests that we might consider deprecating
 AVAILABLE_REGIONS in Horizon and enhancing the multi-region support in
 Keystone. It wouldn’t take a lot; the main points:
 
   * Implement the Regions API discussed back in the Havana time period
 - 
 https://etherpad.openstack.org/p/havana-availability-zone-and-region-management
  -
 but with full CRUD
   * Enhance the Endpoints API to allow filtering by region
 
 Supporting two different multi region models is problematic if we’re
 serious about things like multi-region Heat.
 
 Thoughts?
 
 Geoff
 
 On May 13, 2015, at 12:01 PM, Geoff Arnold ge...@geoffarnold.com
 mailto:ge...@geoffarnold.com wrote:

 I’m looking at implementing dynamically-configured multi-region
 support for service federation, and the prior art on multi-region
 support in Horizon is pretty sketchy. This thread:
 http://lists.openstack.org/pipermail/openstack/2014-January/004372.html
 is the only real discussion I’ve found, and it’s pretty inconclusive.

 More precisely, if I configure a single Horizon with AVAILABLE_REGIONS
 pointing at two different Keystones with region names “X” and “Y, and
 each of those Keystones returns a service catalog with multiple
 regions (“A” and “B” for one, “P”, “Q”, and “R” for the other), what’s
 Horizon going to do? Or rather, what’s it expected to do?

 Yes, I’m being lazy: I could actually configure this to see what
 happens, but hopefully it was considered during the design.

 Geoff

 PS I’ve added Heat to the subject, because from a quick read of
 https://wiki.openstack.org/wiki/Heat/Blueprints/Multi_Region_Support_for_Heat
 it looks as if Heat won’t support the AVAILABLE_REGIONS model. That
 seems like an unfortunate disconnect.



 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 
 
 
 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [horizon][keystone][heat] Are AVAILABLE_REGIONS and multi-region service catalog mutually exclusive?

[Geoff Arnold]

Further digging suggests that we might consider deprecating AVAILABLE_REGIONS 
in Horizon and enhancing the multi-region support in Keystone. It wouldn’t take 
a lot; the main points:
Implement the Regions API discussed back in the Havana time period - 
https://etherpad.openstack.org/p/havana-availability-zone-and-region-management 
https://etherpad.openstack.org/p/havana-availability-zone-and-region-management
 - but with full CRUD
Enhance the Endpoints API to allow filtering by region
Supporting two different multi region models is problematic if we’re serious 
about things like multi-region Heat.

Thoughts?

Geoff

 On May 13, 2015, at 12:01 PM, Geoff Arnold ge...@geoffarnold.com wrote:
 
 I’m looking at implementing dynamically-configured multi-region support for 
 service federation, and the prior art on multi-region support in Horizon is 
 pretty sketchy. This thread:
 http://lists.openstack.org/pipermail/openstack/2014-January/004372.html
 is the only real discussion I’ve found, and it’s pretty inconclusive.
 
 More precisely, if I configure a single Horizon with AVAILABLE_REGIONS 
 pointing at two different Keystones with region names “X” and “Y, and each 
 of those Keystones returns a service catalog with multiple regions (“A” and 
 “B” for one, “P”, “Q”, and “R” for the other), what’s Horizon going to do? Or 
 rather, what’s it expected to do?
 
 Yes, I’m being lazy: I could actually configure this to see what happens, but 
 hopefully it was considered during the design.
 
 Geoff
 
 PS I’ve added Heat to the subject, because from a quick read of 
 https://wiki.openstack.org/wiki/Heat/Blueprints/Multi_Region_Support_for_Heat 
 it looks as if Heat won’t support the AVAILABLE_REGIONS model. That seems 
 like an unfortunate disconnect.
 
 
 
 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [horizon][keystone][heat] Are AVAILABLE_REGIONS and multi-region service catalog mutually exclusive?

[Geoff Arnold]

I’m looking at implementing dynamically-configured multi-region support for 
service federation, and the prior art on multi-region support in Horizon is 
pretty sketchy. This thread:
http://lists.openstack.org/pipermail/openstack/2014-January/004372.html
is the only real discussion I’ve found, and it’s pretty inconclusive.

More precisely, if I configure a single Horizon with AVAILABLE_REGIONS pointing 
at two different Keystones with region names “X” and “Y, and each of those 
Keystones returns a service catalog with multiple regions (“A” and “B” for one, 
“P”, “Q”, and “R” for the other), what’s Horizon going to do? Or rather, what’s 
it expected to do?

Yes, I’m being lazy: I could actually configure this to see what happens, but 
hopefully it was considered during the design.

Geoff

PS I’ve added Heat to the subject, because from a quick read of 
https://wiki.openstack.org/wiki/Heat/Blueprints/Multi_Region_Support_for_Heat 
it looks as if Heat won’t support the AVAILABLE_REGIONS model. That seems like 
an unfortunate disconnect.



__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [horizon][keystone][heat] Are AVAILABLE_REGIONS and multi-region service catalog mutually exclusive?

[David Lyle]

On Wed, May 13, 2015 at 3:24 PM, Mathieu Gagné mga...@iweb.com wrote:

 When using AVAILABLE_REGIONS, you get a dropdown at login time to choose
 your region which is in fact your keystone endpoint.

 Once logged in, you get a new dropdown at the top right to switch
 between the keystone endpoints. This means you can configure an
 Horizon installation to login to multiple independent OpenStack
 installations.

 So I don't fully understand what enhancing the multi-region support in
 Keystone would mean. Would you be able to configure Horizon to login to
 multiple independent OpenStack installations?

 Mathieu

 On 2015-05-13 5:06 PM, Geoff Arnold wrote:
  Further digging suggests that we might consider deprecating
  AVAILABLE_REGIONS in Horizon and enhancing the multi-region support in
  Keystone. It wouldn’t take a lot; the main points:
 
* Implement the Regions API discussed back in the Havana time period
  -
 https://etherpad.openstack.org/p/havana-availability-zone-and-region-management
 -
  but with full CRUD
* Enhance the Endpoints API to allow filtering by region
 
  Supporting two different multi region models is problematic if we’re
  serious about things like multi-region Heat.
 
  Thoughts?
 
  Geoff
 
  On May 13, 2015, at 12:01 PM, Geoff Arnold ge...@geoffarnold.com
  mailto:ge...@geoffarnold.com wrote:
 
  I’m looking at implementing dynamically-configured multi-region
  support for service federation, and the prior art on multi-region
  support in Horizon is pretty sketchy. This thread:
  http://lists.openstack.org/pipermail/openstack/2014-January/004372.html
  is the only real discussion I’ve found, and it’s pretty inconclusive.
 
  More precisely, if I configure a single Horizon with AVAILABLE_REGIONS
  pointing at two different Keystones with region names “X” and “Y, and
  each of those Keystones returns a service catalog with multiple
  regions (“A” and “B” for one, “P”, “Q”, and “R” for the other), what’s
  Horizon going to do? Or rather, what’s it expected to do?
 
  Yes, I’m being lazy: I could actually configure this to see what
  happens, but hopefully it was considered during the design.
 
  Geoff
 
  PS I’ve added Heat to the subject, because from a quick read of
 
 https://wiki.openstack.org/wiki/Heat/Blueprints/Multi_Region_Support_for_Heat
  it looks as if Heat won’t support the AVAILABLE_REGIONS model. That
  seems like an unfortunate disconnect.
 
 
 


Horizon only supports authenticating to one keystone endpoint at a time,
specifically to one of the entries in AVAILABLE_REGIONS as defined in
settings.py. Once you have an authenticated session in Horizon, the region
selection support is merely for filtering between regions registered with
the keystone endpoint you authenticated to, where the list of regions is
determined by parsing the service catalog returned to you with your token.

What's really unclear to me is what you are intending to ask.

AVAILABLE_REGIONS is merely a list of keystone endpoints. They can be
backed by a different IdP per endpoint and thus not share a token store.
Or, they can just be keystone endpoints that are geographically different
but backed by the same IdP, which may or may not share a token store. The
funny thing is, for Horizon, it doesn't matter. They are all supported.
But as one keystone endpoint may not know about another, unless nested,
this has to be done with settings as it's not typically discoverable.

If you are asking about token sharing between keystones which the thread
you linked seems to indicate. Then yes, you can have a synced token store.
But that is an exercise left to the operator.

David
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [horizon] Keystone token expiration causes user to be logged out

[Morgan Fainberg]

On Tue, Apr 14, 2015 at 5:25 PM, Lin Hua Cheng os.lch...@gmail.com wrote:


 That is the expected behavior. Horizon does not support extendable session
 token.

 From my understanding on that spec, it would require Horizon to store only
 the unscoped token and request for extension of that from keystone.

 Horizon is currently dependent on the project scoped token and store that
 in the session.

 We have to make changes in how project scoped token is managed in Horizon
 and just store the unscoped token to support that feature.

 -Lin

 On Tue, Apr 14, 2015 at 4:26 PM, Brad Pokorny brad_poko...@symantec.com
 wrote:

 Hi all,

 When a user is logged into Horizon and the Keystone token expires, I'm
 seeing that the user gets logged out, even though the web session hasn't
 expired.  After some searching around and finding [1], it looks like this
 is expected, as the implementation of Session Extendable Tokens would allow
 applications such as Horizon to fetch another token when the existing token
 expires.

 Is there anything I've missed in the Horizon implementation that would
 currently allow extension of the token?

 [1]
 https://blueprints.launchpad.net/keystone/+spec/session-extendable-tokens

 Thanks,
 Brad


To add, the session Extendable token is not implemented.

--Morgan
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [horizon] Keystone token expiration causes user to be logged out

[Lin Hua Cheng]

That is the expected behavior. Horizon does not support extendable session
token.

From my understanding on that spec, it would require Horizon to store only
the unscoped token and request for extension of that from keystone.

Horizon is currently dependent on the project scoped token and store that
in the session.

We have to make changes in how project scoped token is managed in Horizon
and just store the unscoped token to support that feature.

-Lin

On Tue, Apr 14, 2015 at 4:26 PM, Brad Pokorny brad_poko...@symantec.com
wrote:

 Hi all,

 When a user is logged into Horizon and the Keystone token expires, I'm
 seeing that the user gets logged out, even though the web session hasn't
 expired.  After some searching around and finding [1], it looks like this
 is expected, as the implementation of Session Extendable Tokens would allow
 applications such as Horizon to fetch another token when the existing token
 expires.

 Is there anything I've missed in the Horizon implementation that would
 currently allow extension of the token?

 [1]
 https://blueprints.launchpad.net/keystone/+spec/session-extendable-tokens

 Thanks,
 Brad

 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [horizon] Keystone token expiration causes user to be logged out

[Brad Pokorny]

Hi all,

When a user is logged into Horizon and the Keystone token expires, I'm seeing 
that the user gets logged out, even though the web session hasn't expired.  
After some searching around and finding [1], it looks like this is expected, as 
the implementation of Session Extendable Tokens would allow applications such 
as Horizon to fetch another token when the existing token expires.

Is there anything I've missed in the Horizon implementation that would 
currently allow extension of the token?

[1] https://blueprints.launchpad.net/keystone/+spec/session-extendable-tokens

Thanks,
Brad
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Horizon][Keystone] Failed to set up keystone v3 api for horizon

[Lin Hua Cheng]

Hi,

The 'cloud_admin' policy file requires domain-scoped to work to work.

Horizon does not currently support domain scope token yet. So yes, it is a
gap in horizon at the moment.

There are on-going patches to address this in horizon:
- https://review.openstack.org/#/c/141153/
- https://review.openstack.org/#/c/148082/

Dan (esp) prepared a nicely written document on this should eventually work.

-Lin

On Wed, Mar 11, 2015 at 7:33 PM, Lei Zhang zhang.lei@gmail.com wrote:

 is there anyone tryed this and successfully?

 On Mon, Mar 9, 2015 at 4:25 PM, Lei Zhang zhang.lei@gmail.com wrote:

 Hi guys,

 I am setting up the keytone v3 api. Now I meet a issue about the
 `cloud_admin` policy.

 Base on the
 http://www.florentflament.com/blog/setting-keystone-v3-domains.html
 article, I modify the cloud_admin policy to

 ```
 cloud_admin: rule:admin_required and
 domain_id:ef0d30167f744401a0cbfcc938ea7d63,
 ```

 But the cloud_admin don't work as expected. I failed to open all the
 identity panel ( like http://host/horizon/identity/domains/)
 Horizon tell me Error: Unable to retrieve project list.
 And keystone log warning:

 ```
 2015-03-09 16:00:06.423 9415 DEBUG keystone.policy.backends.rules [-]
 enforce identity:list_user_projects: {'is_delegated_auth': False,
 'access_token_id': None, 'user_id': u'6433222efd78459bb70ad9adbcfac418',
 'roles': [u'_member_', u'admin'], 'trustee_id': None, 'trustor_id': None,
 'consumer_id': None, 'token': KeystoneToken
 (audit_id=DWsSa6yYSWi0ht9E7q4uhw, audit_chain_id=w_zLBBeFQ82KevtJrdKIJw) at
 0x7f4503fab3c8, 'project_id': u'4d170baaa89b4e46b239249eb5ec6b00',
 'trust_id': None}, enforce
 /usr/lib/python2.7/dist-packages/keystone/policy/backends/rules.py:100
 2015-03-09 16:00:06.061 9410 WARNING keystone.common.wsgi [-] You are not
 authorized to perform the requested action: identity:list_projects (Disable
 debug mode to suppress these details.)
 ```

 ​I make some debug and found that, the root cause is that the `context`
 variable in keystone has no `domain_id` field( like the above keystone
 log). So the `cloud_admin` rule failed.​ if i change the `cloud_admin` to
 following. It works as expected.

 ```
 cloud_admin: rule:admin_required and user_id:
 6433222efd78459bb70ad9adbcfac418,
 ```

 I found that in the keystone code[0], the domain_id only exist when it is
 a domain scope. But i believe that the horizon login token is a project
 one( I am not very sure this)

 ```
 if token.project_scoped:
 auth_context['project_id'] = token.project_id
 elif token.domain_scoped:
 auth_context['domain_id'] = token.domain_id
 else:
 LOG.debug('RBAC: Proceeding without project or domain scope')

 ```

 Is it a bug? or some wrong configuration?


 Following is my configuration.


 ```
 # /etc/keystone/keystone.conf
 [DEFAULT]
 debug=true
 verbose=true
 log_dir=/var/log/keystone
 [assignment]
 driver = keystone.assignment.backends.sql.Assignment
 [database]
 connection=mysql://:@controller/keystone
 [identity]
 driver=keystone.identity.backends.sql.Identity
 [memcache]
 servers=controller1:11211,controller2:11211,controller3:1121
 [token]
 provider=keystone.token.providers.uuid.Provider
 ```

 ```
 # /etc/openstack-dashboard/local_settings.py ( partly )
 POLICY_FILES_PATH = /etc/openstack-dashboard/
 POLICY_FILES = {
 'identity': 'keystone_policy.json',
 }
 OPENSTACK_HOST = 127.0.0.1
 OPENSTACK_KEYSTONE_URL = http://%s:5000/v3; % OPENSTACK_HOST
 OPENSTACK_KEYSTONE_DEFAULT_ROLE = _member_
 OPENSTACK_API_VERSIONS = {
  data_processing: 1.1,
  identity: 3,
  volume: 2
 }
 OPENSTACK_KEYSTONE_MULTIDOMAIN_SUPPORT = True
 OPENSTACK_KEYSTONE_DEFAULT_DOMAIN = 'admin'
 ```

 ​[0]
 https://github.com/openstack/keystone/blob/master/keystone/common/authorization.py#L58
 ​

 --
 Lei Zhang
 Blog: http://xcodest.me
 twitter/weibo: @jeffrey4l




 --
 Lei Zhang
 Blog: http://xcodest.me
 twitter/weibo: @jeffrey4l

 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Horizon][Keystone] Failed to set up keystone v3 api for horizon

[Lei Zhang]

Hi Lin,

This two PS is what I wanted. Thx a lot.

btw, is it possible that these PS finished in Kilo?

On Thu, Mar 12, 2015 at 5:41 PM, Lin Hua Cheng os.lch...@gmail.com wrote:

 Hi,

 The 'cloud_admin' policy file requires domain-scoped to work to work.

 Horizon does not currently support domain scope token yet. So yes, it is a
 gap in horizon at the moment.

 There are on-going patches to address this in horizon:
 - https://review.openstack.org/#/c/141153/
 - https://review.openstack.org/#/c/148082/

 Dan (esp) prepared a nicely written document on this should eventually
 work.

 -Lin

 On Wed, Mar 11, 2015 at 7:33 PM, Lei Zhang zhang.lei@gmail.com
 wrote:

 is there anyone tryed this and successfully?

 On Mon, Mar 9, 2015 at 4:25 PM, Lei Zhang zhang.lei@gmail.com
 wrote:

 Hi guys,

 I am setting up the keytone v3 api. Now I meet a issue about the
 `cloud_admin` policy.

 Base on the
 http://www.florentflament.com/blog/setting-keystone-v3-domains.html
 article, I modify the cloud_admin policy to

 ```
 cloud_admin: rule:admin_required and
 domain_id:ef0d30167f744401a0cbfcc938ea7d63,
 ```

 But the cloud_admin don't work as expected. I failed to open all the
 identity panel ( like http://host/horizon/identity/domains/)
 Horizon tell me Error: Unable to retrieve project list.
 And keystone log warning:

 ```
 2015-03-09 16:00:06.423 9415 DEBUG keystone.policy.backends.rules [-]
 enforce identity:list_user_projects: {'is_delegated_auth': False,
 'access_token_id': None, 'user_id': u'6433222efd78459bb70ad9adbcfac418',
 'roles': [u'_member_', u'admin'], 'trustee_id': None, 'trustor_id': None,
 'consumer_id': None, 'token': KeystoneToken
 (audit_id=DWsSa6yYSWi0ht9E7q4uhw, audit_chain_id=w_zLBBeFQ82KevtJrdKIJw) at
 0x7f4503fab3c8, 'project_id': u'4d170baaa89b4e46b239249eb5ec6b00',
 'trust_id': None}, enforce
 /usr/lib/python2.7/dist-packages/keystone/policy/backends/rules.py:100
 2015-03-09 16:00:06.061 9410 WARNING keystone.common.wsgi [-] You are
 not authorized to perform the requested action: identity:list_projects
 (Disable debug mode to suppress these details.)
 ```

 ​I make some debug and found that, the root cause is that the `context`
 variable in keystone has no `domain_id` field( like the above keystone
 log). So the `cloud_admin` rule failed.​ if i change the `cloud_admin` to
 following. It works as expected.

 ```
 cloud_admin: rule:admin_required and user_id:
 6433222efd78459bb70ad9adbcfac418,
 ```

 I found that in the keystone code[0], the domain_id only exist when it
 is a domain scope. But i believe that the horizon login token is a project
 one( I am not very sure this)

 ```
 if token.project_scoped:
 auth_context['project_id'] = token.project_id
 elif token.domain_scoped:
 auth_context['domain_id'] = token.domain_id
 else:
 LOG.debug('RBAC: Proceeding without project or domain scope')

 ```

 Is it a bug? or some wrong configuration?


 Following is my configuration.


 ```
 # /etc/keystone/keystone.conf
 [DEFAULT]
 debug=true
 verbose=true
 log_dir=/var/log/keystone
 [assignment]
 driver = keystone.assignment.backends.sql.Assignment
 [database]
 connection=mysql://:@controller/keystone
 [identity]
 driver=keystone.identity.backends.sql.Identity
 [memcache]
 servers=controller1:11211,controller2:11211,controller3:1121
 [token]
 provider=keystone.token.providers.uuid.Provider
 ```

 ```
 # /etc/openstack-dashboard/local_settings.py ( partly )
 POLICY_FILES_PATH = /etc/openstack-dashboard/
 POLICY_FILES = {
 'identity': 'keystone_policy.json',
 }
 OPENSTACK_HOST = 127.0.0.1
 OPENSTACK_KEYSTONE_URL = http://%s:5000/v3; % OPENSTACK_HOST
 OPENSTACK_KEYSTONE_DEFAULT_ROLE = _member_
 OPENSTACK_API_VERSIONS = {
  data_processing: 1.1,
  identity: 3,
  volume: 2
 }
 OPENSTACK_KEYSTONE_MULTIDOMAIN_SUPPORT = True
 OPENSTACK_KEYSTONE_DEFAULT_DOMAIN = 'admin'
 ```

 ​[0]
 https://github.com/openstack/keystone/blob/master/keystone/common/authorization.py#L58
 ​

 --
 Lei Zhang
 Blog: http://xcodest.me
 twitter/weibo: @jeffrey4l




 --
 Lei Zhang
 Blog: http://xcodest.me
 twitter/weibo: @jeffrey4l

 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe:
 openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




-- 
Lei Zhang
Blog: http://xcodest.me
twitter/weibo: @jeffrey4l
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe

Re: [openstack-dev] [Horizon][Keystone] Failed to set up keystone v3 api for horizon

[Ali, Haneef]

Horizon needs to support domain scoped token for this to work. I don’t think it 
is yet there.

https://review.openstack.org/#/c/148082/39
https://review.openstack.org/#/c/141153/

Thanks
Haneef

From: Lei Zhang [mailto:zhang.lei@gmail.com]
Sent: Wednesday, March 11, 2015 7:33 PM
To: openstack; OpenStack Development Mailing List
Subject: [openstack-dev] [Horizon][Keystone] Failed to set up keystone v3 api 
for horizon

is there anyone tryed this and successfully?

On Mon, Mar 9, 2015 at 4:25 PM, Lei Zhang 
zhang.lei@gmail.commailto:zhang.lei@gmail.com wrote:
Hi guys,

I am setting up the keytone v3 api. Now I meet a issue about the `cloud_admin` 
policy.

Base on the http://www.florentflament.com/blog/setting-keystone-v3-domains.html 
article, I modify the cloud_admin policy to

```
cloud_admin: rule:admin_required and 
domain_id:ef0d30167f744401a0cbfcc938ea7d63,
```

But the cloud_admin don't work as expected. I failed to open all the identity 
panel ( like 
http://host/horizon/identity/domains/http://%3chost%3e/horizon/identity/domains/)
Horizon tell me Error: Unable to retrieve project list.
And keystone log warning:

```
2015-03-09 16:00:06.423 9415 DEBUG keystone.policy.backends.rules [-] enforce 
identity:list_user_projects: {'is_delegated_auth': False, 'access_token_id': 
None, 'user_id': u'6433222efd78459bb70ad9adbcfac418', 'roles': [u'_member_', 
u'admin'], 'trustee_id': None, 'trustor_id': None, 'consumer_id': None, 
'token': KeystoneToken (audit_id=DWsSa6yYSWi0ht9E7q4uhw, 
audit_chain_id=w_zLBBeFQ82KevtJrdKIJw) at 0x7f4503fab3c8, 'project_id': 
u'4d170baaa89b4e46b239249eb5ec6b00', 'trust_id': None}, enforce 
/usr/lib/python2.7/dist-packages/keystone/policy/backends/rules.py:100
2015-03-09 16:00:06.061 9410 WARNING keystone.common.wsgi [-] You are not 
authorized to perform the requested action: identity:list_projects (Disable 
debug mode to suppress these details.)
```

​I make some debug and found that, the root cause is that the `context` 
variable in keystone has no `domain_id` field( like the above keystone log). So 
the `cloud_admin` rule failed.​ if i change the `cloud_admin` to following. It 
works as expected.

```
cloud_admin: rule:admin_required and 
user_id:6433222efd78459bb70ad9adbcfac418,
```

I found that in the keystone code[0], the domain_id only exist when it is a 
domain scope. But i believe that the horizon login token is a project one( I am 
not very sure this)

```
if token.project_scoped:
auth_context['project_id'] = token.project_id
elif token.domain_scoped:
auth_context['domain_id'] = token.domain_id
else:
LOG.debug('RBAC: Proceeding without project or domain scope')

```

Is it a bug? or some wrong configuration?


Following is my configuration.


```
# /etc/keystone/keystone.conf
[DEFAULT]
debug=true
verbose=true
log_dir=/var/log/keystone
[assignment]
driver = keystone.assignment.backends.sql.Assignment
[database]
connection=mysql://:@controller/keystone
[identity]
driver=keystone.identity.backends.sql.Identity
[memcache]
servers=controller1:11211,controller2:11211,controller3:1121
[token]
provider=keystone.token.providers.uuid.Provider
```

```
# /etc/openstack-dashboard/local_settings.py ( partly )
POLICY_FILES_PATH = /etc/openstack-dashboard/
POLICY_FILES = {
'identity': 'keystone_policy.json',
}
OPENSTACK_HOST = 127.0.0.1
OPENSTACK_KEYSTONE_URL = http://%s:5000/v3http://%25s:5000/v3 % 
OPENSTACK_HOST
OPENSTACK_KEYSTONE_DEFAULT_ROLE = _member_
OPENSTACK_API_VERSIONS = {
 data_processing: 1.1,
 identity: 3,
 volume: 2
}
OPENSTACK_KEYSTONE_MULTIDOMAIN_SUPPORT = True
OPENSTACK_KEYSTONE_DEFAULT_DOMAIN = 'admin'
```

​[0] 
https://github.com/openstack/keystone/blob/master/keystone/common/authorization.py#L58​

--
Lei Zhang
Blog: http://xcodest.me
twitter/weibo: @jeffrey4l



--
Lei Zhang
Blog: http://xcodest.me
twitter/weibo: @jeffrey4l
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Horizon][Keystone] Failed to set up keystone v3 api for horizon

[Doug Fish]

I'm sure additional feedback on those patches would be welcome and helpful 
toward getting them merged in Kilo

 On Mar 12, 2015, at 9:14 AM, Lei Zhang zhang.lei@gmail.com wrote:
 
 Hi Lin,
 
 This two PS is what I wanted. Thx a lot.
 
 btw, is it possible that these PS finished in Kilo?
 
 On Thu, Mar 12, 2015 at 5:41 PM, Lin Hua Cheng os.lch...@gmail.com wrote:
 Hi,
 
 The 'cloud_admin' policy file requires domain-scoped to work to work.
 
 Horizon does not currently support domain scope token yet. So yes, it is a 
 gap in horizon at the moment.
 
 There are on-going patches to address this in horizon: 
 - https://review.openstack.org/#/c/141153/
 - https://review.openstack.org/#/c/148082/
 
 Dan (esp) prepared a nicely written document on this should eventually work.
 
 -Lin
 
 On Wed, Mar 11, 2015 at 7:33 PM, Lei Zhang zhang.lei@gmail.com wrote:
 is there anyone tryed this and successfully?
 
 On Mon, Mar 9, 2015 at 4:25 PM, Lei Zhang zhang.lei@gmail.com wrote:
 Hi guys,
 
 I am setting up the keytone v3 api. Now I meet a issue about the 
 `cloud_admin` policy.
 
 Base on the 
 http://www.florentflament.com/blog/setting-keystone-v3-domains.html 
 article, I modify the cloud_admin policy to 
 
 ```
 cloud_admin: rule:admin_required and 
 domain_id:ef0d30167f744401a0cbfcc938ea7d63,
 ```
 
 But the cloud_admin don't work as expected. I failed to open all the 
 identity panel ( like http://host/horizon/identity/domains/)
 Horizon tell me Error: Unable to retrieve project list.
 And keystone log warning:  
 
 ```
 2015-03-09 16:00:06.423 9415 DEBUG keystone.policy.backends.rules [-] 
 enforce identity:list_user_projects: {'is_delegated_auth': False, 
 'access_token_id': None, 'user_id': u'6433222efd78459bb70ad9adbcfac418', 
 'roles': [u'_member_', u'admin'], 'trustee_id': None, 'trustor_id': None, 
 'consumer_id': None, 'token': KeystoneToken 
 (audit_id=DWsSa6yYSWi0ht9E7q4uhw, audit_chain_id=w_zLBBeFQ82KevtJrdKIJw) 
 at 0x7f4503fab3c8, 'project_id': u'4d170baaa89b4e46b239249eb5ec6b00', 
 'trust_id': None}, enforce 
 /usr/lib/python2.7/dist-packages/keystone/policy/backends/rules.py:100
 2015-03-09 16:00:06.061 9410 WARNING keystone.common.wsgi [-] You are not 
 authorized to perform the requested action: identity:list_projects 
 (Disable debug mode to suppress these details.) 
 ```
 
 ​I make some debug and found that, the root cause is that the `context` 
 variable in keystone has no `domain_id` field( like the above keystone 
 log). So the `cloud_admin` rule failed.​ if i change the `cloud_admin` to 
 following. It works as expected. 
 
 ```
 cloud_admin: rule:admin_required and 
 user_id:6433222efd78459bb70ad9adbcfac418,
 ```
 
 I found that in the keystone code[0], the domain_id only exist when it is 
 a domain scope. But i believe that the horizon login token is a project 
 one( I am not very sure this)
 
 ```
 if token.project_scoped:
 auth_context['project_id'] = token.project_id
 elif token.domain_scoped:
 auth_context['domain_id'] = token.domain_id
 else:
 LOG.debug('RBAC: Proceeding without project or domain scope')
 
 ```
 
 Is it a bug? or some wrong configuration? 
 
 
 Following is my configuration.
 
 
 ```
 # /etc/keystone/keystone.conf
 [DEFAULT]
 debug=true
 verbose=true
 log_dir=/var/log/keystone
 [assignment]
 driver = keystone.assignment.backends.sql.Assignment 
 [database]
 connection=mysql://:@controller/keystone
 [identity]
 driver=keystone.identity.backends.sql.Identity
 [memcache]
 servers=controller1:11211,controller2:11211,controller3:1121
 [token]
 provider=keystone.token.providers.uuid.Provider
 ```
 
 ```
 # /etc/openstack-dashboard/local_settings.py ( partly )
 POLICY_FILES_PATH = /etc/openstack-dashboard/
 POLICY_FILES = {
 'identity': 'keystone_policy.json',
 }
 OPENSTACK_HOST = 127.0.0.1
 OPENSTACK_KEYSTONE_URL = http://%s:5000/v3; % OPENSTACK_HOST
 OPENSTACK_KEYSTONE_DEFAULT_ROLE = _member_
 OPENSTACK_API_VERSIONS = {
  data_processing: 1.1,
  identity: 3,
  volume: 2
 }
 OPENSTACK_KEYSTONE_MULTIDOMAIN_SUPPORT = True
 OPENSTACK_KEYSTONE_DEFAULT_DOMAIN = 'admin'
 ``` 
 
 ​[0] 
 https://github.com/openstack/keystone/blob/master/keystone/common/authorization.py#L58​
 
 -- 
 Lei Zhang
 Blog: http://xcodest.me
 twitter/weibo: @jeffrey4l
 
 
 
 -- 
 Lei Zhang
 Blog: http://xcodest.me
 twitter/weibo: @jeffrey4l
 
 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 
 
 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 
 
 
 -- 
 Lei Zhang
 Blog: 

[openstack-dev] [Horizon][Keystone] Failed to set up keystone v3 api for horizon

[Lei Zhang]

is there anyone tryed this and successfully?

On Mon, Mar 9, 2015 at 4:25 PM, Lei Zhang zhang.lei@gmail.com wrote:

 Hi guys,

 I am setting up the keytone v3 api. Now I meet a issue about the
 `cloud_admin` policy.

 Base on the
 http://www.florentflament.com/blog/setting-keystone-v3-domains.html
 article, I modify the cloud_admin policy to

 ```
 cloud_admin: rule:admin_required and
 domain_id:ef0d30167f744401a0cbfcc938ea7d63,
 ```

 But the cloud_admin don't work as expected. I failed to open all the
 identity panel ( like http://host/horizon/identity/domains/)
 Horizon tell me Error: Unable to retrieve project list.
 And keystone log warning:

 ```
 2015-03-09 16:00:06.423 9415 DEBUG keystone.policy.backends.rules [-]
 enforce identity:list_user_projects: {'is_delegated_auth': False,
 'access_token_id': None, 'user_id': u'6433222efd78459bb70ad9adbcfac418',
 'roles': [u'_member_', u'admin'], 'trustee_id': None, 'trustor_id': None,
 'consumer_id': None, 'token': KeystoneToken
 (audit_id=DWsSa6yYSWi0ht9E7q4uhw, audit_chain_id=w_zLBBeFQ82KevtJrdKIJw) at
 0x7f4503fab3c8, 'project_id': u'4d170baaa89b4e46b239249eb5ec6b00',
 'trust_id': None}, enforce
 /usr/lib/python2.7/dist-packages/keystone/policy/backends/rules.py:100
 2015-03-09 16:00:06.061 9410 WARNING keystone.common.wsgi [-] You are not
 authorized to perform the requested action: identity:list_projects (Disable
 debug mode to suppress these details.)
 ```

 ​I make some debug and found that, the root cause is that the `context`
 variable in keystone has no `domain_id` field( like the above keystone
 log). So the `cloud_admin` rule failed.​ if i change the `cloud_admin` to
 following. It works as expected.

 ```
 cloud_admin: rule:admin_required and user_id:
 6433222efd78459bb70ad9adbcfac418,
 ```

 I found that in the keystone code[0], the domain_id only exist when it is
 a domain scope. But i believe that the horizon login token is a project
 one( I am not very sure this)

 ```
 if token.project_scoped:
 auth_context['project_id'] = token.project_id
 elif token.domain_scoped:
 auth_context['domain_id'] = token.domain_id
 else:
 LOG.debug('RBAC: Proceeding without project or domain scope')

 ```

 Is it a bug? or some wrong configuration?


 Following is my configuration.


 ```
 # /etc/keystone/keystone.conf
 [DEFAULT]
 debug=true
 verbose=true
 log_dir=/var/log/keystone
 [assignment]
 driver = keystone.assignment.backends.sql.Assignment
 [database]
 connection=mysql://:@controller/keystone
 [identity]
 driver=keystone.identity.backends.sql.Identity
 [memcache]
 servers=controller1:11211,controller2:11211,controller3:1121
 [token]
 provider=keystone.token.providers.uuid.Provider
 ```

 ```
 # /etc/openstack-dashboard/local_settings.py ( partly )
 POLICY_FILES_PATH = /etc/openstack-dashboard/
 POLICY_FILES = {
 'identity': 'keystone_policy.json',
 }
 OPENSTACK_HOST = 127.0.0.1
 OPENSTACK_KEYSTONE_URL = http://%s:5000/v3; % OPENSTACK_HOST
 OPENSTACK_KEYSTONE_DEFAULT_ROLE = _member_
 OPENSTACK_API_VERSIONS = {
  data_processing: 1.1,
  identity: 3,
  volume: 2
 }
 OPENSTACK_KEYSTONE_MULTIDOMAIN_SUPPORT = True
 OPENSTACK_KEYSTONE_DEFAULT_DOMAIN = 'admin'
 ```

 ​[0]
 https://github.com/openstack/keystone/blob/master/keystone/common/authorization.py#L58
 ​

 --
 Lei Zhang
 Blog: http://xcodest.me
 twitter/weibo: @jeffrey4l




-- 
Lei Zhang
Blog: http://xcodest.me
twitter/weibo: @jeffrey4l
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [horizon][keystone]

[Adam Young]

On 02/18/2015 12:02 PM, David Chadwick wrote:

I think this GUI is not intuitive to users and therefore should not be
encouraged or supported.
It is a fist hack.  I think you don't mean any gui  just that there 
are some warning flags raised by this design?




If you ask a user what does authenticate via a Discovery Service mean?
I think you will get some very strange answers. The same goes for
Authenticate using Default Protocol. Users will have no idea what that
means.


He's not a native English speaker.  We'll need to craft the text here, 
and also carefully review the nuances.  Then there are the international 
translations




There has been a lot of research into how to support federated
authentication and there is a lot of practical experience across the
academic world from dozens of countries for many years. Most
universities now use federated login on a daily basis. We should use
this experience and follow best practise (which sadly does not involve
the screens that are being proposed here).

If you want to read more you can read a Good Practice Guide here

https://discovery.refeds.org/

It should help you to redesign the login page
THanks for the links.  Very helpful.  Some of that might require some 
changes from Horizon, but Jamie has seen those issues also come up in 
the context of the Kerberos login, and we can work to make this a 
smoother experience.


David, we certainly could use some UX  feedback here. Unfortunately, my 
GO-TO team member has decided to GO-TO a trip around the world...who can 
we pull in to make this flow in with the rest of Horizon?






regards

David

On 18/02/2015 16:06, Dolph Mathews wrote:

On Fri, Feb 6, 2015 at 12:47 PM, Adam Young ayo...@redhat.com
mailto:ayo...@redhat.com wrote:

 On 02/04/2015 03:54 PM, Thai Q Tran wrote:

 Hi all,

 I have been helping with the websso effort and wanted to get some
 feedback.
 Basically, users are presented with a login screen where they can
 select: credentials, default protocol, or discovery service.
 If user selects credentials, it works exactly the same way it
 works today.
 If user selects default protocol or discovery service, they can
 choose to be redirected to those pages.

 Keep in mind that this is a prototype, early feedback will be good.
 Here are the relevant patches:
 https://review.openstack.org/#/c/136177/
 https://review.openstack.org/#/c/136178/
 https://review.openstack.org/#/c/151842/

 I have attached the files and present them below:



 Replace the dropdown with a specific link for each protocol type:

 SAML and OpenID  are the only real contenders at the moment, but we
 will not likely have so many that it will clutter up the page.


Agree, but the likelihood that a single IdP will support multiple
protocols is probably low. Keystone certainly supports that from an API
perspective, but I don't think it should be the default UX. Choose a
remote IdP first, and then if *that* IdP supports multiple federation
protocols, present them.
  



 Thanks for doing this.






 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe 
mailto:openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe:
 openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [horizon][keystone]

[David Chadwick]

Hi Adam

there is some work being done on this by HP, Intel and IBM, and they
have some designs at

http://invis.io

pieter.c.kruithof...@hp.com  can send you the details as he invited me
to comment on the designs, which I have done.

As you know, we already have our own federated Horizon login screen, and
this summer I am hoping to have another student integrate this into the
current release, as well as make some enhancements to it (like
type-ahead searching for IdPs)

regards

David

On 23/02/2015 15:54, Adam Young wrote:
 On 02/18/2015 12:02 PM, David Chadwick wrote:
 I think this GUI is not intuitive to users and therefore should not be
 encouraged or supported.
 It is a fist hack.  I think you don't mean any gui  just that there
 are some warning flags raised by this design?
 

 If you ask a user what does authenticate via a Discovery Service mean?
 I think you will get some very strange answers. The same goes for
 Authenticate using Default Protocol. Users will have no idea what that
 means.
 
 He's not a native English speaker.  We'll need to craft the text here,
 and also carefully review the nuances.  Then there are the international
 translations
 

 There has been a lot of research into how to support federated
 authentication and there is a lot of practical experience across the
 academic world from dozens of countries for many years. Most
 universities now use federated login on a daily basis. We should use
 this experience and follow best practise (which sadly does not involve
 the screens that are being proposed here).

 If you want to read more you can read a Good Practice Guide here

 https://discovery.refeds.org/

 It should help you to redesign the login page
 THanks for the links.  Very helpful.  Some of that might require some
 changes from Horizon, but Jamie has seen those issues also come up in
 the context of the Kerberos login, and we can work to make this a
 smoother experience.
 
 David, we certainly could use some UX  feedback here. Unfortunately, my
 GO-TO team member has decided to GO-TO a trip around the world...who can
 we pull in to make this flow in with the rest of Horizon?
 
 
 

 regards

 David

 On 18/02/2015 16:06, Dolph Mathews wrote:
 On Fri, Feb 6, 2015 at 12:47 PM, Adam Young ayo...@redhat.com
 mailto:ayo...@redhat.com wrote:

  On 02/04/2015 03:54 PM, Thai Q Tran wrote:
  Hi all,

  I have been helping with the websso effort and wanted to get some
  feedback.
  Basically, users are presented with a login screen where they can
  select: credentials, default protocol, or discovery service.
  If user selects credentials, it works exactly the same way it
  works today.
  If user selects default protocol or discovery service, they can
  choose to be redirected to those pages.

  Keep in mind that this is a prototype, early feedback will be
 good.
  Here are the relevant patches:
  https://review.openstack.org/#/c/136177/
  https://review.openstack.org/#/c/136178/
  https://review.openstack.org/#/c/151842/

  I have attached the files and present them below:


  Replace the dropdown with a specific link for each protocol type:

  SAML and OpenID  are the only real contenders at the moment, but we
  will not likely have so many that it will clutter up the page.


 Agree, but the likelihood that a single IdP will support multiple
 protocols is probably low. Keystone certainly supports that from an API
 perspective, but I don't think it should be the default UX. Choose a
 remote IdP first, and then if *that* IdP supports multiple federation
 protocols, present them.
  

  Thanks for doing this.





 
 __

  OpenStack Development Mailing List (not for usage questions)
  Unsubscribe:
 openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 mailto:openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

 
 __

  OpenStack Development Mailing List (not for usage questions)
  Unsubscribe:
  openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 
 http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




 __

 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe:
 openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

 __

 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe:
 openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 

Re: [openstack-dev] [horizon][keystone]

[David Chadwick]

I think this GUI is not intuitive to users and therefore should not be
encouraged or supported.

If you ask a user what does authenticate via a Discovery Service mean?
I think you will get some very strange answers. The same goes for
Authenticate using Default Protocol. Users will have no idea what that
means.

There has been a lot of research into how to support federated
authentication and there is a lot of practical experience across the
academic world from dozens of countries for many years. Most
universities now use federated login on a daily basis. We should use
this experience and follow best practise (which sadly does not involve
the screens that are being proposed here).

If you want to read more you can read a Good Practice Guide here

https://discovery.refeds.org/

It should help you to redesign the login page

regards

David

On 18/02/2015 16:06, Dolph Mathews wrote:
 
 On Fri, Feb 6, 2015 at 12:47 PM, Adam Young ayo...@redhat.com
 mailto:ayo...@redhat.com wrote:
 
 On 02/04/2015 03:54 PM, Thai Q Tran wrote:
 Hi all,

 I have been helping with the websso effort and wanted to get some
 feedback.
 Basically, users are presented with a login screen where they can
 select: credentials, default protocol, or discovery service.
 If user selects credentials, it works exactly the same way it
 works today.
 If user selects default protocol or discovery service, they can
 choose to be redirected to those pages.

 Keep in mind that this is a prototype, early feedback will be good.
 Here are the relevant patches:
 https://review.openstack.org/#/c/136177/
 https://review.openstack.org/#/c/136178/
 https://review.openstack.org/#/c/151842/

 I have attached the files and present them below:
 
 
 
 Replace the dropdown with a specific link for each protocol type:
 
 SAML and OpenID  are the only real contenders at the moment, but we
 will not likely have so many that it will clutter up the page.
 
 
 Agree, but the likelihood that a single IdP will support multiple
 protocols is probably low. Keystone certainly supports that from an API
 perspective, but I don't think it should be the default UX. Choose a
 remote IdP first, and then if *that* IdP supports multiple federation
 protocols, present them.
  
 
 
 Thanks for doing this.






 
 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: 
 openstack-dev-requ...@lists.openstack.org?subject:unsubscribe 
 mailto:openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 
 
 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe:
 openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 
 
 
 
 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [horizon][keystone]

[Dolph Mathews]

On Fri, Feb 6, 2015 at 12:47 PM, Adam Young ayo...@redhat.com wrote:

  On 02/04/2015 03:54 PM, Thai Q Tran wrote:

 Hi all,

 I have been helping with the websso effort and wanted to get some feedback.
 Basically, users are presented with a login screen where they can select:
 credentials, default protocol, or discovery service.
 If user selects credentials, it works exactly the same way it works today.
 If user selects default protocol or discovery service, they can choose to
 be redirected to those pages.

 Keep in mind that this is a prototype, early feedback will be good.
 Here are the relevant patches:
 https://review.openstack.org/#/c/136177/
 https://review.openstack.org/#/c/136178/
 https://review.openstack.org/#/c/151842/

 I have attached the files and present them below:




 Replace the dropdown with a specific link for each protocol type:

 SAML and OpenID  are the only real contenders at the moment, but we will
 not likely have so many that it will clutter up the page.


Agree, but the likelihood that a single IdP will support multiple protocols
is probably low. Keystone certainly supports that from an API perspective,
but I don't think it should be the default UX. Choose a remote IdP first,
and then if *that* IdP supports multiple federation protocols, present them.



 Thanks for doing this.







 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: 
 openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [horizon][keystone] SSO

[Anton Zemlyanov]

SSO (Single sign-on) is great. There are some problems, though:

1) If the cloud is private without Internet access, then a private SSO
service should be up and runnning
2) There is no such a thing as OpenStack ID. Should we use Launchpad?
Facebook login? Twitter?
3) Technical difficulties embedding SSO into website.

As SSO service is often located on the different domain, the browser opens
a new window, then open the SSO page there, then redirects to our page
that uses some cross domain messageing like postMessage to inform main page
of login results. The main page closes the popup. The stuff is rather
complex, Facebook and other social nets have SDKs that do all the stufff.

That's certainly not an easy task to make an SSO service, implement SSO SDK
and embed in into Horizon.

Anton

On Fri, Feb 6, 2015 at 11:03 PM, Tim Bell tim.b...@cern.ch wrote:



 From the sound of things, we’re not actually talking about SSO. If so, we
 would not be talking about the design of a login screen.



 An SSO application such as Horizon would not have a login page. If the
 user was logged in already through corporate/organisation SSO page, nothing
 would appear before the standard Horizon page.



 We strongly encourage our user community that if there is any web page
 asking for your credentials which is not the CERN standard SSO page, it is
 not authorised. Our SSO also supports Google/Twitter/Eduroam etc. logins.
 Some of these will be refused for OpenStack login so that having a twitter
 account alone does not get you access to CERN’s cloud resources (but this
 is an authorisation rather than authentication problem).



 Is there really the use case for a site where there is SSO from a
 corporate perspective but there is not a federated login SSO capability ? I
 don’t have a fundamental problem with the approach but we should position
 it with respect to the use case which is that I login in the morning and
 all applications I use (cloud and all) are able to recognise that.



 Tim





 *From:* Adam Young [mailto:ayo...@redhat.com]
 *Sent:* 06 February 2015 19:48
 *To:* openstack-dev@lists.openstack.org
 *Subject:* Re: [openstack-dev] [horizon][keystone]



 On 02/04/2015 03:54 PM, Thai Q Tran wrote:

 Hi all,

 I have been helping with the websso effort and wanted to get some feedback.
 Basically, users are presented with a login screen where they can select:
 credentials, default protocol, or discovery service.
 If user selects credentials, it works exactly the same way it works today.
 If user selects default protocol or discovery service, they can choose to
 be redirected to those pages.

 Keep in mind that this is a prototype, early feedback will be good.
 Here are the relevant patches:
 https://review.openstack.org/#/c/136177/
 https://review.openstack.org/#/c/136178/
 https://review.openstack.org/#/c/151842/

 I have attached the files and present them below:




 Replace the dropdown with a specific link for each protocol type:

 SAML and OpenID  are the only real contenders at the moment, but we will
 not likely have so many that it will clutter up the page.

 Thanks for doing this.








  __

 OpenStack Development Mailing List (not for usage questions)

 Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe

 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [horizon][keystone] SSO)

[Stefano Maffulli]

On Mon, 2015-02-09 at 13:32 +0400, Anton Zemlyanov wrote:
 2) There is no such a thing as OpenStack ID. Should we use Launchpad?
 Facebook login? Twitter?
 
Actually, there is: https://openstackid.org :) It supports OpenID and
OAuth, the code is on
http://git.openstack.org/cgit/openstack-infra/openstackid/

It's in use right now for http://groups.openstack.org and it's planned
to be adopted by www.openstack.org, wiki, storyboard and all other
services that use Launchapd/Ubuntu OpenID with time, over the next
months.

I also know that Dan Radez would appreciate help to make keystone
support openstackid.org out-of-the-box so that http://trystack.org can
adopt it too (instead of facebook, as it is now).

/stef


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [horizon][keystone]

[Adam Young]

On 02/04/2015 03:54 PM, Thai Q Tran wrote:

Hi all,

I have been helping with the websso effort and wanted to get some 
feedback.
Basically, users are presented with a login screen where they can 
select: credentials, default protocol, or discovery service.

If user selects credentials, it works exactly the same way it works today.
If user selects default protocol or discovery service, they can choose 
to be redirected to those pages.


Keep in mind that this is a prototype, early feedback will be good.
Here are the relevant patches:
https://review.openstack.org/#/c/136177/
https://review.openstack.org/#/c/136178/
https://review.openstack.org/#/c/151842/

I have attached the files and present them below:




Replace the dropdown with a specific link for each protocol type:

SAML and OpenID  are the only real contenders at the moment, but we will 
not likely have so many that it will clutter up the page.


Thanks for doing this.







__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [horizon][keystone]

[Adam Young]

On 02/05/2015 04:20 AM, Anton Zemlyanov wrote:

Hi,

I guess Credentials is login and password. I have no idea what is 
Default Protocol or Discovery Service.

The proposed UI is rather embarrassing.
No it is not.  It is a rapid prototyping technique to get things to fail 
fast, and to get feedback from the community.  It would be embarrassing 
if this was made the final design with no review.


Please focus on constructive criticism. We want to encourage 
participation, and not belittle people attempting to make things better.





Anton

On Thu, Feb 5, 2015 at 12:54 AM, Thai Q Tran tqt...@us.ibm.com 
mailto:tqt...@us.ibm.com wrote:


Hi all,

I have been helping with the websso effort and wanted to get some
feedback.
Basically, users are presented with a login screen where they can
select: credentials, default protocol, or discovery service.
If user selects credentials, it works exactly the same way it
works today.
If user selects default protocol or discovery service, they can
choose to be redirected to those pages.

Keep in mind that this is a prototype, early feedback will be good.
Here are the relevant patches:
https://review.openstack.org/#/c/136177/
https://review.openstack.org/#/c/136178/
https://review.openstack.org/#/c/151842/

I have attached the files and present them below:





__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [horizon][keystone] SSO

[Tim Bell]

From the sound of things, we're not actually talking about SSO. If so, we 
would not be talking about the design of a login screen.

An SSO application such as Horizon would not have a login page. If the user was 
logged in already through corporate/organisation SSO page, nothing would appear 
before the standard Horizon page.

We strongly encourage our user community that if there is any web page asking 
for your credentials which is not the CERN standard SSO page, it is not 
authorised. Our SSO also supports Google/Twitter/Eduroam etc. logins. Some of 
these will be refused for OpenStack login so that having a twitter account 
alone does not get you access to CERN's cloud resources (but this is an 
authorisation rather than authentication problem).

Is there really the use case for a site where there is SSO from a corporate 
perspective but there is not a federated login SSO capability ? I don't have a 
fundamental problem with the approach but we should position it with respect to 
the use case which is that I login in the morning and all applications I use 
(cloud and all) are able to recognise that.

Tim


From: Adam Young [mailto:ayo...@redhat.com]
Sent: 06 February 2015 19:48
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [horizon][keystone]

On 02/04/2015 03:54 PM, Thai Q Tran wrote:
Hi all,

I have been helping with the websso effort and wanted to get some feedback.
Basically, users are presented with a login screen where they can select: 
credentials, default protocol, or discovery service.
If user selects credentials, it works exactly the same way it works today.
If user selects default protocol or discovery service, they can choose to be 
redirected to those pages.

Keep in mind that this is a prototype, early feedback will be good.
Here are the relevant patches:
https://review.openstack.org/#/c/136177/
https://review.openstack.org/#/c/136178/
https://review.openstack.org/#/c/151842/

I have attached the files and present them below:



Replace the dropdown with a specific link for each protocol type:

SAML and OpenID  are the only real contenders at the moment, but we will not 
likely have so many that it will clutter up the page.

Thanks for doing this.


[cid:image001.png@01D04247.35BD8B30][cid:image002.png@01D04247.35BD8B30][cid:image003.png@01D04247.35BD8B30][cid:image004.png@01D04247.35BD8B30]






__

OpenStack Development Mailing List (not for usage questions)

Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribemailto:openstack-dev-requ...@lists.openstack.org?subject:unsubscribe

http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [horizon][keystone]

[Fox, Kevin M]

But selecting from a list is harder then from a grid. A grid would give you 
ample room for icons, which also make finding what your looking for easier. 
Having a bit more space makes selecting the thing you want with a mouse(or 
finger on a tablet) easier.

To make it not visually overloaded, you hide the rest of the form bits then, 
once you select a method, user/password for example, the grid slides out of the 
way, and the username/pw box shows up. Leave the selected box up in the corner 
with an X on it, so they can cancel what they selected, and slide the grid back 
when clicked so they can select something different.

Thanks,
Kevin

From: Thai Q Tran [tqt...@us.ibm.com]
Sent: Thursday, February 05, 2015 11:15 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [horizon][keystone]

Hi Ioram,
Thanks for the feedback. I agree that the names are hard to follow, they can 
change to something more intuitive. Or we can even provide a tooltip for more 
information.
As for the look and feel, I don't agree that its easier if all the options are 
listed. Image if you had 5 different ways for users to log in and they are all 
shown at once. That's a lot to take in.
This approach keep things simply, it's really not that hard to pick from a list.

Hi Anton,
I'm just building on top of the visuals we already have without changing things 
too drastically. If you have a better idea, I would love to see it.

-Ioram Schechtman Sette i...@cin.ufpe.br wrote: -
To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.org
From: Ioram Schechtman Sette i...@cin.ufpe.br
Date: 02/05/2015 03:15AM
Subject: Re: [openstack-dev] [horizon][keystone]

Hi Thai,

I agree with Anton that the names are not intuitive for users.

I would use something like:
- Local authentication (for local credentials)
- ?? (I also have no idea of what is a Default protocol)
- Authenticate using name of IdPs or federation (something which is easy to 
the user understand that he could use or not - this is for the discovery 
service or remote IdP)

Here in the University of Kent we used another approach.
Instead of selecting the method using a list/combo box, we present all the 
options in a single screen.
I think it's not beautiful, but functional.
I think it would be easier to the user if they could have all the options in a 
single interface, since it doesn't become too much loaded (visually polluted).

[Imagem inline 1]
Regards,
Ioram


2015-02-05 9:20 GMT+00:00 Anton Zemlyanov 
azemlya...@mirantis.commailto:azemlya...@mirantis.com:
Hi,

I guess Credentials is login and password. I have no idea what is Default 
Protocol or Discovery Service.
The proposed UI is rather embarrassing.

Anton

On Thu, Feb 5, 2015 at 12:54 AM, Thai Q Tran 
tqt...@us.ibm.commailto:tqt...@us.ibm.com wrote:
Hi all,

I have been helping with the websso effort and wanted to get some feedback.
Basically, users are presented with a login screen where they can select: 
credentials, default protocol, or discovery service.
If user selects credentials, it works exactly the same way it works today.
If user selects default protocol or discovery service, they can choose to be 
redirected to those pages.

Keep in mind that this is a prototype, early feedback will be good.
Here are the relevant patches:
https://review.openstack.org/#/c/136177/
https://review.openstack.org/#/c/136178/
https://review.openstack.org/#/c/151842/

I have attached the files and present them below:

[cid:123937071170][cid:105849783951][cid:165446319914][cid:914204953945]



__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [horizon][keystone]

[Ioram Schechtman Sette]

Hi Thai,

I agree with Anton that the names are not intuitive for users.

I would use something like:
- Local authentication (for local credentials)
- ?? (I also have no idea of what is a Default protocol)
- Authenticate using name of IdPs or federation (something which is easy
to the user understand that he could use or not - this is for the discovery
service or remote IdP)

Here in the University of Kent we used another approach.
Instead of selecting the method using a list/combo box, we present all
the options in a single screen.
I think it's not beautiful, but functional.
I think it would be easier to the user if they could have all the options
in a single interface, since it doesn't become too much loaded (visually
polluted).

[image: Imagem inline 1]
Regards,
Ioram


2015-02-05 9:20 GMT+00:00 Anton Zemlyanov azemlya...@mirantis.com:

 Hi,

 I guess Credentials is login and password. I have no idea what is
 Default Protocol or Discovery Service.
 The proposed UI is rather embarrassing.

 Anton

 On Thu, Feb 5, 2015 at 12:54 AM, Thai Q Tran tqt...@us.ibm.com wrote:

 Hi all,

 I have been helping with the websso effort and wanted to get some
 feedback.
 Basically, users are presented with a login screen where they can select:
 credentials, default protocol, or discovery service.
 If user selects credentials, it works exactly the same way it works today.
 If user selects default protocol or discovery service, they can choose to
 be redirected to those pages.

 Keep in mind that this is a prototype, early feedback will be good.
 Here are the relevant patches:
 https://review.openstack.org/#/c/136177/
 https://review.openstack.org/#/c/136178/
 https://review.openstack.org/#/c/151842/

 I have attached the files and present them below:





 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe:
 openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [horizon][keystone]

[Marek Denis]

Thai,

We could also add an option in the Horizon's settings that automatically 
chooses one authentication workflow. At CERN we are trying to use websso 
with use of the SAML2 protocols as much as we can. That's said we 
automatically make users to use websso when they want to access their 
accounts via the dashboard.


Hint: This is being done by automatic redirect to predefined Keystone 
endpoint once user hits our dashboard's URL).


Marek


On 05.02.2015 20:15, Thai Q Tran wrote:

Hi Ioram,
Thanks for the feedback. I agree that the names are hard to follow, 
they can change to something more intuitive. Or we can even provide a 
tooltip for more information.
As for the look and feel, I don't agree that its easier if all the 
options are listed. Image if you had 5 different ways for users to log 
in and they are all shown at once. That's a lot to take in.
This approach keep things simply, it's really not that hard to pick 
from a list.


Hi Anton,
I'm just building on top of the visuals we already have without 
changing things too drastically. If you have a better idea, I would 
love to see it.


-Ioram Schechtman Sette i...@cin.ufpe.br wrote: -
To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.org

From: Ioram Schechtman Sette i...@cin.ufpe.br
Date: 02/05/2015 03:15AM
Subject: Re: [openstack-dev] [horizon][keystone]

Hi Thai,

I agree with Anton that the names are not intuitive for users.

I would use something like:
- Local authentication (for local credentials)
- ?? (I also have no idea of what is a Default protocol)
- Authenticate using name of IdPs or federation (something which is 
easy to the user understand that he could use or not - this is for the 
discovery service or remote IdP)


Here in the University of Kent we used another approach.
Instead of selecting the method using a list/combo box, we present 
all the options in a single screen.

I think it's not beautiful, but functional.
I think it would be easier to the user if they could have all the 
options in a single interface, since it doesn't become too much loaded 
(visually polluted).


Imagem inline 1
Regards,
Ioram


2015-02-05 9:20 GMT+00:00 Anton Zemlyanov azemlya...@mirantis.com 
mailto:azemlya...@mirantis.com:


Hi,

I guess Credentials is login and password. I have no idea what
is Default Protocol or Discovery Service.
The proposed UI is rather embarrassing.

Anton

On Thu, Feb 5, 2015 at 12:54 AM, Thai Q Tran tqt...@us.ibm.com
mailto:tqt...@us.ibm.com wrote:

Hi all,

I have been helping with the websso effort and wanted to get
some feedback.
Basically, users are presented with a login screen where they
can select: credentials, default protocol, or discovery service.
If user selects credentials, it works exactly the same way it
works today.
If user selects default protocol or discovery service, they
can choose to be redirected to those pages.

Keep in mind that this is a prototype, early feedback will be
good.
Here are the relevant patches:
https://review.openstack.org/#/c/136177/
https://review.openstack.org/#/c/136178/
https://review.openstack.org/#/c/151842/

I have attached the files and present them below:






__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



--
Marek Denis
[marek.de...@cern.ch]

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo

Re: [openstack-dev] [horizon][keystone]

[Marek Denis]

Hi,

I am more leaning towards layout Ioram suggested, but with 
protocols/other metods (Kerberos for instance) in the dropdown box.



On 05.02.2015 17:16, Steve Martinelli wrote:

Thanks Ioram,

From the keystone side: the one issue with listing IdPs is that some may
be private, so we're now looking to exploit the apache plugin data in the
environment (https://review.openstack.org/#/c/142743/), thus from the
horizon side the only data they need to send over would be the protocol
that the IdP uses.

What i'm taking away from some of the comments is to preserve the usual
(username and password) flow, and maybe it'll be easier to just list off
the protocols in a separate drop down (SAML and OpenID Connect).

Steve

Ioram Schechtman Sette i...@cin.ufpe.br wrote on 02/05/2015 06:04:36 AM:

 From: Ioram Schechtman Sette i...@cin.ufpe.br
 To: OpenStack Development Mailing List (not for usage questions)
 openstack-dev@lists.openstack.org
 Date: 02/05/2015 06:14 AM
 Subject: Re: [openstack-dev] [horizon][keystone]

 Hi Thai,

 I agree with Anton that the names are not intuitive for users.

 I would use something like:
 - Local authentication (for local credentials)
 - ?? (I also have no idea of what is a Default protocol)
 - Authenticate using name of IdPs or federation (something which
 is easy to the user understand that he could use or not - this is
 for the discovery service or remote IdP)

 Here in the University of Kent we used another approach.
 Instead of selecting the method using a list/combo box, we present
 all the options in a single screen.
 I think it's not beautiful, but functional.
 I think it would be easier to the user if they could have all the
 options in a single interface, since it doesn't become too much
 loaded (visually polluted).

 [image removed]
 Regards,
 Ioram

 2015-02-05 9:20 GMT+00:00 Anton Zemlyanov azemlya...@mirantis.com:
 Hi,

 I guess Credentials is login and password. I have no idea what is
 Default Protocol or Discovery Service.
 The proposed UI is rather embarrassing.

 Anton

 On Thu, Feb 5, 2015 at 12:54 AM, Thai Q Tran tqt...@us.ibm.com wrote:
 Hi all,

 I have been helping with the websso effort and wanted to get some 
feedback.

 Basically, users are presented with a login screen where they can
 select: credentials, default protocol, or discovery service.
 If user selects credentials, it works exactly the same way it works 
today.

 If user selects default protocol or discovery service, they can
 choose to be redirected to those pages.

 Keep in mind that this is a prototype, early feedback will be good.
 Here are the relevant patches:
 https://review.openstack.org/#/c/136177/
 https://review.openstack.org/#/c/136178/
 https://review.openstack.org/#/c/151842/

 I have attached the files and present them below:

 [image removed] [image removed] [image removed] [image removed]



 
__

 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe

 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



 
__

 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe

 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

 
__

 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe

 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



--
Marek Denis
[marek.de...@cern.ch]

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [horizon][keystone]

[Thai Q Tran]

Hi Ioram,Thanks for the feedback. I agree that the names are hard to follow, they can change to something more intuitive. Or we can even provide a tooltip for more information.As for the look and feel, I don't agree that its easier if all the options are listed. Image if you had 5 different ways for users to log in and they are all shown at once. That's a lot to take in.This approach keep things simply, it's really not that hard to pick from a list.Hi Anton,I'm just building on top of the visuals we already have without changing things too drastically. If you have a better idea, I would love to see it.-Ioram Schechtman Sette i...@cin.ufpe.br wrote: -To: "OpenStack Development Mailing List (not for usage questions)" openstack-dev@lists.openstack.orgFrom: Ioram Schechtman Sette i...@cin.ufpe.brDate: 02/05/2015 03:15AMSubject: Re: [openstack-dev] [horizon][keystone]Hi Thai,I agree with Anton that the names are not intuitive for users.I would use something like:- Local authentication (for local credentials)- ?? (I also have no idea of what is a Default protocol)- Authenticate using name of IdPs or federation (something which is easy to the user understand that he could use or not - this is for the discovery service or remote IdP)Here in the University of Kent we used another approach.Instead of selecting the method using a "list/combo" box, we present all the options in a single screen.I think it's not beautiful, but functional.I think it would be easier to the user if they could have all the options in a single interface, since it doesn't become too much loaded (visually polluted).Regards,Ioram2015-02-05 9:20 GMT+00:00 Anton Zemlyanov azemlya...@mirantis.com:Hi,I guess "Credentials" is login and password. I have no idea what is "Default Protocol" or "Discovery Service".The proposed UI is rather embarrassing.AntonOn Thu, Feb 5, 2015 at 12:54 AM, Thai Q Tran tqt...@us.ibm.com wrote:Hi all,I have been helping with the websso effort and wanted to get some feedback.Basically, users are presented with a login screen where they can select: credentials, default protocol, or discovery service.If user selects credentials, it works exactly the same way it works today.If user selects default protocol or discovery service, they can choose to be redirected to those pages.Keep in mind that this is a prototype, early feedback will be good.Here are the relevant patches:https://review.openstack.org/#/c/136177/https://review.openstack.org/#/c/136178/https://review.openstack.org/#/c/151842/I have attached the files and present them below:__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__OpenStack Development Mailing List (not for usage questions)Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [horizon][keystone]

[Thai Q Tran]

Marek,Yep, that makes a lot of sense. Can definitely add that.-Marek Denis marek.de...@cern.ch wrote: -To: openstack-dev@lists.openstack.orgFrom: Marek Denis marek.de...@cern.chDate: 02/05/2015 01:35PMSubject: Re: [openstack-dev] [horizon][keystone]
  

  
  
Thai,
  
  We could also add an option in the Horizon's settings that
  automatically chooses one authentication workflow. At CERN we are
  trying to use websso with use of the SAML2 protocols as much as we
  can. That's said we automatically make users to use websso when
  they want to access their accounts via the dashboard. 
  
  Hint: This is being done by automatic redirect to predefined
  Keystone endpoint once user hits our dashboard's URL).
  
  Marek
  
  
  On 05.02.2015 20:15, Thai Q Tran wrote:


  
  Hi Ioram,
Thanks for the feedback. I agree that the names are hard to
follow, they can change to something more intuitive. Or we can
even provide a tooltip for more information.
As for the look and feel, I don't agree that its easier if all
the options are listed. Image if you had 5 different ways for
users to log in and they are all shown at once. That's a lot to
take in.
This approach keep things simply, it's really not that hard to
pick from a list.

Hi Anton,
I'm just building on top of the visuals we already have without
changing things too drastically. If you have a better idea, I
would love to see it.

-Ioram Schechtman Sette
  i...@cin.ufpe.br wrote: -

  To: "OpenStack Development Mailing List (not for
usage questions)" openstack-dev@lists.openstack.org
From: Ioram Schechtman Sette i...@cin.ufpe.br
Date: 02/05/2015 03:15AM
Subject: Re: [openstack-dev] [horizon][keystone]


  

  

  

  
Hi Thai,
  
  I agree with Anton that the names are not
  intuitive for users.
  

I would use something like:
  
  - Local authentication (for local credentials)

- ?? (I also have no idea of what is a Default
protocol)
  
  - Authenticate using name of IdPs or
  federation (something which is easy to the
  user understand that he could use or not - this is
  for the discovery service or remote IdP)
  

Here in the University of Kent we used another
approach.
  
  Instead of selecting the method using a "list/combo"
  box, we present all the options in a single screen.

I think it's not beautiful, but functional.
  
  I think it would be easier to the user if they could have
  all the options in a single interface, since it doesn't
  become too much loaded (visually polluted).
  
  
  

  
Regards,
  Ioram


  

  

  

  

  2015-02-05
9:20 GMT+00:00 Anton Zemlyanov azemlya...@mirantis.com:

  Hi,


I guess "Credentials"
  is login and password. I
  have no idea what is
  "Default Protocol" or
  "Discovery Service".
The proposed UI is
  rather embarrassing.

Re: [openstack-dev] [horizon][keystone]

[Steve Martinelli]

Thanks Ioram,

From the keystone side: the one issue with listing IdPs is that some may
be private, so we're now looking to exploit the apache plugin data in the
environment (https://review.openstack.org/#/c/142743/), thus from the
horizon side the only data they need to send over would be the protocol
that the IdP uses.

What i'm taking away from some of the comments is to preserve the usual
(username and password) flow, and maybe it'll be easier to just list off
the protocols in a separate drop down (SAML and OpenID Connect).

Steve

Ioram Schechtman Sette i...@cin.ufpe.br wrote on 02/05/2015 06:04:36 AM:

 From: Ioram Schechtman Sette i...@cin.ufpe.br
 To: OpenStack Development Mailing List (not for usage questions) 
 openstack-dev@lists.openstack.org
 Date: 02/05/2015 06:14 AM
 Subject: Re: [openstack-dev] [horizon][keystone]
 
 Hi Thai,
 
 I agree with Anton that the names are not intuitive for users.

 I would use something like:
 - Local authentication (for local credentials)
 - ?? (I also have no idea of what is a Default protocol)
 - Authenticate using name of IdPs or federation (something which 
 is easy to the user understand that he could use or not - this is 
 for the discovery service or remote IdP)

 Here in the University of Kent we used another approach.
 Instead of selecting the method using a list/combo box, we present
 all the options in a single screen.
 I think it's not beautiful, but functional.
 I think it would be easier to the user if they could have all the 
 options in a single interface, since it doesn't become too much 
 loaded (visually polluted).
 
 [image removed] 
 Regards,
 Ioram
 
 2015-02-05 9:20 GMT+00:00 Anton Zemlyanov azemlya...@mirantis.com:
 Hi,
 
 I guess Credentials is login and password. I have no idea what is 
 Default Protocol or Discovery Service.
 The proposed UI is rather embarrassing.
 
 Anton
 
 On Thu, Feb 5, 2015 at 12:54 AM, Thai Q Tran tqt...@us.ibm.com wrote:
 Hi all,
 
 I have been helping with the websso effort and wanted to get some 
feedback.
 Basically, users are presented with a login screen where they can 
 select: credentials, default protocol, or discovery service.
 If user selects credentials, it works exactly the same way it works 
today.
 If user selects default protocol or discovery service, they can 
 choose to be redirected to those pages.
 
 Keep in mind that this is a prototype, early feedback will be good.
 Here are the relevant patches:
 https://review.openstack.org/#/c/136177/
 https://review.openstack.org/#/c/136178/
 https://review.openstack.org/#/c/151842/
 
 I have attached the files and present them below:
 
 [image removed] [image removed] [image removed] [image removed] 
 
 

 
__
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

 
 
 
__
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

 
__
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [horizon][keystone]

[Anton Zemlyanov]

Hi,

I guess Credentials is login and password. I have no idea what is
Default Protocol or Discovery Service.
The proposed UI is rather embarrassing.

Anton

On Thu, Feb 5, 2015 at 12:54 AM, Thai Q Tran tqt...@us.ibm.com wrote:

 Hi all,

 I have been helping with the websso effort and wanted to get some feedback.
 Basically, users are presented with a login screen where they can select:
 credentials, default protocol, or discovery service.
 If user selects credentials, it works exactly the same way it works today.
 If user selects default protocol or discovery service, they can choose to
 be redirected to those pages.

 Keep in mind that this is a prototype, early feedback will be good.
 Here are the relevant patches:
 https://review.openstack.org/#/c/136177/
 https://review.openstack.org/#/c/136178/
 https://review.openstack.org/#/c/151842/

 I have attached the files and present them below:





 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [horizon][keystone]

[Thai Q Tran]

Hi all,I have been helping with the websso effort and wanted to get some feedback.Basically, users are presented with a login screen where they can select: credentials, default protocol, or discovery service.If user selects credentials, it works exactly the same way it works today.If user selects default protocol or discovery service, they can choose to be redirected to those pages.Keep in mind that this is a prototype, early feedback will be good.Here are the relevant patches:https://review.openstack.org/#/c/136177/https://review.openstack.org/#/c/136178/https://review.openstack.org/#/c/151842/I have attached the files and present them below:__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Horizon][Keystone] Steps toward Kerberos and Federation

[Marco Fargetta]

Hi,

I am wondering if the solution I was trying to sketch with the spec
https://review.openstack.org/#/c/96867/13; is not easier to implement
and manage then the steps highlated till n.2. Maybe, the spec is not
yet there and should be improved (I will abandon or move to Kilo as
Marek suggest) but the overall schema I think it is better then try to
complicate the communication between Horizon and Keystone, IMHO.

Step 3 is a different story and it needs more evaluation of the
possible scenarios opened.

Cheers,
Marco

On Thu, Sep 04, 2014 at 05:37:38PM -0400, Adam Young wrote:
 While the Keystone team has made pretty good strides toward
 Federation for getting a Keystone token, we do not yet have a
 complete story for Horizon.  The same is true about Kerberos.  I've
 been working on this, and I want to inform the people that are
 interested in the approach, as well as get some feedback.
 
 My first priority has been Kerberos.  I have a proof of concept of
 this working, but the amount of hacking I had to
 Django-OpenStack-Auth (DOA) made me shudder:  its fairly ugly.  A
 few discussions today have moved things such that I think I can
 clean up the approach.
 
 Phase 1.  DOA should be able to tell whether to use password or
 Kerberos in order to get a token from Keystone based on an variable
 set by the Apache web server;  mod_auth_kerb will set
 
 request.META['KRB5CCNAME']
 
 only in the kerberos case.  If it gets this variable, DOA will only
 do Kerberos.  If it does not, it will only do password.  There will
 be no fallback from Kerberos to password;  this is enforced by
 mod_auth_kerb, not something we can easily hack around in Django.
 
 That gets us Kerberos, but not Federation. Most of the code changes
 are common with what follows after:
 
 Phase 1.5.  Add an optional field  to the password auth page that
 allows a user to log in with a token instead of userid/password.
 This can be a hidden field by default if we really want.  DOA now
 needs to be able to validate a token.  Since Horizon only cares
 about the hashed version of the tokens anyway, we only to Online
 lookup, not PKI token validation.  In the successful response,
 Keystone will to return the properly hashed (SHA256 for example) of
 the PKI tokens for Horizon to cache.
 
 Phase 2.  Use AJAX to get a token from Keystone instead of sending
 the credentials to the client.  Then pass that token to Horizon in
 order to login. This implies that Keystone has set up CORS support.
 This will open the door for Federation.  While it will provide a
 different path to Kerberos than the stage 1, I think both are
 valuable approaches and will serve different use cases.  This
 
 Phase 3.  Never send your token to Horizon.  In this world, the
 browser, with full CORS support, makes AJAX calls direct to Nova,
 Glance, and all other services.
 
 Yep, this should be a cross project session for the summit.
 
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




smime.p7s
Description: S/MIME cryptographic signature
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Horizon][Keystone] Steps toward Kerberos and Federation

[Adam Young]

On 09/05/2014 04:49 AM, Marco Fargetta wrote:

Hi,

I am wondering if the solution I was trying to sketch with the spec
https://review.openstack.org/#/c/96867/13; is not easier to implement
and manage then the steps highlated till n.2. Maybe, the spec is not
yet there and should be improved (I will abandon or move to Kilo as
Marek suggest) but the overall schema I think it is better then try to
complicate the communication between Horizon and Keystone, IMHO.

That is a very well written, detailed spec.  I'm impressed.

The S4U2Proxy/Step one stuff will be ready to go as soon as I drop off 
the Net for a while and clean up my patches.  But that doesn't address 
the Federation issue.


The Javascript approach is, I think, simpler and better than using 
OAUTH2 as you specify, as it is the direction that Horizon is going 
anyway: A single page App, Javascript driven,  talking direct to all the 
Remote Services.


I want to limit the number of services that get tokens.  I want to limit 
the scope of those tokens as much as possible.  Keeping passwords out of 
Horizon is just the first step to this goal.



As I see it Keystone tokens and the OAUTH* protocols are both ways of 
doing distributed single sign on and delegation of privileges. However,  
Keystone specifies data that is relevant to OpenStack, and OAUTH is 
necessarily format agnostic.  Using a different mechanism punts on the 
hard decisions and rewrites the easy ones.


Yes, I wish we had started with OAUTH way back a couple years ago, but I 
can't say it is so compelling that we should do it now.




Step 3 is a different story and it needs more evaluation of the
possible scenarios opened.

Cheers,
Marco

On Thu, Sep 04, 2014 at 05:37:38PM -0400, Adam Young wrote:

While the Keystone team has made pretty good strides toward
Federation for getting a Keystone token, we do not yet have a
complete story for Horizon.  The same is true about Kerberos.  I've
been working on this, and I want to inform the people that are
interested in the approach, as well as get some feedback.

My first priority has been Kerberos.  I have a proof of concept of
this working, but the amount of hacking I had to
Django-OpenStack-Auth (DOA) made me shudder:  its fairly ugly.  A
few discussions today have moved things such that I think I can
clean up the approach.

Phase 1.  DOA should be able to tell whether to use password or
Kerberos in order to get a token from Keystone based on an variable
set by the Apache web server;  mod_auth_kerb will set

 request.META['KRB5CCNAME']

only in the kerberos case.  If it gets this variable, DOA will only
do Kerberos.  If it does not, it will only do password.  There will
be no fallback from Kerberos to password;  this is enforced by
mod_auth_kerb, not something we can easily hack around in Django.

That gets us Kerberos, but not Federation. Most of the code changes
are common with what follows after:

Phase 1.5.  Add an optional field  to the password auth page that
allows a user to log in with a token instead of userid/password.
This can be a hidden field by default if we really want.  DOA now
needs to be able to validate a token.  Since Horizon only cares
about the hashed version of the tokens anyway, we only to Online
lookup, not PKI token validation.  In the successful response,
Keystone will to return the properly hashed (SHA256 for example) of
the PKI tokens for Horizon to cache.

Phase 2.  Use AJAX to get a token from Keystone instead of sending
the credentials to the client.  Then pass that token to Horizon in
order to login. This implies that Keystone has set up CORS support.
This will open the door for Federation.  While it will provide a
different path to Kerberos than the stage 1, I think both are
valuable approaches and will serve different use cases.  This

Phase 3.  Never send your token to Horizon.  In this world, the
browser, with full CORS support, makes AJAX calls direct to Nova,
Glance, and all other services.

Yep, this should be a cross project session for the summit.

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




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


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

Re: [openstack-dev] [Horizon][Keystone] Steps toward Kerberos and Federation

[Adam Young]

On 09/05/2014 11:28 AM, Marco Fargetta wrote:

I understand the general idea and the motivations but I am not sure
about the implementation. Even with a SPA you still need to provide
credentials and manage tokens for the authentication/authorisation in
a way not too much different from the current implementation.

Additionally, this might have some implications with the security since
you have to open the services to accept connection from clients everywhere.

Is there some schema/spec/pad/whatever describing this new approach for
Horizon and the other services?
I think several people are starting to discuss things along these lines, 
most under the Horizon heading.  I'm just trying to contribute the 
Keystone piece.


You are quite right about the security implications.  One potential 
approach is to use a Proxy for services and hide any behavior or APIs 
you don't want exposed to the outside world.  But in general, the 
services themselves should be hardened enough to be exposed directly to 
the public internet.  That is  the design of OpenStack.





Cheers,
Marco


On Fri, Sep 05, 2014 at 10:14:00AM -0400, Adam Young wrote:

On 09/05/2014 04:49 AM, Marco Fargetta wrote:

Hi,

I am wondering if the solution I was trying to sketch with the spec
https://review.openstack.org/#/c/96867/13; is not easier to implement
and manage then the steps highlated till n.2. Maybe, the spec is not
yet there and should be improved (I will abandon or move to Kilo as
Marek suggest) but the overall schema I think it is better then try to
complicate the communication between Horizon and Keystone, IMHO.

That is a very well written, detailed spec.  I'm impressed.

The S4U2Proxy/Step one stuff will be ready to go as soon as I drop
off the Net for a while and clean up my patches.  But that doesn't
address the Federation issue.

The Javascript approach is, I think, simpler and better than using
OAUTH2 as you specify, as it is the direction that Horizon is going
anyway: A single page App, Javascript driven,  talking direct to all
the Remote Services.

I want to limit the number of services that get tokens.  I want to
limit the scope of those tokens as much as possible.  Keeping
passwords out of Horizon is just the first step to this goal.


As I see it Keystone tokens and the OAUTH* protocols are both ways
of doing distributed single sign on and delegation of privileges.
However,  Keystone specifies data that is relevant to OpenStack, and
OAUTH is necessarily format agnostic.  Using a different mechanism
punts on the hard decisions and rewrites the easy ones.

Yes, I wish we had started with OAUTH way back a couple years ago,
but I can't say it is so compelling that we should do it now.


Step 3 is a different story and it needs more evaluation of the
possible scenarios opened.

Cheers,
Marco

On Thu, Sep 04, 2014 at 05:37:38PM -0400, Adam Young wrote:

While the Keystone team has made pretty good strides toward
Federation for getting a Keystone token, we do not yet have a
complete story for Horizon.  The same is true about Kerberos.  I've
been working on this, and I want to inform the people that are
interested in the approach, as well as get some feedback.

My first priority has been Kerberos.  I have a proof of concept of
this working, but the amount of hacking I had to
Django-OpenStack-Auth (DOA) made me shudder:  its fairly ugly.  A
few discussions today have moved things such that I think I can
clean up the approach.

Phase 1.  DOA should be able to tell whether to use password or
Kerberos in order to get a token from Keystone based on an variable
set by the Apache web server;  mod_auth_kerb will set

 request.META['KRB5CCNAME']

only in the kerberos case.  If it gets this variable, DOA will only
do Kerberos.  If it does not, it will only do password.  There will
be no fallback from Kerberos to password;  this is enforced by
mod_auth_kerb, not something we can easily hack around in Django.

That gets us Kerberos, but not Federation. Most of the code changes
are common with what follows after:

Phase 1.5.  Add an optional field  to the password auth page that
allows a user to log in with a token instead of userid/password.
This can be a hidden field by default if we really want.  DOA now
needs to be able to validate a token.  Since Horizon only cares
about the hashed version of the tokens anyway, we only to Online
lookup, not PKI token validation.  In the successful response,
Keystone will to return the properly hashed (SHA256 for example) of
the PKI tokens for Horizon to cache.

Phase 2.  Use AJAX to get a token from Keystone instead of sending
the credentials to the client.  Then pass that token to Horizon in
order to login. This implies that Keystone has set up CORS support.
This will open the door for Federation.  While it will provide a
different path to Kerberos than the stage 1, I think both are
valuable approaches and will serve different use cases.  This

Phase 3.  Never send your token to Horizon.  In this 

[openstack-dev] [Horizon][Keystone] Steps toward Kerberos and Federation

[Adam Young]

While the Keystone team has made pretty good strides toward Federation 
for getting a Keystone token, we do not yet have a complete story for 
Horizon.  The same is true about Kerberos.  I've been working on this, 
and I want to inform the people that are interested in the approach, as 
well as get some feedback.


My first priority has been Kerberos.  I have a proof of concept of this 
working, but the amount of hacking I had to Django-OpenStack-Auth (DOA) 
made me shudder:  its fairly ugly.  A few discussions today have moved 
things such that I think I can clean up the approach.


Phase 1.  DOA should be able to tell whether to use password or Kerberos 
in order to get a token from Keystone based on an variable set by the 
Apache web server;  mod_auth_kerb will set


request.META['KRB5CCNAME']

only in the kerberos case.  If it gets this variable, DOA will only do 
Kerberos.  If it does not, it will only do password.  There will be no 
fallback from Kerberos to password;  this is enforced by mod_auth_kerb, 
not something we can easily hack around in Django.


That gets us Kerberos, but not Federation. Most of the code changes are 
common with what follows after:


Phase 1.5.  Add an optional field  to the password auth page that allows 
a user to log in with a token instead of userid/password. This can be a 
hidden field by default if we really want.  DOA now needs to be able to 
validate a token.  Since Horizon only cares about the hashed version of 
the tokens anyway, we only to Online lookup, not PKI token validation.  
In the successful response, Keystone will to return the properly hashed 
(SHA256 for example) of the PKI tokens for Horizon to cache.


Phase 2.  Use AJAX to get a token from Keystone instead of sending the 
credentials to the client.  Then pass that token to Horizon in order to 
login. This implies that Keystone has set up CORS support. This will 
open the door for Federation.  While it will provide a different path to 
Kerberos than the stage 1, I think both are valuable approaches and will 
serve different use cases.  This


Phase 3.  Never send your token to Horizon.  In this world, the browser, 
with full CORS support, makes AJAX calls direct to Nova, Glance, and all 
other services.


Yep, this should be a cross project session for the summit.

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

Re: [openstack-dev] [Horizon][Keystone] Steps toward Kerberos and Federation

[Jamie Lennox]

On Thu, 2014-09-04 at 17:37 -0400, Adam Young wrote:
 While the Keystone team has made pretty good strides toward Federation 
 for getting a Keystone token, we do not yet have a complete story for 
 Horizon.  The same is true about Kerberos.  I've been working on this, 
 and I want to inform the people that are interested in the approach, as 
 well as get some feedback.
 
 My first priority has been Kerberos.  I have a proof of concept of this 
 working, but the amount of hacking I had to Django-OpenStack-Auth (DOA) 
 made me shudder:  its fairly ugly.  A few discussions today have moved 
 things such that I think I can clean up the approach.
 
 Phase 1.  DOA should be able to tell whether to use password or Kerberos 
 in order to get a token from Keystone based on an variable set by the 
 Apache web server;  mod_auth_kerb will set
 
  request.META['KRB5CCNAME']
 
 only in the kerberos case.  If it gets this variable, DOA will only do 
 Kerberos.  If it does not, it will only do password.  There will be no 
 fallback from Kerberos to password;  this is enforced by mod_auth_kerb, 
 not something we can easily hack around in Django.
 
 That gets us Kerberos, but not Federation. Most of the code changes are 
 common with what follows after:
 
 Phase 1.5.  Add an optional field  to the password auth page that allows 
 a user to log in with a token instead of userid/password. This can be a 
 hidden field by default if we really want.  DOA now needs to be able to 
 validate a token.  Since Horizon only cares about the hashed version of 
 the tokens anyway, we only to Online lookup, not PKI token validation.  
 In the successful response, Keystone will to return the properly hashed 
 (SHA256 for example) of the PKI tokens for Horizon to cache.
 
 Phase 2.  Use AJAX to get a token from Keystone instead of sending the 
 credentials to the client.  Then pass that token to Horizon in order to 
 login. This implies that Keystone has set up CORS support. This will 
 open the door for Federation.  While it will provide a different path to 
 Kerberos than the stage 1, I think both are valuable approaches and will 
 serve different use cases.  This
 
 Phase 3.  Never send your token to Horizon.  In this world, the browser, 
 with full CORS support, makes AJAX calls direct to Nova, Glance, and all 
 other services.
 
 Yep, this should be a cross project session for the summit.

So it was brought up briefly in Atlanta that keystone should provide a
way to discover the available auth mechanisms. This would mean to me for
example: 

1. a GET /auth/methods or just GET /auth which would include a list of
the methods for retrieving a token. (or just jsonhome entries)
2. a GET /OS-FEDERATION/idp that would list the available federated
IDPs. (or just jsonhome entries)

Horizon would then be able to do a similar thing to web services with
'login using your google id' or with user/pass and do some sensible
things based on what is allowed, or if it is receiving a kerberos ticket
and kerberos is one of the allowed methods then bypass all this stuff.

If we did this wouldn't most of 'use CORS/AJAX/kerberos/whatever' be on
a case by case basis? 

I don't know Horizon or the DOA very well at all so just let me know if
i've picked up on completely the wrong things here. 


Jamie

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




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

[openstack-dev] Horizon, Keystone, Kerberos, and Federation

[Adam Young]

I've been looking in to enabling  Kerberos for Horizon.  Since Horizon 
passes the Users credentials on to Keystone to get a token, Kerberos 
requires an additional delegation mechanism.  This leads to some 
questions about how to handle delegation in the case of Federated Identity.



In Kerberos, the Horizon Django App would get a 
strongREMOTE_USER/strong set by the Apache web server.  
strongREMOTE_USER/strong by itself is not enough to send to Keystone 
to get a token.


Kerberos has a Delegation mechanism called a 
href=http://vda.li/en/posts/2013/07/29/Setting-up-S4U2Proxy-with-FreeIPA/; 
title=Setting Up S4U2Proxy with FreeIPAService for User to Proxy 
(abbreviated as S4U2Proxy)/a which would allow (only) Horizon to get a 
service ticket to Keystone on behalf of the user. I am pretty certain we 
can make this work without too much effort.


The exposure of a hacked Horizon set up this way would be limited to 
those active service tickets in the webserver.  Since Kerberos tickets 
are typically 8 hours in duration, the hacker would have full access to 
Keystone and Keystone only for any use that had logged in in the past 8 
hours, or that logged in while the attack was running.  Essentially, it 
would be the same exposure as the current Horizon model would have; both 
ticket duration and token duration are configurable.


If Horizon under Kerberos falls back to a user-id/password mechanism, 
the Horizon server could fetch a much more powerful Ticket Granting 
Ticket (TGT) for the user and use that to get a service ticket.  The 
exposure for this is much greater;  a successful hacker could 
impersonate the user to emall/em services.  Unfortunately, business 
requirements often demand a fallback to UserID/Password for users with 
limited ability to administer their own machines. mod_auth_krb5 provides 
a means to use userid and password, and there are form based approaches, 
too.


For SAML we would need a comparable delegation mechanism.   If Horizon 
were authorized to access Keystone on the behalf of the user, and it 
provided the original SAML Assertion, we would have the same exposure as 
the S4U2Proxy case.  SAML assertion are time limited, so the Hacked 
Horizon instance would only be able to access Keystone, and only for the 
duration of the SAML assertions.


In both cases, the exposure would be better than today using 
User-Id/Password to get tokens from Horizon in the deployments when the 
tokens have a default  lifetime of 12 hours.  Whereas as sniffed 
password would be usable indefinitely, a stolen assertion or service 
ticket would only be usable for the life of the ticket or assertion, and 
on so long as the Horizon service itself is still compromised.


The Keystone default token duration has been shortened to one hour, and 
a corresponding Service ticket policy would make sense:  limit Kerberos 
Service tickets or SAML assertions to access Horizon to one hour.


I'm digging into X509 client certificates as well, but there does not 
seem to be as clear a story there.  I think the short of it is 
theoretically possible but may be impractical.




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

[openstack-dev] [horizon / keystone] Marker could not be found?

[Sebastian Porombka]

Hello Folks.

I have a problem after grizzly-havana migration where i’m unable to rescue 
myself.
When I open the Admin - Resource-Usage View i get no results – only a red 
error box with the message Error: Unable to retrieve tenant list.“.

Horizon log:

[Thu Oct 31 11:39:44 2013] [error] Creating a new keystoneclient connection to 
http://$controller:35357/v2.0.

[Thu Oct 31 11:39:44 2013] [error] REQ: curl -i -X GET 
http://$controller:35357/v2.0/tenants?marker=tenant_markerlimit=21 -H 
User-Agent: python-keystoneclient -H Forwarded: 
for=131.234.5.178;by=python-keystoneclient -H X-Auth-Token: 82[…]f46

[Thu Oct 31 11:39:44 2013] [error] REQ: curl -i -X GET 
http://$controller:35357/v2.0/tenants?marker=tenant_markerlimit=21 -H 
User-Agent: python-keystoneclient -H Forwarded: 
for=131.234.5.178;by=python-keystoneclient -H X-Auth-Token: 82[…]46

[Thu Oct 31 11:39:44 2013] [error] INFO:urllib3.connectionpool:Starting new 
HTTP connection (1): $controller

[Thu Oct 31 11:39:44 2013] [error] DEBUG:urllib3.connectionpool:GET 
/v2.0/tenants?marker=tenant_markerlimit=21 HTTP/1.1 400 88

[Thu Oct 31 11:39:44 2013] [error] RESP: [400] CaseInsensitiveDict({'date': 
'Thu, 31 Oct 2013 11:39:47 GMT', 'vary': 'X-Auth-Token', 'content-length': 
'88', 'content-type': 'application/json'})

[Thu Oct 31 11:39:44 2013] [error] RESP BODY: {error: {message: Marker 
could not be found, code: 400, title: Bad Request}}

[Thu Oct 31 11:39:44 2013] [error]

[Thu Oct 31 11:39:44 2013] [error] RESP: [400] CaseInsensitiveDict({'date': 
'Thu, 31 Oct 2013 11:39:47 GMT', 'vary': 'X-Auth-Token', 'content-length': 
'88', 'content-type': 'application/json'})

[Thu Oct 31 11:39:44 2013] [error] RESP BODY: {error: {message: Marker 
could not be found, code: 400, title: Bad Request}}

[Thu Oct 31 11:39:44 2013] [error]

[Thu Oct 31 11:39:44 2013] [error] Request returned failure status: 400

[Thu Oct 31 11:39:44 2013] [error] Request returned failure status: 400

[Thu Oct 31 11:39:44 2013] [error] Recoverable error: Marker could not be found 
(HTTP 400)

Keystone Log:
2013-10-31 12:39:47.352 17187 DEBUG routes.middleware [-] Matched GET /tenants 
__call__ /usr/lib/python2.7/dist-packages/routes/middleware.py:100

2013-10-31 12:39:47.352 17187 DEBUG routes.middleware [-] Route path: 
'{path_info:.*}', defaults: {'controller': 
keystone.contrib.ec2.routers.Ec2Extension object at 0x4156f10} __call__ 
/usr/lib/python2.7/dist-packages/routes/middleware.py:102

2013-10-31 12:39:47.352 17187 DEBUG routes.middleware [-] Match dict: 
{'controller': keystone.contrib.ec2.routers.Ec2Extension object at 0x4156f10, 
'path_info': '/tenants'} __call__ 
/usr/lib/python2.7/dist-packages/routes/middleware.py:103

2013-10-31 12:39:47.353 17187 DEBUG routes.middleware [-] Matched GET /tenants 
__call__ /usr/lib/python2.7/dist-packages/routes/middleware.py:100

2013-10-31 12:39:47.353 17187 DEBUG routes.middleware [-] Route path: 
'{path_info:.*}', defaults: {'controller': 
keystone.contrib.s3.core.S3Extension object at 0x4156cd0} __call__ 
/usr/lib/python2.7/dist-packages/routes/middleware.py:102

2013-10-31 12:39:47.353 17187 DEBUG routes.middleware [-] Match dict: 
{'controller': keystone.contrib.s3.core.S3Extension object at 0x4156cd0, 
'path_info': '/tenants'} __call__ 
/usr/lib/python2.7/dist-packages/routes/middleware.py:103

2013-10-31 12:39:47.354 17187 DEBUG routes.middleware [-] Matched GET /tenants 
__call__ /usr/lib/python2.7/dist-packages/routes/middleware.py:100

2013-10-31 12:39:47.354 17187 DEBUG routes.middleware [-] Route path: 
'{path_info:.*}', defaults: {'controller': 
keystone.contrib.admin_crud.core.CrudExtension object at 0x41517d0} __call__ 
/usr/lib/python2.7/dist-packages/routes/middleware.py:102

2013-10-31 12:39:47.355 17187 DEBUG routes.middleware [-] Match dict: 
{'controller': keystone.contrib.admin_crud.core.CrudExtension object at 
0x41517d0, 'path_info': '/tenants'} __call__ 
/usr/lib/python2.7/dist-packages/routes/middleware.py:103

2013-10-31 12:39:47.355 17187 DEBUG routes.middleware [-] Matched GET /tenants 
__call__ /usr/lib/python2.7/dist-packages/routes/middleware.py:100

2013-10-31 12:39:47.355 17187 DEBUG routes.middleware [-] Route path: 
'{path_info:.*}', defaults: {'controller': 
keystone.common.wsgi.ComposingRouter object at 0x4151e50} __call__ 
/usr/lib/python2.7/dist-packages/routes/middleware.py:102

2013-10-31 12:39:47.356 17187 DEBUG routes.middleware [-] Match dict: 
{'controller': keystone.common.wsgi.ComposingRouter object at 0x4151e50, 
'path_info': '/tenants'} __call__ 
/usr/lib/python2.7/dist-packages/routes/middleware.py:103

2013-10-31 12:39:47.356 17187 DEBUG routes.middleware [-] Matched GET /tenants 
__call__ /usr/lib/python2.7/dist-packages/routes/middleware.py:100

2013-10-31 12:39:47.357 17187 DEBUG routes.middleware [-] Route path: 
'/tenants', defaults: {'action': u'get_all_projects', 'controller': 
keystone.identity.controllers.Tenant object at 0x4151ed0} __call__ 

Re: [openstack-dev] [horizon / keystone] Marker could not be found?

[Dolph Mathews]

On Thu, Oct 31, 2013 at 8:38 AM, Sebastian Porombka 
porom...@uni-paderborn.de wrote:

  Hello Folks.

  I have a problem after grizzly-havana migration where i’m unable to
 rescue myself.
 When I open the Admin - Resource-Usage View i get no results – only a
 red error box with the message *Error: *Unable to retrieve tenant list.“.

  Horizon log:

 [Thu Oct 31 11:39:44 2013] [error] Creating a new keystoneclient
 connection to http://$controller:35357/v2.0.

 [Thu Oct 31 11:39:44 2013] [error] REQ: curl -i -X GET 
 http://$controller:35357/v2.0/tenants?marker=tenant_markerlimit=21
 -H User-Agent: python-keystoneclient -H Forwarded:
 for=131.234.5.178;by=python-keystoneclient -H X-Auth-Token: 82[…]f46

 [Thu Oct 31 11:39:44 2013] [error] REQ: curl -i -X GET 
 http://$controller:35357/v2.0/tenants?marker=tenant_markerlimit=21
 -H User-Agent: python-keystoneclient -H Forwarded:
 for=131.234.5.178;by=python-keystoneclient -H X-Auth-Token: 82[…]46

 [Thu Oct 31 11:39:44 2013] [error] INFO:urllib3.connectionpool:Starting
 new HTTP connection (1): $controller

 [Thu Oct 31 11:39:44 2013] [error] DEBUG:urllib3.connectionpool:GET
 /v2.0/tenants?marker=tenant_markerlimit=21 HTTP/1.1 400 88

 [Thu Oct 31 11:39:44 2013] [error] RESP: [400]
 CaseInsensitiveDict({'date': 'Thu, 31 Oct 2013 11:39:47 GMT', 'vary':
 'X-Auth-Token', 'content-length': '88', 'content-type': 'application/json'})

 [Thu Oct 31 11:39:44 2013] [error] RESP BODY: {error: {message:
 Marker could not be found, code: 400, title: Bad Request}}

 [Thu Oct 31 11:39:44 2013] [error]

 [Thu Oct 31 11:39:44 2013] [error] RESP: [400]
 CaseInsensitiveDict({'date': 'Thu, 31 Oct 2013 11:39:47 GMT', 'vary':
 'X-Auth-Token', 'content-length': '88', 'content-type': 'application/json'})

 [Thu Oct 31 11:39:44 2013] [error] RESP BODY: {error: {message:
 Marker could not be found, code: 400, title: Bad Request}}

 [Thu Oct 31 11:39:44 2013] [error]

 [Thu Oct 31 11:39:44 2013] [error] Request returned failure status: 400

 [Thu Oct 31 11:39:44 2013] [error] Request returned failure status: 400

 [Thu Oct 31 11:39:44 2013] [error] Recoverable error: Marker could not be
 found (HTTP 400)

  Keystone Log:
 2013-10-31 12:39:47.352 17187 DEBUG routes.middleware [-] Matched GET
 /tenants __call__ /usr/lib/python2.7/dist-packages/routes/middleware.py:100

 2013-10-31 12:39:47.352 17187 DEBUG routes.middleware [-] Route path:
 '{path_info:.*}', defaults: {'controller':
 keystone.contrib.ec2.routers.Ec2Extension object at 0x4156f10} __call__
 /usr/lib/python2.7/dist-packages/routes/middleware.py:102

 2013-10-31 12:39:47.352 17187 DEBUG routes.middleware [-] Match dict:
 {'controller': keystone.contrib.ec2.routers.Ec2Extension object at
 0x4156f10, 'path_info': '/tenants'} __call__
 /usr/lib/python2.7/dist-packages/routes/middleware.py:103

 2013-10-31 12:39:47.353 17187 DEBUG routes.middleware [-] Matched GET
 /tenants __call__ /usr/lib/python2.7/dist-packages/routes/middleware.py:100

 2013-10-31 12:39:47.353 17187 DEBUG routes.middleware [-] Route path:
 '{path_info:.*}', defaults: {'controller':
 keystone.contrib.s3.core.S3Extension object at 0x4156cd0} __call__
 /usr/lib/python2.7/dist-packages/routes/middleware.py:102

 2013-10-31 12:39:47.353 17187 DEBUG routes.middleware [-] Match dict:
 {'controller': keystone.contrib.s3.core.S3Extension object at 0x4156cd0,
 'path_info': '/tenants'} __call__
 /usr/lib/python2.7/dist-packages/routes/middleware.py:103

 2013-10-31 12:39:47.354 17187 DEBUG routes.middleware [-] Matched GET
 /tenants __call__ /usr/lib/python2.7/dist-packages/routes/middleware.py:100

 2013-10-31 12:39:47.354 17187 DEBUG routes.middleware [-] Route path:
 '{path_info:.*}', defaults: {'controller':
 keystone.contrib.admin_crud.core.CrudExtension object at 0x41517d0}
 __call__ /usr/lib/python2.7/dist-packages/routes/middleware.py:102

 2013-10-31 12:39:47.355 17187 DEBUG routes.middleware [-] Match dict:
 {'controller': keystone.contrib.admin_crud.core.CrudExtension object at
 0x41517d0, 'path_info': '/tenants'} __call__
 /usr/lib/python2.7/dist-packages/routes/middleware.py:103

 2013-10-31 12:39:47.355 17187 DEBUG routes.middleware [-] Matched GET
 /tenants __call__ /usr/lib/python2.7/dist-packages/routes/middleware.py:100

 2013-10-31 12:39:47.355 17187 DEBUG routes.middleware [-] Route path:
 '{path_info:.*}', defaults: {'controller':
 keystone.common.wsgi.ComposingRouter object at 0x4151e50} __call__
 /usr/lib/python2.7/dist-packages/routes/middleware.py:102

 2013-10-31 12:39:47.356 17187 DEBUG routes.middleware [-] Match dict:
 {'controller': keystone.common.wsgi.ComposingRouter object at 0x4151e50,
 'path_info': '/tenants'} __call__
 /usr/lib/python2.7/dist-packages/routes/middleware.py:103

 2013-10-31 12:39:47.356 17187 DEBUG routes.middleware [-] Matched GET
 /tenants __call__ /usr/lib/python2.7/dist-packages/routes/middleware.py:100

 2013-10-31 12:39:47.357 17187 DEBUG routes.middleware [-] Route path:
 '/tenants', defaults: {'action':