18:02:12 <heckj> #startmeeting 18:02:13 <openstack> Meeting started Tue May 29 18:02:12 2012 UTC. The chair is heckj. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:02:14 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 18:02:28 <heckj> Ola all 18:02:35 <heckj> #topic status and progress... 18:02:45 <heckj> milestone 1 is cut and available 18:02:50 <heckj> so we're into milestone 2 18:03:11 <heckj> #link https://launchpad.net/keystone/+milestone/folsom-2 18:03:25 <heckj> Lots of blueprints this next milestone 18:03:31 <ayoung> IPv6.... 18:03:48 <ayoung> I was hoping to use Apache HTTPD and make it a non issue. 18:03:49 <rafaduran> hi all 18:04:02 <ayoung> Let me check on the status of Eventlet upstream IPv6 support. 18:04:09 <dolphm_> o/ 18:04:16 <heckj> ayoung: sounds good 18:04:32 <heckj> token_id work is under review now 18:05:04 <heckj> V3 API is in review, and needs another draft. I have a significant amount of feedback to pull together this week. 18:05:19 <heckj> Is joesavak around? 18:07:09 <heckj> dolphm (guilty by association here) - any idea what joesavak specifically wanted with https://blueprints.launchpad.net/keystone/+spec/rbac-keystone? (I updated the whiteboard with what I think it needs, but wasn't sure) 18:08:19 <dolphm_> He reviewed my proposal, and gave it a thumbs up 18:08:37 <dolphm_> Some of his feedback was already included in what I posted tithe draft API 18:08:58 <heckj> dolphm_: do we need a separate blueprint for what he wants there? 18:09:34 <dolphm_> Something specific you're referring to? 18:09:59 <heckj> dolphm_: just trying to figure out what he wanted with the blueprint and how to track it's "progress". 18:10:03 <heckj> everett toewes about? 18:10:17 <dolphm_> He likes actions/capabilities, doesn't need rules for rax 18:10:27 <heckj> chmouel? 18:10:48 <heckj> dolphm_: I guess my question really is should we be tracking a blueprint for that specific work against the v3 api? 18:11:53 <dolphm_> I'd roll it into the RBAC-keystone bp, but it's up to you 18:13:19 <heckj> I'll hunt down chmouel and everett related to the last two blueprints in folsom-2 to find out how they're doing and what help might be needed. Everett is a new contributor, so i'm expecting he'll need some 18:13:45 <heckj> #topic open discussion 18:14:33 <heckj> We've got a pile of reviews outstanding. I'm working through a number today 18:14:52 <heckj> haven't checked bug and questions this week yet either, so I"ll be trying to hit that today as well 18:15:28 <heckj> Any open questions? 18:16:15 <liemmn> o/ Thanks for all the love for https://review.openstack.org/#/c/7706/... How do we trigger SmokeStack for patch set#3? 18:16:39 <ayoung> https://review.openstack.org/#/c/7706/ 18:16:49 <ayoung> the ... messes up the hyperlink 18:17:22 <liemmn> What ...? 18:17:27 <heckj> liemmn: not entirely sure… mtaylor or dprince might have a good idea 18:17:28 <dolphm> need someone with smokestack admin access to retrigger last i asked 18:17:39 <liemmn> okie dokie 18:18:38 <ayoung> who are the core reviewers? Why does this patch require so many reviewers to get in? We have 3 community members plus core.... 18:19:00 <heckj> ayoung: all reviews take 2 core reviewers 18:19:21 <dolphm> i'm happy to +2 if there's community consensus there 18:19:38 <heckj> core members are https://launchpad.net/~keystone-core/+members 18:19:39 <ayoung> dolphm, are you core? 18:19:45 <dolphm> ayoung: yes 18:20:08 <ayoung> yeah, and this code is basically adding in functionality that didn't make the KSL redo 18:21:24 <ayoung> As far as other topics: I have a working proof of concept of the PKI signed tokens 18:21:38 <dolphm> :D 18:21:42 <ayoung> #link https://github.com/admiyo/keystone/tree/signed-tokens 18:21:46 <heckj> ayoung: nice! 18:22:26 <ayoung> One thing I noticed is that the service.py authenticate method is kindof overflowing its scope. I think this should move mostly into a middleware component 18:22:53 <ayoung> it does more than authenticate, really, as it also generates the data for the token, then calls the token API 18:23:08 <dolphm> what would you move to middleware? 18:23:35 <dolphm> it is a token api call 18:23:40 <ayoung> this one might include a refactoring where user-id authentication is one middleware component, and the token generation and persistance a different one 18:24:00 <ayoung> I have to grok the architecture a little bit better 18:24:36 <dolphm> if you can simplify, please do! 18:25:09 <ayoung> dolphm, there are 3 stages as I see it. 1 is authenticate. 2 Is generate token, and that needs to call the SSL binary (in my first impl) 3 is persist to DB/KVS whatever 18:25:45 <ayoung> I'd like to be able to say: add in these two authentication mechanisms: basic-auth, certiificate, and if you use those, you then get aswsigned a token 18:26:02 <ayoung> however, if you come in with a token, you can do new things. 18:26:28 <ayoung> But you need to use a non-token based auth in order to get assigned a token, or tokens never really time out... 18:27:09 <dolphm> basic-auth == http basic auth? 18:27:14 <ayoung> dolphm, yes 18:27:42 <ayoung> dolphm, as well as client certificate auth, which is part of the PkI blueprint. 18:27:59 <dolphm> makes sense to me 18:28:40 <ayoung> dolphm, the idea is, I think, that the authentication mechanism sets REMOTE_USER, which is the WSGI way of saying the container has done auth for us. 18:29:16 <ayoung> So the definition of authenticated is that REMOTE_USER is set, and then we can build a token for users that need it 18:29:45 <ayoung> It should also allow us to interop with Apache HTTPD a little more cleanly 18:29:51 <dolphm> cool 18:31:58 <ayoung> heckj, I'd like to backpeddal on https://bugs.launchpad.net/keystone/+bug/996139 18:32:04 <ayoung> "Change default token backend from KVS to SQL " 18:32:05 * heckj looks 18:32:06 <uvirtbot> Launchpad bug 996139 in keystone "Change default token backend from KVS to SQL" [Undecided,In progress] 18:32:14 <ayoung> I think that change only makes sense if we default to HTTPD 18:32:37 <ayoung> I think that for Eventlet, I'd prefer to keep the Tokens in memory. Especially in light of the PKI Signing 18:32:55 <dolphm> what's the impact from pki? 18:33:04 <ayoung> since we won't have to go back to Keystone to authenticate tokens, "losing" them on reboot is no longer a real concern 18:33:34 <heckj> ayoung: I'm OK with that. You're welcome to mark the bug as invalid to kill it. 18:33:45 <ayoung> I like memory vs SQL for security reasons 18:34:02 <ayoung> IE, you can't get access to everyone's token via A SQL query 18:34:08 <ayoung> heckj, OK. Will do 18:34:16 <dolphm> ah 18:34:43 <dolphm> do pki tokens need to be persisted at all, then? or just logged a bit 18:35:17 <rafaduran> ayoung: if many tokens are saved in memory, can be an issue? 18:35:35 <ayoung> rafaduran, possibly 18:36:00 <ayoung> the new tokens are going to be larger. Probably about 700 Bytes or so, ve 64 currently 18:36:10 <ayoung> vs 18:36:36 <ayoung> rafaduran, so maybe the right answer is to not persist them at all 18:37:15 <ayoung> I could see an argument that for Signed tokens, just append the new tokens to an audit log 18:37:16 <rafaduran> ayoung: yes, I think so 18:38:06 <rafaduran> ayoung: if you are not going back to ask for them not saving them seems the way to go 18:39:34 <ayoung> rafaduran, let me think about that for a bit. There is some discussion vis-a-vis revocation I want to deal with first 18:39:42 <ayoung> revocation might require persistance 18:40:20 <dolphm> ayoung: pki tokens still have an identifier, i assume? 18:40:43 <dolphm> ayoung: persist only that, and remember its state? 18:40:45 <ayoung> dolphm, well, for the first approximation, it is the whole token 18:41:05 <dolphm> a hash of the entrie token then? 18:41:13 <dolphm> sha1 or whatever 18:41:20 <ayoung> dolphm, I thought there was a separate Blueprint for splitting Token ID from secret portion 18:41:32 <ayoung> Hashing would be fine...just not certain yet it is required 18:41:40 <dolphm> ayoung: that was just a thought, i didn't make a bp 18:42:30 <ayoung> If a token has a life span of 8 hours, are we really going to need revocation? 18:42:51 <dolphm> ayoung: 8 hours is an eternity ;) 18:43:05 <ayoung> I tend to doubt it, as it makes the system much more complex, and Kerberos works with 8 hour service tickets for 20+ years now 18:43:43 <ayoung> dolphm, the only reason to make them that long is if tokens need to be used in batch jobs or something 18:44:00 <ayoung> for most uses, 20 minutes would likely be fine 18:44:06 <dolphm> personally, i think "need" is relative, so i'm just playing devil's advocate 18:44:22 <ayoung> The devil can hire his own advocates. He has the payroll for it 18:44:26 <dolphm> as long as the token lifespan is configurable 18:44:30 <dolphm> lol 18:44:40 <ayoung> dolphm, that is my thinking 18:47:52 <rafaduran> ayoung: I don't know a lot of encryption so probably is a bad idea, but you could get automatic revocation if the encryption includes a variable part that changes/cycle afet expriation time 18:48:24 <ayoung> rafaduran, if it is after expiration time, you have to go and get a new certificate. 18:48:37 <ayoung> lets call them tokens, actually 18:48:48 <ayoung> so the signed token has a expiry in it 18:49:08 <ayoung> and the auth_token middleware will check that 18:49:21 <ayoung> if the token has timed out, the user will not be authenticated 18:49:44 <ayoung> the usually deal is that they then go back to keystone and get a new token 18:50:33 <rafaduran> ayoung: I think that would work fine 18:50:39 <ayoung> We can provide a grace period if the token was used to auth against, say, Nova, and then is needed a while later to talk to, say Quantum. 18:51:22 <ayoung> and b "talk to" I mean that nova sends the token along as part of a quantum request.... 18:54:37 <mtaylor> heckj: aroo? 18:54:52 <heckj> mtaylor: ola 18:55:13 <heckj> y'all good with ending the meeting? 18:55:59 <heckj> #endmeeting