Open Stack

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.

Tim

> -----Original Message-----
> From: Alan Sill [mailto:kilohoku150 at 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).
> 
> On Oct 29, 2013, at 8:35 AM, David Chadwick <d.w.chadwick at 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.
> >
> > 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 at 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 at lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev