Open Stack

Hi Alvaro

On 30/10/2013 09:38, Á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.

No, I am focussing on authz after authn

Please take
> into account that external authentication and the REMOTE_USER stuff
> can be used without any federation at all.

I completely agree. But it also needs authz.

  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.

Not so. All users need to be authorised via their Keystone attributes of 
domains, projects and roles etc (unless user ID is being used as in Swift).

So after authn you have to get these keystone authz attributes from 
somewhere. It could be a backend LDAP, or from attributes inside an 
X.509 cert, or in the case of federation from the IDP. What I am 
suggesting is a unifying mechanism for turning these user identity 
attributes, obtained during authn, into Keystone authz attributes, via a 
common attribute mapping capability.

When LDAP groups were being discussed, I suggested that this could be 
implemented using attribute mappings without any recourse to adding a 
new set of schema and code for groups in backend LDAPs. But folks werent 
ready to add attribute mappings at that time. Perhaps now they are

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

I dont mind what you call it. I would like to see all authz processes 
after any authn process follow a common pipeline

regards

David

>
> Regards,
>