18:00:29 <dolphm> #startmeeting keystone 18:00:30 <openstack> Meeting started Tue Mar 26 18:00:29 2013 UTC. The chair is dolphm. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:00:31 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 18:00:33 <openstack> The meeting name has been set to 'keystone' 18:00:52 <dolphm> ayoung: o/ 18:00:55 <joesavak> o/ 18:01:14 <dolphm> #topic Anything on fire? 18:01:37 <dolphm> (silence is appreciated here) 18:01:47 <topol> :-) 18:01:57 <henrynash> dolphm: so am debugging why the current master fails to run the test_sql_upgrade scripts on MySQL and PostGres 18:02:14 <dolphm> henrynash: master without my patch, you mean? 18:02:21 <henrynash> dolphm: yes! 18:02:33 <dolphm> henrynash: does db_sync fail? 18:03:00 <ayoung> I'm here! 18:03:09 <henrynash> dolphm: seems to be when you downgrade to zero…problem with tenant membership table 18:03:22 <henrynash> ok with sqlite, of course 18:03:25 <dwaite> ayoung: o/ 18:03:31 <dolphm> henrynash: have you seen christopher yeoh's comments on a similar issue in postgresql? 18:03:38 <henrynash> dolphm: yes 18:03:43 <dolphm> 0->22->0 fails on postgres 18:03:50 <dolphm> but only in test_sql_migrations 18:03:52 <henrynash> dolphm: yea I found that too 18:04:02 <henrynash> dophm: that matches what I have found…. 18:04:09 <dolphm> henrynash: in db_sync or test_sql_upgrade? 18:04:20 <henrynash> dolphm: test_sql_upgrade 18:04:48 <dolphm> i'm inclined to say it's an issue with the test infrastructure, not an issue with the migrations 18:04:50 <henrynash> dolphm: so I think its probably our bad test code….but want to make sure 18:04:59 <henrynash> dolphm: I tend to agree 18:05:11 <dolphm> i.e. test_sql_upgrade and test_sql_migrations aren't properly mimicking the process of db_sync 18:05:11 <henrynash> dolphm: will try to get to the bottom of it 18:05:54 <dolphm> henrynash: thanks; if you find that it's an issue with db_sync, we need to raise a bug / backport fix ASAP 18:06:00 <henrynash> dolphm: yep 18:06:15 <henrynash> dolphm: I also just raised this bug https://bugs.launchpad.net/keystone/+bug/1160504 18:06:16 <uvirtbot> Launchpad bug 1160504 in keystone "Grizzly v2 catalog has slight formatting changes compared to Folsom" [Undecided,New] 18:06:58 <dolphm> oh wow, that's breaking 18:07:16 <dolphm> err, hmm 18:07:21 <dolphm> i reviewed this, hold on 18:07:30 <dolphm> this was a mismatch between spec and reality 18:09:33 <dolphm> targeted that at rc2 for review, at minimum, i can't find the relevant patch atm 18:09:42 <henrynash> dolphm: ok 18:09:43 <dolphm> it was a tested change to the xml serializer though 18:09:53 <dolphm> #topic Grizzly release candidate status (RC2) 18:09:58 <dolphm> #link https://launchpad.net/keystone/+milestone/grizzly-rc2 18:10:05 <henrynash> dolphm: yea , remember it…and we added some special code doe links etc. 18:10:42 <topol> dolphm, what is the target date for RC2? 18:10:53 <dolphm> topol: always ASAP 18:10:55 <dolphm> anyone aware of any other issues or patches that need to be backported, or considered for backporting to grizzly? 18:11:19 <topol> dolphm, I am working on TLS Support for LDAP. Should be done soon 18:11:36 <dolphm> topol: features especially can't be backported 18:11:54 <dolphm> we' 18:11:59 <dolphm> we're open for havana though :) 18:14:07 <gyee> dolphm, found an inconsistency with credential 18:14:13 <dolphm> gyee: link? 18:14:20 <gyee> in the spec we have "data", but in impl we have "blob" 18:14:28 <gyee> I haven't file a bug yet 18:14:56 <dolphm> gyee: unless we have a strong preference for 'data', i think we should fix the spec at this point 18:15:08 <gyee> dolphm, no argument here 18:16:39 <dolphm> gyee: ping me when you have a review up 18:17:13 <dolphm> if we only have one issue left (that may not need a fix?), we might be able to cut rc2 today 18:17:22 <dolphm> that was my goal before henrynash's issue at least :) 18:17:27 <dolphm> #topic Review, revise & amend Keystone's release notes 18:17:35 <dolphm> #link https://wiki.openstack.org/wiki/ReleaseNotes/Grizzly#OpenStack_Identity_.28Keystone.29 18:17:48 <dolphm> i got our release notes started last week, and have noticed a few contributions since 18:18:20 <dolphm> i'd encourage everyone to make sure all the features and potential upgrade issues you're familiar with are included, and doc them if not -- even if it's just a stub so someone else can go fill it in later 18:18:21 <gyee> dolphm, will oauth be part of rc2, or havana? 18:18:28 <dolphm> gyee: havana 18:18:31 <gyee> cool 18:18:54 <topol> dolphm, do we have a blueprint for oauth? 18:19:06 <ayoung> dolphm, TLS will probably be nominated for backport to Grizzly stable 18:19:24 <dolphm> termie opened one today https://blueprints.launchpad.net/keystone/+spec/delegated-auth-via-oauth 18:19:26 <topol> dolphm, because adding oauth can me a couple of things 18:19:40 <topol> dolphm, OK 18:19:43 <gyee> yeah, LDAP + TLS is recommended 18:19:44 <dolphm> topol: have you seen termie's impl? 18:19:52 <dolphm> i don't believe it's in review, but it's on his github 18:19:59 <gyee> doing LDAP auth without TLS/SSL is like driving without seatbelt :) 18:20:03 <ayoung> dolphm, it was cursory last I looked 18:20:05 <topol> dolphm, I have steve martinelli digesting as we speak 18:20:10 <ayoung> let me see if he has updated 18:20:26 <dolphm> i think that's why he didn't put it in review 18:20:41 <dolphm> termie: feel free to post it to gerrit as WIP ;) 18:20:55 <ayoung> +1 18:21:09 <ayoung> dolphm, also, is it possible to comment on the gist? 18:21:09 <gyee> +1.0 18:21:33 <ayoung> #link https://gist.github.com/termie/5225817#file-delegated_auth 18:21:34 <dolphm> ayoung: yes, you can comment on gists at the bottom of the page 18:22:36 <dolphm> #topic oauth support 18:22:41 <dolphm> because why not 18:23:36 <dolphm> topol: is steve looking through the spec, impl, or both? 18:23:45 <stevemar> dolphm: both 18:24:27 <dolphm> stevemar: thanks 18:24:41 <ayoung> The more I learn about oauth, the more I think it is the right approach. Trusts is really a limited subset of the functionality, but it maps pretty clearly to oauth. The major benefit is that oauth provides a way that the remote service can specify what roles are requred 18:25:15 <dolphm> yeah, i think oauth is a great long term solution 18:25:22 <stevemar> ayoung: does that mean we will get rid of trusts? I think termie submitted something for that already 18:25:23 <ayoung> Also, I think I was a bit put off by the bad reputation that oauth2 has, but didn't realize just how supported the version 1 protocol was. 18:25:27 <dolphm> i'm just not familiar enough with it myself -- yet 18:25:30 <ayoung> stevemar, no 18:25:38 <ayoung> stevemar, more likely we will merge 18:26:04 <gyee> dolphm, https://review.openstack.org/25421 18:26:06 <ayoung> stevemar, as I see it, anything set up with trusts can be served by oauth 18:26:07 <dolphm> stevemar: care to share your initial impressions? 18:26:13 <ayoung> so it is a superset of functioanlityy 18:26:19 <stevemar> ayoung: yeah, from what I read - the community was split when v2 came out, v1 is well supported though 18:26:22 <ayoung> long term, yeah, proably won'tbe much call for trusts 18:26:49 <ayoung> but we need a way to prime the pump for delegation, and trusts will allow people to do that for Grizzly 18:26:54 <stevemar> dolphm: still have to digest a lot of things, it's all coming in quickly now 18:26:59 <topol> dolphm, so two ways to look at oauth. Using it between openstack components and using it to bridge the outside world to openstack world 18:27:40 <ayoung> oauth should be in Havana, with a migration for established trusts, and the trust API will still work against the unified table 18:28:15 <topol> stevemar will gather use cases to make this more clear 18:28:15 <ayoung> topol, it looks like using it between OS components is a pretty straightforward simplificaition of the overall protocol 18:28:42 <topol> ayoung, assuming the other components buy in I agree! 18:28:52 <ayoung> and one thing you could do if you didn't want to support the bridge would be to enforce that all consumers are entires in the user tables 18:29:07 <dolphm> partly related summit session... 18:29:09 <dolphm> #link http://summit.openstack.org/cfp/details/111 18:29:10 <topol> stevemar will gather info on the bridge to the world use case 18:29:16 <dolphm> dwaite: ^ 18:29:34 <stevemar> dolphm: i was *just* going to link that, but was afraid it would cause confusion :) 18:29:35 <dwaite> not sure the community which was split on v2 18:30:00 <ayoung> dwaite, oh yes it was 18:30:02 <dwaite> one person involved in creating v2 rage-quit the project :) 18:30:11 <ayoung> dwaite, he wasn;t the only one. 18:30:16 <dolphm> dwaite: how much time do you intend to spend on oauth? 18:30:18 <ayoung> Just the most visible 18:30:22 <dolphm> percentage wise 18:30:44 <dwaite> I was thinking 10 minutes on oauth itself 18:31:33 <dwaite> 10 on saml, 2.5 on SCIM and JWT, saving 15 for talk 18:32:44 <dolphm> i suspect that the introduction of oauth might be the biggest change on the table for havana; if that's the case, i'd like to make sure we have a significant chunk of time dedicated to it at the summit 18:32:53 <dwaite> more seriously wrt oauth 1 and 2, there are three usual points of contention on the protocol. One is that the tokens alone are used for authorization of the API, without any other user/client proof tokens. There are some efforts to add MAC profiles back to the spec for this 18:32:53 <henrynash> dolphm:…and you may have seen I put in a second session for us to then talk about how we implment 18:33:12 <dwaite> but the tokens in use today in openstack are the same; just a token, put in a header. 18:33:17 <dolphm> henrynash: link? 18:34:39 <dolphm> dwaite: ideally we don't have to change the X-Auth-Token infrastructure, as doing so would be an expensive and slow process 18:35:03 <dwaite> second is that there is a push to have clients identified in general (limiting API access to clients who have registered and been approved and possibly agreed to terms of service). Its anti-hacker, while a fair number of people consider APIs to be complete fair game 18:35:24 <henrynash> http://summit.openstack.org/cfp/edit/157 18:35:31 <dwaite> dolphm: I suspect that the first step would be to support the header style of OAuth (Authorization: Bearer <token>) in tandem 18:35:34 <dolphm> #link http://summit.openstack.org/cfp/details/157 18:35:38 <dwaite> and phase that out slowly 18:35:47 <dolphm> henrynash: swap /edit/ for /details/ 18:36:21 <ayoung> So might I address that last point? 18:36:25 <dwaite> the third issue I see people have with OAuth is that there are so many different options for acquiring a token. There are web flows, username password flows, flows where users aren't involved and its just service to service, etc. 18:36:53 <ayoung> As I see it, for getting beyond bearer tokens, there are three approaches worth addressing 18:36:53 <dolphm> ayoung: absolutely; this wasn't anyone's specific time slot on the agenda 18:36:59 <dwaite> this is probably the main reason people say oauth 2 is a framework, and not a protocol - because there is no MTI here, its just based on what you want to support 18:37:16 <ayoung> 1. add a public key to the tokens, and sign the request. Lets call that "roll your own PKI" 18:37:24 <dwaite> I would propose we support username/password to start, which is closest to what keystone does today, and move forth from there. 18:37:42 <ayoung> 2. Kerberos, and extend the authorization data with the information we have in the token today 18:37:48 <ayoung> 3. X509 18:38:09 <ayoung> The benefit of X509 is that we can then use the same infrastructure for all of the security related pieces 18:38:16 <ayoung> but it is not too clean 18:38:32 <ayoung> there is no standard way to do authorization data, short term certificates, etc 18:38:41 <ayoung> not unsurmountable problems, but worth mentioning 18:38:52 <ayoung> Kerberos has a few short comings as well 18:38:56 <dwaite> SAML is closest to that IMHO (short term certificates) 18:39:11 <ayoung> dwaite, but you can't use SAML to set up SSL connections 18:39:16 <dwaite> nope 18:39:21 <ayoung> so it woudl be "in conjunction with" 18:39:50 <ayoung> kerberos you can't use the service tickets to set up SSL either 18:39:57 <ayoung> and you need to fetch thme over port 88 18:40:14 <ayoung> and there is no firm standard about what should be in the authorization data 18:40:22 <ayoung> Also, a negotiate call requires 2 round trips 18:40:42 * ayoung will explain negotiate later to any that really care 18:40:45 <dwaite> kerberos becomes a real pain when you start to cross domain boundaries. thats the driver behind Microsoft supporting federation protocols like SAML 18:41:06 <ayoung> so typically you end up doing something like Kerbers for initial auth and then a cookie 18:41:15 <ayoung> since that cookie can also be our tokens 18:41:27 <dwaite> bearer tokens are hard to get away from :) 18:41:34 <ayoung> Ithink that the first thing to do is to add a credential to the currrent bearer tokens, or option 1 18:41:52 <ayoung> we can make the signing optional to start 18:42:06 <dolphm> ( aside- we should create a design.openstack.org based on stackexchange to allow voting on competing design solution to problem statements :) ) 18:42:11 <ayoung> and we'll have to clarify how the user will specify which credential to use 18:42:39 <ayoung> as well as make sure we do the request signing in an intellegent manner for people that want to use them 18:42:50 <ayoung> over time, we make signing go from optional to expected and required 18:43:09 <ayoung> we can only do that if we have a delegation mechanism, hence the push for trusts 18:43:22 <ayoung> if oauth replaces trusts, no big deal, we still have the mechanism we need 18:44:04 <ayoung> dwaite, there are a few things about Kerberos that make it worth addressing, though 18:44:19 <dwaite> def. 18:44:26 <ayoung> probably the most important is that it is an enterprise must 18:44:38 <ayoung> so good interop is required 18:45:02 <ayoung> to what degree that gets integrated into the rest of the stack can remain to be seen 18:45:44 <dwaite> kerberos in keystone is a must. kerberos in each other service, I could probably argue well against 18:46:01 <ayoung> for example, you could put the auth data into the service ticket, and have the web server that nova runs in use negotiate and an analogy to auth_token 18:46:17 <ayoung> dwaite, there is also some question about securing AMQP 18:46:33 <ayoung> Kerberos there might actually make more sense than at the HTTPS level 18:47:35 <ayoung> We also might want to look at "worst case scenarios" 18:47:57 <ayoung> the most likely target for an attack seems to be nova-compute, since it is running the virtual machines, ie random code from out there 18:48:21 <ayoung> if a hypervisor exploit is found, we want to make sure that they don't end up with admin privs in keystone 18:48:46 <dwaite> so it would make sense to recommend nova and keystone be physically isolated, and for nova to not have delegation privileges 18:49:02 <dwaite> also, to make sure that raw credentials are not sent to nova, so that they would never be able to be captured 18:49:13 <ayoung> dwaite, nova-computet 18:49:24 <ayoung> nova needs it but not the hypervisor, I think 18:49:31 <ayoung> however, that might not meet current arch 18:49:58 <ayoung> for example, an application running in a VM might need to be able to talk to swift 18:50:07 <ayoung> that needs to be very limited scope. 18:51:06 <dwaite> yeah, I suppose constraining the delegation is more appropriate 18:51:15 <dolphm> i'm going to cut ya'll off so we have a bit of time for summit sessions & open discussion 18:51:34 <dwaite> kk 18:51:45 <ayoung> also, when you deploy a VM to a compute node, I assum that the image gets "pushed" from nova-api, but if it actually gets pulled out of glance, the compute node would need a token, and that would be a potential attack 18:51:46 <dolphm> would love to continue in -dev after :) 18:51:47 <ayoung> sure 18:51:48 <dolphm> #topic Design summit sessions 18:52:24 <dolphm> would love for people to become familiar with what's been proposed for the summit 18:52:25 <dolphm> #link http://summit.openstack.org/cfp/topic/9 18:52:40 <bknudson> dolphm: Forbidden 18:52:45 <dolphm> hrm 18:52:52 <dolphm> http://summit.openstack.org/ 18:52:57 <dolphm> and then click keystone 18:53:00 <topol> I am verbotten as well 18:53:04 <dolphm> you might have to login through launchpad? 18:53:55 <bknudson> http://summit.openstack.org/cfp/details/9 18:53:58 <ayoung> yeah, log in 18:54:30 <dolphm> if anyone has new sessions to propose -- do so as soon as possible! so far i've avoided approving/denying anything as new ones are still being proposed, but it looks like at least a few will have to be merged or denied, due to time constraints if nothing else 18:54:34 <ayoung> here are the unreviewed topics 18:55:07 <ayoung> Scaling/Performance of Keystone for the Enterprise, Supporting KMIP in Key Manager, Keystone LDAP Integration for Enterprises , Domain specific backends, Generic support for external authn/authz, 18:55:16 <ayoung> SAML, OAuth 2, and SCIM - Overview and Application, Availability zone and region management 18:55:44 <ayoung> Fine-grained access control, Endpoint Filtering, Service Metadata/Capabilities, Centralized Quotas, 18:55:50 <ayoung> and an incomplete for Use DNS for initial endpoint information 18:57:07 <stevemar> ayoung: dolphm: should termie also have a proposal? 18:57:07 <ayoung> dolphm, I assume we have time for one days worth of topics? 18:57:11 <topol> we gonna review all these in 4 mins? 18:57:19 <stevemar> in case it is not the same as dwaite's OAuth 18:57:24 <ayoung> topol, we need to consolidate 18:57:43 <ayoung> dolphm, we have a day, right? 18:57:45 <dolphm> ayoung: roughly 18:57:53 <dolphm> topol: no 18:57:53 <ayoung> Thursday, with 2 topics pre-approved 18:58:06 <dolphm> topol: just become familiar with them in your free time 18:58:08 <ayoung> Keymanager and KMIP should be one topic 18:58:15 <topol> OK 18:58:28 <dolphm> topol: i'd like to have some initial discussion around them in irc, mailing list, etc before we start rubber stamping stuff 18:58:37 <dolphm> i'd also like to remind everyone that sessions with a goal of concluding with a yes/no tend to go pretty quickly as there's not usually much to discuss (it always seems to be either a resounding yes or resounding no) -- the most productive sessions are the ones with contending design solutions presented or are intended for open discussion on a specific topic 18:58:42 <topol> dolphm, makes sense 18:58:43 <ayoung> Guang, can your two topics be combined? 18:58:59 <ayoung> Service Metadata/Capabilities and Endpoint Filtering seem like almoste.... 18:59:03 <dolphm> lectures are also welcome if you're a super expert on something and are open to questions :) 18:59:43 <dolphm> but we should always walk away with an action item or two from every session 19:00:05 <ayoung> topol, does yours tend to tie in with Generic support for external authn/authz 19:00:11 <dolphm> hrm, we're out of time 19:00:18 <dolphm> switching to -dev! 19:00:20 <dolphm> #endmeeting