KeystoneFolsomSummitTopics

= Keystone Folsom Summit Topics =

What we're doing with Middleware - does it reside in Keystone, each project, etc.

 * 12:16  [freenode] [(westmaas ~ westmaas@184-106-186-202.static.cloud-ips.com )   ]hello sir, some things have been landing in middleware in the  keystone  project lately, especially for glance - will these changes  have to be  re-done as ksl lands?
 * 12:55 [freenode] [msg(westmaas)] not if you do them in th ksl project ;) port the changes you want over right now in http://github.com/termie/keystonelight
 * 12:56 [freenode] [(westmaas ~ westmaas@184-106-186-202.static.cloud-ips.com )] is middleware going to move out of ksl?
 * 12:57 [freenode] [msg(westmaas)] probably at some point, but when they do they will be copied out of the ksl project, (i expect)
 * 12:58 [freenode] [(westmaas ~ westmaas@184-106-186-202.static.cloud-ips.com )] kk
 * 12:58 [freenode] [msg(westmaas)] we haven't committed to doing them all yet
 * 12:58 [freenode] [msg(westmaas)] though i think nova is currently already doing it
 * 12:58 [freenode] [(westmaas ~ westmaas@184-106-186-202.static.cloud-ips.com )] yeah it is
 * 13:01  [freenode] [msg(westmaas)] just talked it over with vish, we have a   pretty decent plan for what to do with the middleware, actuals
 * 13:02  [freenode] [msg(westmaas)] thoughts are thin: we put some base-class   for middleware into keystoneclient that can be subclassed wby the   project middleware, and then the project middlewares do specific stuff
 * 13:04  [freenode] [msg(westmaas)] this will allow us a little bit of   flexibility if something small changes or we want to add some default   behaviors

How to allow for/enable multifactor authentication -

 * pluggable backend for multiple authN sources (ex: mobile authN from verisign but SMS done through Telesign) -
 * Potential out-of-box integration with WikiD - an opensrouce MFA provider-
 * allowing MFA for different tenants/users. Ex: Access to tenant A  requires 3  authN but tenant B requires 2. User Jane requires 3 authN but  user  test_service requires 1.

Catalog crud

 * right now, catalog is template/config file based in keystone/redux -     catalogs are handed back with a user once authenticated, because the     tenantID is embedded into URI for some of the services (SWIFT, I'm     looking at you) -   there's also some use cases related to wanting to   hide endpoints from   some users - i.e. if you're not an admin, don't   return the admin   endpoints.Endpoints   in general need to have a   general discussion from the point of view of   use cases, then   re-examine the API to figure out how to support it.

Federation

 * Huge   topic - means lots of things to lots of people. We need get a  sense  of   what the needs are from the community, and then wrangle this  down  into   something where we can prototype and start small - getting   something   done in the folsom timeframe for expansion as we drive the   project   forward.

Trust & Service

 * the trust zone of an openstack cloud is currently all services receive a token that can use it against other services. It would be preferable to add services without requiring they receive a re-usable token.

Default tenant

 * DO  we even allow a user  to be  created without a tenant - and if so, how  do  we handle the "free   floating user" issue when that case does  occur  (assuming they're   separate entities on some backend  systems)currently nova EC2 keys are  handed out to a user - not a  user-tenant   pair, so they are  theoretically usable by a user  regardless of the   tenant owning the VM  that the user is  accessing/messin' with

RBAC

 * Are the essex requirements for RBAC still the same? Did anything change? We didn't deliver this in Essex, so it's even more needed for Folsom

PKI

 * Certain deployment environments require PKI. How can Keystone accommodate (or generally move towards accommodating) this?

Service relationships

 * A volume service may be associated with an explicit compute service. There is no way to explicitly indicate this relationship via the service catalog today. Type and names can be duplicated according to the contract and expanding a URL type for a relationship seems like over-kill. There needs to be a collection or grouping of services to indicate which ones play well with each other.