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.
This topic will cover two topics related to Code Management within Keystone. The first is API Deprecation (Internal API Stabilization as well as V2 and future deprecation paths). The second will be Extension mechanisms [use of stevedore, paste, and alembic].
API Stabilization and Deprecation: Keystone has seen a large amount of shift in the internal APIs over the course of Havana. From that standpoint, it is important to be able to elegantly deprecate these internal APIs in a controlled manner to better support developers and consumers that implement custom code that hooks into keystone (be it a driver, a plugin, or something totally different). The scope of the deprecation should probably be for a single release (e.g. if the interface was deprecated/moved/changed/etc during the Havana cycle, in Icehouse the "deprecated" warning or stub-compat function would be removed). This session should also touch on the public facing APIs and the deprecation mechanism/choices (see the linked blueprint).
ML topic can be seen here: http://lists.openstack.org/pipermail/openstack-dev/2013-October/016704.html
Extension Mechanisms: The second part of this session will cover the use of the various tools to pull together Keystone and it's extensions. This will cover the use of stevedore, alembic, paste, etc. This is to make sure we are on the same page for handling extension detection both integrated and out-of-tree development. We will also address what is to become core versus strictly extensions (and how this is determined) and how we determine if an extension should become more than an extension.
The current Identity API and implementation of role assignments is a mess. I'd like to discuss:
1) A more logical API by extending the GET /role-assignment API into a full set of crud operations with "role-assignment" becoming a first class entity. We would deprecate (but still support for a while the existing GET /user/role/project...style)
2) Implementation of a single assignments table/structure in the backend
3) Removal of cross-identity-manager calls from the assignments manager/driver - i.e. assignment is just a mapper...and shouldn't know how to validate the objects it is mapping between (this will be required for federation). However, is there a security risk for that?
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/
A more generalized how to fix keystoneclient and what needs to be done.
Possible topics: - Version and Extension discovery - what are the performance implications of this? How does client deal with optional server components? Given the v2 and v3 client interfaces are completely different how would this be realistically used? - auth_token middleware uses httplib directly rather than consuming the rest of keystoneclient - Caching - what makes sense and how do we do it in a client lib?
However i'm willing to turn this into a discussion of whatever gets people more interested in the client.
It seems there are some blueprints, and corresponding wikis that try and flesh out a design for federated identity support in keystone. Currently neither exist in OpenStack.
Let's go through the use cases, the two different approaches that have been proposed (Joe Savak @ Rackspace and David Chadwick @ University of Kent), and the primary concepts and technologies (IDPs, mapping and SAML, authentication).
1) Use Cases can be found here: https://etherpad.openstack.org/p/federation-flows
2) Concepts: a) IDPs b) Federation mechanism: SAML, ABFAB, OAuth c) Attribute mapping d) Authentication requests
3) The two different approaches: Joe Savak @ Rackspace bp: https://blueprints.launchpad.net/keystone/+spec/virtual-idp wiki: https://wiki.openstack.org/wiki/Keystone_Virtual_Identity_Providers api-spec: https://review.openstack.org/#/c/51980/
David Chadwick @ University of Kent bp: https://blueprints.launchpad.net/keystone/+spec/federation wiki: https://wiki.openstack.org/wiki/Keystone/Federation/Blueprint api-spec: https://review.openstack.org/#/c/39499/
The goal for this session is to decide on one approach for keystone to pursue supporting during Icehouse.
Discussion here: https://etherpad.openstack.org/keystone-federation and here: https://etherpad.openstack.org/p/federation-flows
A token may not be expired yet, but the authorization it presents may no longer be valid.
As a result, keystoneclient.middleware.auth_token constantly needs to ask "Is this token valid?" We've taken a couple different approaches to answering this question in the past, including:
- UUID tokens + online token validation - PKI tokens + periodically fetching a list of revoked tokens
Both existing solutions require keystone to track issued tokens so that it can later know which to consider as "revoked," and both solutions result in an undesirable amount of network traffic and activity against the token backend.
I'd like to select and pursue a better approach (if any) to avoid the pitfalls described above. Proposed solutions include:
In the havana release, we added OAuth 1.0a support to keystone; I received a lot of suggestions to enhance this feature. The point of this session is to vet those suggestions and gauge participant interest.
Another goal of the session is a two-parter, 1) Quickly establish the differences between oauth and trusts for the crowd. And 2) See if there are any other delegation models, or a way to wrap oauth and trusts, so they are not completely different code paths.
Future OAuth work suggestions: - Changing the token secret to be a hash of information, rather than just uuid. Dolphm already has a prototype working. The point of this is that it could be used offline. - Adding a web UI, pretty self-explanatory, this would make using the oauth delegation mechanism much easier. Would this go directly into horizon? Or can this exist in keystone? - Using policy config files to assert delegation. ayoung suggested that if we let Keystone parse the policy config files it is handed. Keystone would then be able to deduce what a give token would be allowed to do. THen, instead of delegating a whole a role, a user could delegate the ability to execute individual api functions. Then, a token could say: only let the bearer execute function X on Nova. - Moving to a newer and better library, oauthlib. Near the end of the release, there were some concerns brought up about the current library being used.
Discuss designs for auditing Notifications for Low-Level Authentication, Authorization and Policy Decisions
In order to properly audit the access or management of an data or workload governed by a cloud platform, regardless of industry (e.g. Banking, Financial, Healthcare, etc.) or compliance regulations (e.g. Basil, SSAE16, HIPAA, ISO 27000, etc.), all low-level security decisions based upon security identities and policies (including access control groups management and administrator/privileged actions) need precise audit information to be recorded. Ceilometer has recently added support for standardized auditing of external OpenStack APIs which can leveraged for internal auditing of such critical security events. However, these API records need to be correlated to the "control" decisions made by Keystone that the API access decision was based upon.
