Please note: This schedule is for OpenStack Active Technical Contributors participating in the Icehouse Design Summit sessions in Hong Kong. These are working sessions to determine the roadmap of the Icehouse release and make decisions across the project. To see the full OpenStack Summit schedule, including presentations, panels and workshops, go to http://openstacksummitnovember2013.sched.org.
python-keystoneclient has been holding off taking nova's auth_plugin mechanism for a while now and it's not because we believe it to be a bad idea. Instead we want to go further.
The concept has been discussed under the term APIClient but involve separating the communication, authentication and API call areas of concern and having common communication mechanisms amongst all the OpenStack clients.
The communication object should be responsible for: - CA and User x509 Certificates - Kerberos - User Agents and common headers
Authentication objects (pluggable) should utilise and be attached to the communication object and provide abstraction for: - Username and Password authentication - Token endpoint auth - All the new mechanisms that are upcoming and/or third party. In this way requests made via the communication object (whether they come from a client or not) are authenticated and secure.
The Client object then is left to manage the API calls to it's own services. - Users, projects, domains etc
Once we have this reusable communication object this is something that can/should be reused by all the different clients, however it needs to originate from keystoneclient as the authentication hub.
See this blog post for more: http://www.jamielennox.net/blog/2013/09/27/apiclient-communications/
