Open Stack

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

Yes, indeed (and providing a set of common auth plugins like X509,
basic, etc).

> 
> >
> >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).
> 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.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.
> Love this idea.  We can discuss in the Federation session.

I completely agree, but you are focusing on federation. 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 X509 certificates and they want to 
use that for authentication instead of username/password. In this case
there would be no authz, no mapping, etc., just authn.

Maybe we should rename "external authentication" to "HTTPD
authentication"?

Regards,
-- 
Álvaro López García                              aloga at ifca.unican.es
Instituto de Física de Cantabria         http://alvarolopez.github.io
Ed. Juan Jordá, Campus UC                      tel: (+34) 942 200 969
Avda. de los Castros s/n
39005 Santander (SPAIN)
_____________________________________________________________________
http://xkcd.com/571/