Jump to: navigation, search

Difference between revisions of "KeystoneFolsomSummitTopics"

 
Line 2: Line 2:
 
Keystone Folsom Summit Topics
 
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/keystonelight12: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 )] kk12:58 [freenode] [msg(westmaas)] we haven't committed to doing them all yet12:58 [freenode] [msg(westmaas)] though i think nova is currently already doing it12:58 [freenode] [(westmaas ~westmaas@184-106-186-202.static.cloud-ips.com )] yeah it is13:01 [freenode] [msg(westmaas)] just talked it over with vish, we have a pretty decent plan for what to do with the middleware, actuals13: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 stuff13:04 [freenode] [msg(westmaas)] this will allow us a little bit of flexibility if something small changes or we want to add some default  behaviorsHow to allow for/enable multifactor authentication------------------------------------------------------------------------------------------------------------------------ pluggable backend for multiple authN sources (ex: mobile authN from verisign but SMS done through Telesign)
+
What we're doing with Middleware - does it reside in Keystone, each project, etc.
- 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.'''Default tenant'''
+
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/keystonelight12: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 )] kk12:58 [freenode] [msg(westmaas)] we haven't committed to doing them all yet12:58 [freenode] [msg(westmaas)] though i think nova is currently already doing it12:58 [freenode] [(westmaas ~westmaas@184-106-186-202.static.cloud-ips.com )] yeah it is13:01   [freenode] [msg(westmaas)] just talked it over with vish, we have a   pretty decent plan for what to do with the middleware, actuals13: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 stuff13: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
-----------------------------------------------------------------------------------------------------------------------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
+
  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.'''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

Revision as of 20:27, 7 February 2012

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/keystonelight12: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 )] kk12:58 [freenode] [msg(westmaas)] we haven't committed to doing them all yet12:58 [freenode] [msg(westmaas)] though i think nova is currently already doing it12:58 [freenode] [(westmaas ~westmaas@184-106-186-202.static.cloud-ips.com )] yeah it is13:01   [freenode] [msg(westmaas)] just talked it over with vish, we have a   pretty decent plan for what to do with the middleware, actuals13: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 stuff13: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.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