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
