Hi David and Kristy, looking at the slides it is not clear to me why you need to have an authn plugin for each Apache plugin. I have experience only with few Apache plugins and they provide the possibility to customise the attributes for the application behind. As an example, with mod_shib it is possible to define how the information coming from the IdP should be provided to the application. Maybe this is not possible with all plugins but I am wondering if it is possible the other way around. In other words, to create only a configurable authn plugin for all apache plugin. In the configuration you should provide the name of the attributes to look at and the mapping with the Keystone attributes.
BTW: design 2 seems better although requires more work. Cheers, Marco On Wed, May 28, 2014 at 04:59:48PM +0100, David Chadwick wrote: > Hi Everyone > > at the Atlanta meeting the following slides were presented during the > federation session > > http://www.slideshare.net/davidwchadwick/keystone-apach-authn > > It was acknowledged that the current design is sub-optimal, but was a > best first efforts to get something working in time for the IceHouse > release, which it did successfully. > > Now is the time to redesign federated access in Keystone in order to > allow for: > i) the inclusion of more federation protocols such as OpenID and OpenID > Connect via Apache plugins > ii) federating together multiple Keystone installations > iii) the inclusion of federation protocols directly into Keystone where > good Apache plugins dont yet exist e.g. IETF ABFAB > > The Proposed Design (1) in the slide show is the simplest change to > make, in which the Authn module has different plugins for different > federation protocols, whether via Apache or not. > > The Proposed Design (2) is cleaner since the plugins are directly into > Keystone and not via the Authn module, but it requires more > re-engineering work, and it was questioned in Atlanta whether that > effort exists or not. > > Kent therefore proposes that we go with Proposed Design (1). Kent will > provide drafts of the revised APIs and the re-engineered code for > inspection and approval by the group, if the group agrees to go with > this revised design. > > If you have any questions about the proposed re-design, please don't > hesitate to ask > > regards > > David and Kristy > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- ==================================================== Eng. Marco Fargetta, PhD Istituto Nazionale di Fisica Nucleare (INFN) Catania, Italy EMail: marco.farge...@ct.infn.it ====================================================
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev