On 10/29/2013 12:18 PM, 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.
There is a OS client talk on Wednesday that you should atend. Getting
the Auth options striaght in a common client will be a huge benefit.
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 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.
This means that Apache modules can potentially pas on more than just the
username or comparable authentication value.
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 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 Keystone that handles the incoming request, regardless of
whether it has only the remote user env variable, or has
this plus a number of authz attribute env variables as well. I should like this
module to end by returning the identity of the remote user in
a standard internal keystone format (i.e. as a set of identity attributes),
which can then be passed to the next phase of processing (which
will include attribute mapping). In this way, we can have a common processing
pipeline for incoming requests, regardless of how the end
user was authenticated, ie. whether the request contains SAML assertions, env
variables, OpenID assertions etc. Different endpoints could
be used for the different incoming protocols, or a common endpoint could be
used, with JSON parameters containing the different
protocol information.
Love this idea. We can discuss in the Federation session.
regards
David
On 29/10/2013 12:59, Álvaro López García wrote:
Hi there,
I've been working on this bug [1,2] related with the pluggable
external authentication support in Havana. For those not familiar
with it, Keystone can rely on the usage of the REMOTE_USER env
variable, assuming that the user has been authenticated upstream (by
an httpd server). This REMOTE_USER variable is supposed to store the
username information that Keystone is going to use.
In the Havana external authentication plugins, the REMOTE_USER
variable is *always* split by the "@" character, assuming that the @
is being used as the domain separator (i.e. REMOTE_USER=username@domain).
Now there are two plugins available:
- ExternalDefault: Only the leftmost part of the REMOTE_USER after the
split is considered. The domain information is obtainted from the
default domain configured in keystone.conf.
- ExternalDomain: The rightmost part is considered the domain, and the
leftover is considered the username.
The change in [2] aims to solve this problem: ExternalDefault will
not split the username by an "@" since we are going to use the
default domain so we assume that no domain will be appended.
However, this will work only if we are using a WSGI filter that is
aware of the semantics: the filter should know if ExternalDefault is
used so that the domain information is not appended, but append it if
ExternalDomain is used. Moreover, if somebody is using directly the
REMOTE_USER variable from Apache without any WSGI filter (for example
using X509 auth with mod_ssl and the SSLUsername directive [3]) the
REMOTE_USER will contain only the username and no domain at all.
Does anybody have any concerns about this? Should we pass down the
domain information by any other mean?
[1] https://bugs.launchpad.net/keystone/+bug/1211233
[2] https://review.openstack.org/#/c/50362/
[3] http://httpd.apache.org/docs/2.2/mod/mod_ssl.html#sslusername
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
