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: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.
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,
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
