+1 (except possibly for the environmental variables portion, which could and perhaps should be handled through provisioning).
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. > > regards > > David > > On 29/10/2013 12:59, Álvaro López García wrote: >> Hi there, >> >> I've been working on this bug [1,2] related with the pluggable external >> authentication support in Havana. For those not familiar with it, >> Keystone can rely on the usage of the REMOTE_USER env variable, assuming >> that the user has been authenticated upstream (by an httpd server). This >> REMOTE_USER variable is supposed to store the username information that >> Keystone is going to use. >> >> In the Havana external authentication plugins, the REMOTE_USER variable >> is *always* split by the "@" character, assuming that the @ is being >> used as the domain separator (i.e. REMOTE_USER=username@domain). >> >> Now there are two plugins available: >> >> - ExternalDefault: Only the leftmost part of the REMOTE_USER after the >> split is considered. The domain information is obtainted from the >> default domain configured in keystone.conf. >> >> - ExternalDomain: The rightmost part is considered the domain, and the >> leftover is considered the username. >> >> The change in [2] aims to solve this problem: ExternalDefault will not >> split the username by an "@" since we are going to use the default >> domain so we assume that no domain will be appended. >> >> However, this will work only if we are using a WSGI filter that is aware >> of the semantics: the filter should know if ExternalDefault is used so >> that the domain information is not appended, but append it if >> ExternalDomain is used. Moreover, if somebody is using directly the >> REMOTE_USER variable from Apache without any WSGI filter (for example >> using X509 auth with mod_ssl and the SSLUsername directive [3]) the >> REMOTE_USER will contain only the username and no domain at all. >> >> Does anybody have any concerns about this? Should we pass down the >> domain information by any other mean? >> >> [1] https://bugs.launchpad.net/keystone/+bug/1211233 >> [2] https://review.openstack.org/#/c/50362/ >> [3] http://httpd.apache.org/docs/2.2/mod/mod_ssl.html#sslusername >> > > _______________________________________________ > 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
