Thank you Nathan,
Do you have more details on what your mapping is configured like? There
have been some changes around this area in Juno, but it's still possible
that there is some sort of bug here.
Here are my mapping details:
# Search base for users. (string value)
On 10/18/2014 08:43 AM, lohit.valleru wrote:
Hello,
Thank you for posting this issue to openstack-dev. I had posted this on the
openstack general user list and was waiting for response.
May i know, if we have any progress regarding this issue.
I am trying to use external HTTPD
Hi Tim.
On Tue 29 Oct 2013 (16:18), Tim Bell wrote:
We also need some standardisation on the command line options for the client
portion (such as --os-auth-method, --os-x509-cert etc.) . Unfortunately, this
is not yet in Oslo so there would be multiple packages to be enhanced.
I totally
[mailto:kilohoku...@gmail.com]
Sent: 29 October 2013 16:36
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [keystone] Support for external authentication
(i.e. REMOTE_USER) in Havana
+1
(except possibly for the environmental variables portion
).
Tim
-Original Message-
From: Alan Sill [mailto:kilohoku...@gmail.com]
Sent: 29 October 2013 16:36
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [keystone] Support for external authentication
(i.e. REMOTE_USER) in Havana
+1
(except
-Original Message-
From: Alan Sill [mailto:kilohoku...@gmail.com]
Sent: 29 October 2013 16:36
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [keystone] Support for external authentication
(i.e. REMOTE_USER) in Havana
+1
(except possibly
] [keystone] Support for external
authentication (i.e. REMOTE_USER) in Havana
On 10/30/2013 05:38 AM, Álvaro López García wrote:
On Tue 29 Oct 2013 (17:04), Adam Young wrote:
On 10/29/2013 12:18 PM, Tim Bell wrote:
We also need some standardisation on the command line options for the
client
Hi Adam.
On Wed 30 Oct 2013 (11:08), Adam Young wrote:
On 10/30/2013 05:38 AM, Álvaro López García wrote:
(...)
Please take
into account that external authentication and the REMOTE_USER stuff
can be used without any federation at all. For example if an org
is providing their users with
On Wed, 2013-10-30 at 10:27 +0100, Álvaro López García wrote:
Hi Tim.
On Tue 29 Oct 2013 (16:18), Tim Bell wrote:
We also need some standardisation on the command line options for the
client portion (such as --os-auth-method, --os-x509-cert etc.) .
Unfortunately, this is not yet in
Whilst on this topic, perhaps we should also expand it to discuss
support for external authz as well. I know that Adam at Red Hat is
working on adding additional authz attributes as env variables so that
these can be used for authorising the user in keystone. It should be the
same module in
+1
(except possibly for the environmental variables portion, which could and
perhaps should be handled through provisioning).
On Oct 29, 2013, at 8:35 AM, David Chadwick d.w.chadw...@kent.ac.uk wrote:
Whilst on this topic, perhaps we should also expand it to discuss support for
external
Has the case been considered where REMOTE_USER is used with authentication
mechanisms where the username is an email address? It will have to keep the
@domain part because that's the only thing that makes it unique.
Thanks,
Kevin
From: Álvaro López
...@gmail.com]
Sent: 29 October 2013 16:36
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [keystone] Support for external authentication
(i.e. REMOTE_USER) in Havana
+1
(except possibly for the environmental variables portion, which could
What is the semantic of domain in the current implementation? Until we
know this we cant devise a solution.
Will the developed solution cater for me logging in via Google using my
kent email address (as opposed to my gmail one)? In this case there
could be 2 domains (depending upon the
: Re: [openstack-dev] [keystone] Support for external authentication
(i.e. REMOTE_USER) in Havana
+1
(except possibly for the environmental variables portion, which could and
perhaps should be handled through provisioning).
THis is the Apache ENV dictionary, not system environemnte variables
15 matches
Mail list logo
