18:01:24 #startmeeting 18:01:25 Meeting started Tue Jul 3 18:01:24 2012 UTC. The chair is heckj. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:01:26 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 18:01:44 How's things? 18:01:53 #topic folsom-2 milestone 18:02:23 #link https://launchpad.net/keystone/+milestone/folsom-2 18:02:54 dolphm: you and I have a few reviews outstanding - otherwise we're in good shape for the F2 release milestone 18:03:03 o/ 18:03:14 heckj: i'll take another pass this afternoon 18:03:59 ayoung: around? 18:04:11 is jenkins having a bad day again? :-/ 18:05:09 oh, probably 18:05:51 Reviews that need someone other than Dolph or I looking at this for the F2 release: https://review.openstack.org/#/c/8909/, https://review.openstack.org/#/c/9182/ 18:05:57 both for F2 milestone 18:06:00 #link https://review.openstack.org/#/c/9182/ 18:06:06 #link https://review.openstack.org/#/c/8909/ 18:06:53 #topic hot issues 18:07:03 Any new issues? Hot topics? 18:07:22 Heckj, when is the v3 API "frozen"? 18:07:35 \)/ 18:08:07 finally got the SSL Cert generation into Keystone 18:08:09 liemmn: I'm going through the existing feedback now - going to take one more cut at it, and then it'll be solid enough to start development against 18:08:22 I'd hoped to do that this past weekend, but ended up sleeping through most of it 18:08:29 sounds good :) 18:08:33 ayoung: yeah!!! 18:08:42 heckj, do we have a summary sheet of the changes? 18:08:50 ready for implementation != frozen, correct? 18:08:53 I have to present on it, and am lazy 18:09:05 liemmn: I do expect to leave the spec "open" per bcwaldon's suggestion to allow us to revise as we run into implementation issues 18:09:17 ayoung: #link https://launchpad.net/keystone/+milestone/folsom-2 18:09:21 heckj: is that what glance did? 18:09:29 dolphm: yeah 18:09:46 dolphm: Brian said it made a huge difference for their work as they sussed out deeper issues 18:09:57 heckj: i can imagine :) 18:10:02 should I add in https://bugs.launchpad.net/keystone/+bug/994860 ? 18:10:03 Launchpad bug 994860 in keystone "Keystone middleware auth_token assumes top level URL when making http connection" [Medium,In progress] 18:10:10 ayoung, there were some feedback on making PKI optional... That is still in the plan right? 18:10:25 liemmn, I don't want it optional. 18:10:38 I'd rather have it out there, have everyone beat on it 18:10:47 and if it is a real problem, we roll back 18:11:00 but some implementers will not use PKI 18:11:02 there are 2 parts to it: token generation and token validation 18:11:13 the old style validation *can* be done with the new tokens 18:11:20 ayoung: I think it's only pending unit tests 18:11:31 but vice versa is not 18:11:47 heckj, my ticket? Yes, I will get unit tests. I meant should I add that bug to the API blueprint? 18:12:06 jrouault, why would they not use PKI? 18:12:10 ayoung: not worried too much about it either way - 18:12:21 heckj: ayoung: can we "demote," for example, the token validation call to an official extension, if it's not necessary for PKI and PKI is core? 18:13:04 dolphm, I don't think that is wise 18:13:13 ayoung, so... if someone is using non PKI and going through to Keystone backend to do a validation (and have no cert), how would that work with PKI enforced? 18:13:13 ayoung: because they have implementations running today that dont require it 18:13:16 dolphm, ayoung: I don't want to demote anything at this point 18:13:18 I think PKI will give us many new features. Probably most important is Federation 18:14:27 liemmn, token is generated using PKI. That means that it can be validated with the signing cert. But it can also be validated the old way: by asking Keystone directly. 18:14:40 I am going to post another patch shortly that is just the token generation 18:14:47 the vaolidation will be a separate patch 18:15:33 Cool, as long as we can still have an option to ask Keystone to validate the token, should the signed cert is not there, I think that should be ok 18:15:47 dolphm, the thing is, token validation without calling to keystone is pretty much the reason for having PKI in the first place. Otherwise, we've just implemented a slightly more expensive token generation scheme 18:16:00 liemmn, signed cert is fetched on demand 18:16:39 which is why it should be optional whether the token is signed 18:16:39 I mean, if a token is not signed, then we have the option to ask Keystone to validate the token as before... 18:16:41 One thing that is currently missing, and I am tempted to try and add before submitting the token generation is the ID of the Keystone server 18:16:49 ayoung: PKI will be part of just v3 API or it will land into master before it? 18:17:11 ayoung: that's why i don't like it remaining in the "core" api 18:17:11 rafaduran, it makes no changes to the API and will land before it 18:17:12 rafaduran: he's aiming to have it in prior to V3 api - in progress now 18:17:21 ayoung: it's just bloat if it's not recommended 18:17:35 granted, it should be kept around 18:18:25 dolphm, this is based on the lessons learned in other IdM systems. Probably most notably is Kerberos. THe biggest difference between V4 and V5 is the way that service tickets are validated, which is what this is echoing 18:19:16 another reason to support the current token scheme in conjunction to the PKI scheme is to support token revocations 18:19:52 It should have a significant impact in decreasing the amount of network traffic 18:20:12 not arguing that... just asking that is be optional 18:20:23 you configure if you want PKI or not 18:20:47 we do need it to work side-by-side with the legacy mechanisms and not break the legacy mechanisms 18:21:18 #topic keystone-core 18:21:28 Switching topics - sounds like that one's tapped out 18:21:36 I'm proud to announce the addition of ayoung to keystone-core 18:21:54 awesome 18:21:57 ayoung: grats 18:22:00 I'll send a note out to the list shortly with the same 18:22:04 thanks 18:22:10 ayoung: awesome work, thank you - and here's more to do 18:22:27 :-) 18:23:41 #topic open discussion 18:24:12 um...one last thing on the PKI tokens...I was planning on changing the behavior of auth_token middleware, but I could also privde a different middleware for it....I could do something like check the length of the token, and if it is short, assume it is a hashed (current style) token, but if it is longer than some threshold, assume it is PKI signed. Question then is do we want to make people 1) default to phone home and enable 18:24:12 signing validation or 2) default to PKI validation and explicelty enable phone home? 18:24:41 My thought is that we should push the new functionality to ensure that people test it and report issues 18:25:04 we can provide the fall back...so you would have to explicitly set the middleware on, say glance 18:25:18 I'd hoped to avoid doing anything along those lines.... 18:26:27 so you will then support unsigned tokens? 18:26:36 ayoung: shouldn't you try to decrypt in middleware, and if that fails, try phoning home if phoning home is enabled? 18:26:41 jrouault, only under duress :) 18:26:44 ayoung: otherwise immediately fail? 18:26:57 ayoung: extending the current auth_token middleware should be fine as long as it doesn't get too complex in there. kind of a judgement call though. 18:26:58 ayoung: fail = reject authentication 18:27:03 ayoung, you could leave the auth_token as is to provide the default behavior, and create a new filter before auth_token to handle PKI tokens. If the tokens are not PKI, then let them fall to the auth_token for legacy support. 18:27:13 +1 18:27:22 liemmn, but that makes a configuration nightmare 18:27:36 just another filter in the WSGI pipeline... 18:27:47 liemmn, I object to the word "just" 18:27:51 means we have to change a bunch of client pipelines 18:28:00 liemmn: that doesn't sound like it will work at all -- auth_token will filter out incoming authentication claims as-is 18:28:12 it means that we have to change devstack, plus any tool like puppet or chef... 18:28:22 human sacrifice, dogs and cats. living together 18:28:26 heh 18:28:26 liemmn: and always attempt token validation 18:28:27 masss hysteria 18:29:21 Here's a thought. Let me get the token generation code through review and into the repo, and let people beat on it for a while. 18:29:41 well.. the alternative is to have auth_token do it all... that's fine too, but IMHO, I am just trying to do separation of concerns... did not think about deployment 18:29:42 Meanwhile, we can go through the auth_token code with a fine tooth comb, deal with corner cases etc 18:30:08 ayoung: that sounds like a good take on it 18:30:10 i would like to conclude on whether PKI usage will be optional... 18:30:23 I'd like to make it default 18:30:33 but provide an override to turn it off? 18:30:49 jrouault: are you asking about the api or keystone's implementation? 18:31:02 yes, I would like to turn it off and use the v2.0 mechanism 18:31:14 jrouault: We will support that 18:31:24 i'd vote for optional in API, and required (or at least on by default) in keystone 18:31:35 doph: my understanding is ayoung wanted to force all tokens to be signed... I don't want to do that if I am using the v2 mechansim 18:31:46 of validation 18:31:59 it is unnecessary overhead 18:32:12 jrouault: still not sure if you're referring to the v2 api or v2 implementation? 18:32:16 jrouault, out of curiousty, why? I mean, I understand the revokation issue, but beyond that, what issue do you see with PKI? 18:32:37 if I request a token from Keystone configured for no PKI, i should get a token back that is not signed 18:33:13 jrouault, are you worried about doing a rolling upgrade? 18:33:29 jrouault: as a service consumer, does it matter? 18:33:50 no, we have use cases where a signed token will just cause us greif 18:34:00 jrouault: example? 18:34:55 jrouault, the token is opaque. To the end user, the only difference will be the length 18:35:07 and they should not really even care about that 18:35:13 and that will cause problems for other services we have 18:35:18 jrouault: example? 18:37:37 jrouault: can you expand on the "grief" and what causes it? 18:37:52 jrouault: i'm not sure how we're supposed to address issues that you're not sharing or justifying 18:38:25 1. we have other services that consume tokens that have problems with the length 18:38:45 OK...I'll put in a disalbe override, but leave enabled the default. Will that suit everyone? 18:38:56 yes 18:39:18 jrouault, so you specifically need the shorter length? 18:39:20 jrouault: what kind of length is problematic? what lead you to assume a specific length? 18:40:23 jrouault: is there a maximum token length documented somewhere that we need to correct? 18:40:58 2. we also have some keystone like token generators that are used for testing... those would all need to change to support signing... but that is not so much a concern for the community 18:41:23 jrouault, I can help you build some replacements. 18:41:38 jrouault: I'm most interested in the length issue and what you're hitting there - do you have a max length? 18:42:11 heckj: i do have the exact length but can get that to you 18:42:34 s/don't/do 18:43:16 jrouault: thanks - would like to know that ASAP, as there's a bunch of other potential impacts there 18:43:36 OK...I'm thinking that is insufficient reason to hold up the PKI side of things. THe token length could change for many reasons without PKI. I am not really willing to disable the server side just for a specific test harness 18:44:33 making it optional is holding things up? 18:44:57 ayoung: don't hold up the PKI effort - carry it forward, let's just make sure we can disable it as an option, but not as the default settings 18:45:18 heckj, disabling it is not trivial on the Keystone side. 18:45:51 So it will hold it up. Plus, if both forms of tokens ate allowed, they should be minimally tested 18:46:18 ayoung: gotcha. Let's see what we can suss out to enable both or either at the same time 18:46:44 OK...I'll post the current code to my github page here shortly 18:46:49 sounds good 18:48:53 ayoung: Can I change topic now? 18:48:57 #action jrouault to provide a max key length 18:49:02 rafaduran: yep - 18:49:09 rafaduran, yes, please do so 18:49:13 I've working on the rate limit middleware, I still need some work on it, but It would be nice get some feedback on corner cases, defaults ... 18:49:30 I think it would be nice take some time for next meeting 18:49:44 rafaduran: I'll schedule it up as a specific topic for next meeting 18:49:58 heckj: Ok, thanks 18:51:02 cool - any other topics for today? 18:53:27 Okay - gotta present in 5 minutes, so I'll close this up for today. 18:53:32 #endmeeting