Open Stack

+1!

Brad Topol, Ph.D.
IBM Distinguished Engineer
OpenStack
(919) 543-0646
Internet:  btopol at us.ibm.com
Assistant: Kendra Witherspoon (919) 254-0680



From:   Adam Young <ayoung at redhat.com>
To:     openstack-dev at lists.openstack.org
Date:   10/30/2013 11:13 AM
Subject:        Re: [openstack-dev] [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 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.
Sorry, that comment was meant explicitly for the OpenID, SAML piece of 
it...but having said that:

I see Federation as being the priamry reason that Keystone exists. It is 
rare that a dedicated user ID database will belong to the Cloud 
deployment.  In the Enterprise, we cannot even count on a single 
Directory (Mergers and acquisitions make  this unlikely) and in the 
public we need to be able to link users from remote IdPs. Federation is 
a lousyt term, in that it implies that this stuff is special.  It is 
not.  This stuff is Authorization at its core. Federation is just the 
name for smacking us out of the nearsightedness that has driven 
application development.

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

Oh, no, not at all...Authenticaion is not authorization. Authorization 
is based on authentication plus.  It is that plus that is important.

Yes, it may still be an LDAP call after the user logs in with the X509, 
we are not going to break that.  But even in a non-federate case, it is 
likely that Authoriuzation attributes will be coming from the Web front 
end.



>
> Maybe we should rename "external authentication" to "HTTPD
> authentication"?
Nope.  Apache HTTPD is one potential front to a WSGI app, but not the 
only one.  NOthing we are doing here is Apache specific, if we can help 
it.  Ngnix and many other web front ends are out there.  I just want to 
use Apache HTTPD as the common, understood sample Front end that 
provides a well documented set of strong security protocols.  Lets 
continue to call it external, as that term was chosen after discussing 
this very topic.

>
> Regards,


_______________________________________________
OpenStack-dev mailing list
OpenStack-dev at lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131030/c90bf092/attachment.html>