Open Stack

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 at 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.Fargetta at ct.infn.it
====================================================

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5483 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140528/9755790d/attachment.bin>