Difference between revisions of "KeystoneFolsomSummitTopics"
| Line 1: | Line 1: | ||
__NOTOC__ | __NOTOC__ | ||
= 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 behaviors | |
| + | == How to allow for/enable multifactor authentication - == | ||
* pluggable backend for multiple authN sources (ex: mobile authN from verisign but SMS done through Telesign) - | * 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- | * 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. | * 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 | + | == 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. | * 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 | + | == 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. | * 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 | * 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:38, 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
