Open Stack

Hello,

For what it is worth I was toying around with the possibility to extend the federation mapping mechanism to be used with keystone's external auth plugin. I believe this would allow easy, immediate and generic support of other federation protocols through apache mods without the need to write specific auth plugins unless it is needed.
I've pushed a very early PoC on this and given some basic guidelines to make it work with OpenID here: 

* PoC: https://review.openstack.org/#/c/92079/
* Blueprint: https://blueprints.launchpad.net/keystone/+spec/external-auth-federation-mapping

I'd be happy to get some feedback and push work forward on it if it can be of any use to the project. Let me know what you think !

Regards

Matthieu Huin 

mhu at enovance.com

----- Original Message -----
> From: "David Chadwick" <d.w.chadwick at kent.ac.uk>
> To: "OpenStack Development Mailing List" <openstack-dev at lists.openstack.org>
> Sent: Wednesday, May 28, 2014 5:59:48 PM
> Subject: [openstack-dev]  [keystone] Redesign of Keystone Federation
> 
> 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
>