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

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:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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-dev] [Horizon] [Keystone] cross-project meeting Thursday 1st December 2000UTC

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-dev] [Horizon][Keystone] No Horizon/Keystone cross-project meeting this week

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] [Horizon] [Keystone] Inaugural weekly cross-project meeting summary

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

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

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

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

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 fro

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:

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

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

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

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 Mo

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 > wrote: > Hi, > > we're deploying Liberty (soon Mitaka) with heavy reliance on > the SAML2 > Federation system by

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

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

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

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

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

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

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

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 >

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

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

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

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:

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

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

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

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

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

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

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

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

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

atever 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

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

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

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

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

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

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][keyston

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

ck <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, Anto

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

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

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

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

[openstack-dev] [horizon][keystone]

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

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

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

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

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

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

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

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

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

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

+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

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.

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

+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

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

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

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

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

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

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

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

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

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

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

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?

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

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é

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

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

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

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

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

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 -

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

; 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

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

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

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

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

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

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

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

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

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

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

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,

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

*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

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

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

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

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

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

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

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

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

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

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

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

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

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

(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

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

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 Th

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

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

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

/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

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

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

[openstack-dev] [horizon][keystone]

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

Re: [openstack-dev] [Horizon][Keystone] Steps toward Kerberos and Federation

Hi, I am wondering if the solution I was trying to sketch with the spec https://review.openstack.org/#/c/96867/13; is not easier to implement and manage then the steps highlated till n.2. Maybe, the spec is not yet there and should be improved (I will abandon or move to Kilo as Marek suggest) but

Re: [openstack-dev] [Horizon][Keystone] Steps toward Kerberos and Federation

On 09/05/2014 04:49 AM, Marco Fargetta wrote: Hi, I am wondering if the solution I was trying to sketch with the spec https://review.openstack.org/#/c/96867/13; is not easier to implement and manage then the steps highlated till n.2. Maybe, the spec is not yet there and should be improved (I

Re: [openstack-dev] [Horizon][Keystone] Steps toward Kerberos and Federation

On 09/05/2014 11:28 AM, Marco Fargetta wrote: I understand the general idea and the motivations but I am not sure about the implementation. Even with a SPA you still need to provide credentials and manage tokens for the authentication/authorisation in a way not too much different from the

[openstack-dev] [Horizon][Keystone] Steps toward Kerberos and Federation

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

Re: [openstack-dev] [Horizon][Keystone] Steps toward Kerberos and Federation

On Thu, 2014-09-04 at 17:37 -0400, Adam Young wrote: While the Keystone team has made pretty good strides toward Federation for getting a Keystone token, we do not yet have a complete story for Horizon. The same is true about Kerberos. I've been working on this, and I want to inform the

[openstack-dev] Horizon, Keystone, Kerberos, and Federation

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

[openstack-dev] [horizon / keystone] Marker could not be found?

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]

Re: [openstack-dev] [horizon / keystone] Marker could not be found?

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