+1! Brad Topol, Ph.D. IBM Distinguished Engineer OpenStack (919) 543-0646 Internet: bto...@us.ibm.com Assistant: Kendra Witherspoon (919) 254-0680
From: Adam Young <ayo...@redhat.com> To: openstack-dev@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: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). >> 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.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. >> 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@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
