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