<font size=2 face="sans-serif">+1!</font>
<br><font size=2 face="sans-serif"><br>
Brad Topol, Ph.D.<br>
IBM Distinguished Engineer<br>
OpenStack<br>
(919) 543-0646<br>
Internet:  btopol@us.ibm.com<br>
Assistant: Kendra Witherspoon (919) 254-0680</font>
<br>
<br>
<br>
<br><font size=1 color=#5f5f5f face="sans-serif">From:      
 </font><font size=1 face="sans-serif">Adam Young <ayoung@redhat.com></font>
<br><font size=1 color=#5f5f5f face="sans-serif">To:      
 </font><font size=1 face="sans-serif">openstack-dev@lists.openstack.org</font>
<br><font size=1 color=#5f5f5f face="sans-serif">Date:      
 </font><font size=1 face="sans-serif">10/30/2013 11:13 AM</font>
<br><font size=1 color=#5f5f5f face="sans-serif">Subject:    
   </font><font size=1 face="sans-serif">Re: [openstack-dev]
[keystone] Support for external authentication (i.e. REMOTE_USER) in Havana</font>
<br>
<hr noshade>
<br>
<br>
<br><tt><font size=2>On 10/30/2013 05:38 AM, Álvaro López García wrote:<br>
> On Tue 29 Oct 2013 (17:04), Adam Young wrote:<br>
>> On 10/29/2013 12:18 PM, Tim Bell wrote:<br>
>>> 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.<br>
>> There is a OS client talk on Wednesday that you should atend.<br>
>> Getting the Auth options striaght in a common client will be a
huge<br>
>> benefit.<br>
> Yes, indeed (and providing a set of common auth plugins like X509,<br>
> basic, etc).<br>
><br>
>>> Tim<br>
>>><br>
>>>> -----Original Message-----<br>
>>>> From: Alan Sill [</font></tt><a href=mailto:kilohoku150@gmail.com><tt><font size=2>mailto:kilohoku150@gmail.com</font></tt></a><tt><font size=2>]<br>
>>>> Sent: 29 October 2013 16:36<br>
>>>> To: OpenStack Development Mailing List (not for usage
questions)<br>
>>>> Subject: Re: [openstack-dev] [keystone] Support for external
authentication (i.e. REMOTE_USER) in Havana<br>
>>>><br>
>>>> +1<br>
>>>><br>
>>>> (except possibly for the environmental variables portion,
which could and perhaps should be handled through provisioning).<br>
>> THis is the Apache ENV dictionary,  not system environemnte<br>
>> variables.  This means that Apache modules can potentially
pas on<br>
>> more than just the username or comparable authentication value.<br>
>><br>
>><br>
>>>> On Oct 29, 2013, at 8:35 AM, David Chadwick <d.w.chadwick@kent.ac.uk>
wrote:<br>
>>>><br>
>>>>> 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<br>
>>>> working on adding additional authz attributes as env variables
so that these can be used for authorising the user in keystone. It should
be<br>
>>>> the same module in Keystone that handles the incoming
request, regardless of whether it has only the remote user env variable,
or has<br>
>>>> 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<br>
>>>> 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<br>
>>>> will include attribute mapping). In this way, we can have
a common processing pipeline for incoming requests, regardless of how the
end<br>
>>>> user was authenticated, ie. whether the request contains
SAML assertions, env variables, OpenID assertions etc. Different endpoints
could<br>
>>>> be used for the different incoming protocols, or a common
endpoint could be used, with JSON parameters containing the different<br>
>>>> protocol information.<br>
>> Love this idea.  We can discuss in the Federation session.<br>
> I completely agree, but you are focusing on federation.<br>
Sorry, that comment was meant explicitly for the OpenID, SAML piece of
<br>
it...but having said that:<br>
<br>
I see Federation as being the priamry reason that Keystone exists. It is
<br>
rare that a dedicated user ID database will belong to the Cloud <br>
deployment.  In the Enterprise, we cannot even count on a single <br>
Directory (Mergers and acquisitions make  this unlikely) and in the
<br>
public we need to be able to link users from remote IdPs. Federation is
 <br>
a lousyt term, in that it implies that this stuff is special.  It
is <br>
not.  This stuff is Authorization at its core. Federation is just
the <br>
name for smacking us out of the nearsightedness that has driven <br>
application development.<br>
<br>
> Please take<br>
> into account that external authentication and the REMOTE_USER stuff<br>
> can be used without any federation at all. For example if an org<br>
> is providing their users with X509 certificates and they want to<br>
> use that for authentication instead of username/password. In this
case<br>
> there would be no authz, no mapping, etc., just authn.<br>
<br>
Oh, no, not at all...Authenticaion is not authorization. Authorization
<br>
is based on authentication plus.  It is that plus that is important.<br>
<br>
Yes, it may still be an LDAP call after the user logs in with the X509,
<br>
we are not going to break that.  But even in a non-federate case,
it is <br>
likely that Authoriuzation attributes will be coming from the Web front
end.<br>
<br>
<br>
<br>
><br>
> Maybe we should rename "external authentication" to "HTTPD<br>
> authentication"?<br>
Nope.  Apache HTTPD is one potential front to a WSGI app, but not
the <br>
only one.  NOthing we are doing here is Apache specific, if we can
help <br>
it.  Ngnix and many other web front ends are out there.  I just
want to <br>
use Apache HTTPD as the common, understood sample Front end that <br>
provides a well documented set of strong security protocols.  Lets
<br>
continue to call it external, as that term was chosen after discussing
<br>
this very topic.<br>
<br>
><br>
> Regards,<br>
<br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
OpenStack-dev@lists.openstack.org<br>
</font></tt><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"><tt><font size=2>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</font></tt></a><tt><font size=2><br>
<br>
</font></tt>
<br>