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 m...@enovance.com ----- Original Message ----- > From: "David Chadwick" <d.w.chadw...@kent.ac.uk> > To: "OpenStack Development Mailing List" <openstack-dev@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@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
