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.

Sign up or log in to bookmark your favorites and sync them to your phone or calendar.

Keystone [clear filter]
Tuesday, November 5


API Deprecation and Extensions

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.

(Session proposed by Morgan Fainberg)

Tuesday November 5, 2013 4:40pm - 5:20pm
AWE Level 2, Room 201B


Refactoring Assignments

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?

(Session proposed by Henry Nash)

Tuesday November 5, 2013 5:30pm - 6:10pm
AWE Level 2, Room 201B
Wednesday, November 6


python-keystoneclient: APIClient & auth_plugins

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/

(Session proposed by Jamie Lennox)

Wednesday November 6, 2013 4:40pm - 5:20pm
AWE Level 2, Room 201B


python-keystoneclient: middleware & caching

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.

(Session proposed by Jamie Lennox)

Wednesday November 6, 2013 5:30pm - 6:10pm
AWE Level 2, Room 201B
Thursday, November 7


Federated Identity
Note: This is part 1 of a 2 part session. Part 2 will take place in the same room after a short break.


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:

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

(Session proposed by Steve Martinelli)

Thursday November 7, 2013 4:30pm - 5:10pm
AWE Level 2, Room 201B


Federated Identity (Cont.)

This is a simply a continuation of the previous Federated Identity session, in the same room.

(Session proposed by Dolph Mathews)

Thursday November 7, 2013 5:20pm - 6:00pm
AWE Level 2, Room 201B
Friday, November 8


Token revocation

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:


(Session proposed by Dolph Mathews)

Friday November 8, 2013 1:30pm - 2:10pm
AWE Level 2, Room 201B


OAuth, Trusts and Delegation

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.

(Session proposed by Steve Martinelli)

Friday November 8, 2013 2:20pm - 3:00pm
AWE Level 2, Room 201B


Auditing AuthN, AuthZ and Policy Decisions

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.

(Session proposed by Matt Rutkowski)

Friday November 8, 2013 3:10pm - 3:50pm
AWE Level 2, Room 201B