17:59:35 <dolphm> #startmeeting keystone
17:59:36 <openstack> Meeting started Tue Apr 29 17:59:35 2014 UTC and is due to finish in 60 minutes.  The chair is dolphm. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:59:37 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
17:59:40 <openstack> The meeting name has been set to 'keystone'
17:59:47 <ayoung> \)/
18:00:10 <dolphm> i expect this meeting to be mostly open discussion, following an improv session by our special guest stevemar
18:00:23 <dolphm> #topic Design summit schedule
18:00:25 <dolphm> #link http://junodesignsummit.sched.org/
18:00:27 <ayoung> Compress3ed tokens....review it
18:00:28 <morganfainberg> dolphm, do we get interpretive dance too?
18:00:36 <dolphm> morganfainberg: oh i hope so!
18:00:38 <ayoung> https://review.openstack.org/#/c/71181/
18:00:48 <ayoung> You know you want it
18:01:12 <dolphm> so most projects are starting to post their design summit schedules to http://junodesignsummit.sched.org/
18:01:54 <dolphm> it'd be awesome if everyone took this time to look for obvious conflicts between sessions that keystoners should be attending
18:02:03 <ayoung> dolphm, ++
18:02:38 <dolphm> don't forget to look through the new "cross-project workshops" track as well
18:02:57 <morganfainberg> there are a lot of cross project items that are going to be cool
18:03:04 <lbragstad> #link http://junodesignsummit.sched.org/overview/type/cross-project+workshops#.U1_pS1feRww
18:03:10 <gyee> is there a barbican track or it is rolled into keystone?
18:03:26 <ayoung> Not rolled in
18:03:51 <morganfainberg> this one is an important one for anyone interested in SQLAlchemy, Dogpile, Alembic, etc http://junodesignsummit.sched.org/event/0a0e3cb824a090773c42b67d6ed85d29
18:04:00 <ayoung> The'yll just all be sitting together in the devlounge
18:04:07 <dolphm> gyee: looks like they'll have their own track, but it's not published yet. keep an eye out for it
18:04:16 <dolphm> gyee: their sessions aren't even reviewed yet
18:04:29 <gyee> ayoung, dolphm, seem like there are some integration points we need to discuss
18:04:36 <gyee> keystone and barbican I mean
18:04:51 <ayoung> gyee, ++
18:05:24 <morganfainberg> gyee, this is something we'll likely just need to catch up in the dev-lounge/podarea/whatever it is
18:05:40 <morganfainberg> gyee, for in-person
18:05:45 <joesavak> dolphm - the "Federation" 2:40p Weds design session is before the 9:50 a summit session "Federated Identity & Federated Service Provider support". I think the summit session would drive attendance to the design session.
18:05:49 <gyee> yes absolutely
18:05:56 <joesavak> summit-session being thurs
18:06:09 <nkinder> gyee: I'm curious about what integration points you have in mind
18:06:27 <gyee> nkinder, like credential management
18:06:45 <gyee> authorization
18:06:54 <nkinder> gyee: using it as the password store?
18:07:01 <stevemar> o/ late
18:07:09 <gyee> nkinder, no, not password store
18:07:19 <gyee> I mean access keys, certs, etc
18:07:21 <morganfainberg> nkinder, credentials, certs, etc
18:07:22 <morganfainberg> gyee, ++
18:07:26 <dolphm> joesavak: looking...
18:07:28 <stevemar> joesavak, i agree, i was hoping we could switch things around
18:08:02 <dolphm> joesavak: where's the conference schedule?
18:08:02 <joesavak> dolpm - links: design: http://junodesignsummit.sched.org/event/ab0966f5ec41f78e929effd499e0286f#.U1_p4_ldUog    summit session: http://openstacksummitmay2014atlanta.sched.org/event/e04ac68f0c98be95f9fcbf2812e44d5d#.U1_qf_ldUog
18:08:17 <joesavak> link: http://openstacksummitmay2014atlanta.sched.org/
18:08:23 <dolphm> joesavak: thanks
18:10:20 <ayoung> gyee, you saw this:  http://junodesignsummit.sched.org/event/9a6b59be11cdeaacfea70fef34328931
18:10:32 <dolphm> would swapping the Federation session with python-keystoneclient session resolve the conference conflict?
18:10:41 <ayoung> We'll need to figure out an identity scheme for the various Queue Sinks and sources
18:10:48 <gyee> ayoung, w00t!
18:10:52 <stevemar> dolphm, i think it would
18:11:18 <ayoung> what is the conflict?
18:11:21 <joesavak> agreed
18:11:22 <gyee> ayoung, lets get certmonger in there, we need a realistic provisioning
18:11:31 <gyee> provisioning process
18:11:39 <ayoung> gyee, ++
18:11:50 <morganfainberg> gyee, ++
18:12:03 <dolphm> so python-keystoneclient Wednesday @ 2:40p and Federation Thursday @ 11:50a (with the Federated Identity conference session Thursday @ 9:50a)
18:12:16 <joesavak> dolphm +1
18:12:23 <ayoung> gyee, but certmonger only handles "Here are my certs"  we need to figure out the mapping from X509 Cert name constraints to the endpoints and hypervisors etc...
18:12:34 <gyee> we are having the same issue with tripleO with cert provisioning
18:12:53 <dolphm> thursday will be 100% identity then
18:13:06 <gyee> we been told no self-signed certs, but we need a realistic solution, so I am pushing certmonger
18:13:10 <morganfainberg> dolphm, thats a good thing imo
18:13:21 <morganfainberg> dolphm, keeps general focus
18:13:23 <jamielennox> dolphm: do you know if it's possible to reword the session description now it's in?
18:13:34 <dolphm> morganfainberg: ++ and friday is sort of post-auth stuff
18:13:41 <dolphm> authorization & service catalog
18:14:05 <dolphm> err thursday
18:14:10 <ayoung> gyee, do you guys have an API for submitting and retrieving a Cert to a  CA separate from the Dogtog one?
18:14:30 <dolphm> no i was right, the 16th is friday :P
18:14:33 <ayoung> If not...we can drive that in Barbican.  I think they have a BP for it already
18:14:51 <gyee> ayoung, no, we don't have an agreed approach right now, that's the problem
18:14:57 <gyee> agreed upon
18:15:53 <gyee> ayoung, I am fine with Barbican, so as long as it is consistent
18:16:05 <ayoung> gyee, I'll be prepped to demo certmonger stuff, and we can discuss the wider CA story there.  Barbican as a CA front works for me.
18:16:27 <morganfainberg> ayoung, ++
18:16:28 <gyee> ayoung, ++
18:16:29 <ayoung> And certmonger<->Baribican makes sense
18:17:06 <nkinder> ayoung: agreed
18:17:11 <dolphm> (assuming no one sees any further scheduling conflicts -- if any arise, ping me ASAP so we can try to resolve them)
18:17:26 <joesavak> thanks dolphm!
18:17:30 <dolphm> #topic Open discussion following improv and interpretive dance by stevemar
18:17:31 <dolphm> stevemar: o/
18:17:35 <ayoung> gyee, also, I think we'll need to driver the cryptography.py work for CMS, which means accepting a 509, and verifying a signature.  That will help both Keystone Client verification as well as the Messaging verification
18:17:51 <dstanek> go stevemar go
18:18:06 <stevemar> i've prepared a table flip
18:18:10 <stevemar> (╯°□°）╯ ┻━┻)
18:18:15 <stevemar> thats all i got
18:18:15 <dolphm> rofl
18:18:16 <gyee> heh
18:18:24 <morganfainberg> Nice.
18:18:26 <ayoung> ヽ(^o^)丿
18:18:45 <joesavak> lol
18:18:48 <dstanek> lol
18:18:50 <morganfainberg> ┬─┬ ノ( ^_^ノ)
18:18:52 <stevemar> serves me right for questioning the agenda
18:18:54 <ayoung> (~_~)
18:19:23 <dolphm> stevemar: damn straight
18:19:36 <dolphm> #link https://review.openstack.org/#/c/71181/
18:19:50 <ayoung> Review compressed tokens.  Please!
18:20:02 <gyee> on it
18:20:40 <ayoung> Compressed tokens will lead to being able to extract the singer info from the token prior to verification, and thus fetching the certs, allowing for multiple providers.
18:22:12 <ayoung> Oh...also, anyone have any real resistance to an addition to the mapping API that says "just pass through the groups as is, don't require an explicit enumeration of them?"
18:22:45 <ayoung> *allowing* explicit enumeration is a good thing, but requiring it leads to duplication of effort for places that don't want or need it.
18:22:50 <morganfainberg> ayoung, do we have the bug/bp to get testing of the examples handy?
18:23:12 <ayoung> morganfainberg, you mean PKI signed tokens?
18:23:27 <ayoung> compressed rather?
18:23:32 <bknudson> ayoung: https://review.openstack.org/#/c/90472/ has a -2 on it but there's no suggestion what to do differently.
18:23:50 <morganfainberg> ayoung, was that one where we wanted to test the example scripts?
18:24:23 <ayoung> bknudson, if the "server" switches from PKI to uuid tokens, the existing tokens that were revoked are still in memcache
18:24:25 <morganfainberg> ayoung, i know we had ~2-3 reviews we wanted to test the example scripts.
18:24:30 <dolphm> ayoung: why is this only Partial-Bug: 1255321 rather than Closes-Bug?
18:24:37 <ayoung> and they went from revoked to unrevoked
18:25:06 <ayoung> yeah, I need to resplit the example scripts...on my list for this week
18:25:59 <morganfainberg> ayoung, ah just want to tag related reviews for tracking on that bug/bp if possible :) that way we can say "no no we're planning on implementing tests" and see what we need to incorporate. that way we don't miss something
18:26:07 <stevemar> but we still don't have anything that tests the example scripts?
18:26:10 <ayoung> dolphm, hmm...good question
18:26:31 <bknudson> ayoung: seems like auth_token always worked that way -- cached tokens aren't checked if they're revoked
18:26:39 <ayoung> that bug is a Server bug, and it needs this patch in order to issue signed tokens
18:26:50 <morganfainberg> stevemar, the plan is to work on that specifically in Juno, tag it to J1 or such so we have a timeline but not require it before.
18:26:56 <morganfainberg> stevemar, that way it's on the radar we have a timeline, but we don't block work
18:27:21 <morganfainberg> and yes, i'll commit to getting that work done if we get down to the wire on it
18:27:52 <morganfainberg> but hopefully i can convince everyone to collaborate on it vs. just waiting till it gets done at the last minute
18:28:18 <ayoung> dolphm, so the client patch is partial, and the Compressed PKI provider would be the other half.  I have not yet written it, as it won't pass check until the client is avaialb3e.  It is a simple one line difference from the current PKI provider
18:28:58 <ayoung> bknudson, you are correct, but we have a patch going through right now that is attempting to rectify that:  let me see if I can find the link
18:29:09 <gyee> bknudson, ayoung, didn't we have the same discussion last week about the other patch which does the same thing?
18:29:24 <ayoung> gyee, heh, yeah
18:29:28 <ayoung> from the other side
18:29:45 <bknudson> gyee: right, that patch merged and now uuid-only setup fails... because there's no revocation list
18:30:27 <bknudson> ayoung: could you post the keystone server changes for compressed tokens so I can try it/
18:30:28 <gyee> bknudson, I thought that patch is token format independent
18:30:34 <ayoung> bknudson, wilco
18:30:50 <bknudson> gyee: I thought it was too
18:30:54 <stevemar> ayoung, i like the idea of supporting a bunch of group names in mapping, but probably needs to be thought out a bit more, perfect for a side session in the dev lounge
18:31:04 <ayoung> stevemar, ++
18:31:22 <bknudson> gyee: but if you use uuid tokens you probably didn't pki_setup, so auth_token can't get the revocation list
18:31:36 <ayoung> stevemar, I think we can do ity without an API change, actually, just a change on the enforcement of the rules processing
18:31:41 <gyee> bknudson, ahhhh! I remember now
18:31:51 <bknudson> gyee: and with the change we check UUID tokens against the revocation list
18:31:59 <gyee> there's also a bug about requiring PKI setup even though token format is set to UUID
18:32:12 <stevemar> ayoung, agreed, it might just open a discussion about how to handle domains, and we should get others opinion on that too
18:32:20 <stevemar> s/might/will
18:32:23 <ayoung> bknudson, I('m OK with that.  Lets make it as painful as possible for people to stay on UUID tokens!   But seriously...I wonder what the right logic is?  Maybe check_revocations needs to be configurable.
18:32:24 <bknudson> gyee: so my proposed fix is to allow auth_token to fail to fetch the revocation list
18:32:31 <gyee> stevemar, you mean hierarchical domains? :D
18:32:58 <dolphm> ayoung: it should be Closes-Bug in the client then, we'd track against keystone itself separately
18:33:07 <stevemar> gyee,  the old fashioned normal one
18:33:12 <ayoung> dolphm, that makes sense...I'll change
18:33:28 <stevemar> gyee, not those crazy new fangled hierarchical ones
18:33:51 <morganfainberg> ayoung, the bug should be filed against server and client if it needs to be tracked in both places.
18:34:09 <ayoung> morganfainberg, it is
18:34:14 <jamielennox> bknudson: i haven't been following - but that doesn't sound right - why would you need them to fail to fetch the list?
18:34:15 <ayoung> just listed as "affects"
18:34:20 <morganfainberg> ayoung, ah easy then
18:34:21 <morganfainberg> ayoung, yep see it
18:34:22 <jamielennox> bknudson: you can still revoke a UUID token
18:34:31 <gyee> stevemar, I am hungry for a hierarchical in-and-out burger, maybe I'll get one after the meeting
18:34:49 <bknudson> jamielennox: fetching the revocation list fails because there's no PKI certs.
18:35:20 <jamielennox> bknudson: why? all it should need is the CA cert from the server
18:35:47 <bknudson> jamielennox: the server doesn't have a CA cert... if you're using UUID tokens why do you need CA cert?
18:35:58 <bknudson> deployments didn't need it before this change.
18:36:31 <jamielennox> did we not allow UUID token revocations before this then? i was under the impression that we did
18:36:48 <gyee> jamielennox, for UUID, validation is over the network
18:36:57 <bknudson> jamielennox: we did allow it. But we never checked the revocation list for UUID tokens.
18:36:58 <jamielennox> gyee: but we would always allow cachig
18:37:16 <gyee> jamielennox, right, caching is a security tradeoff
18:37:25 <jamielennox> gyee: the revocation list was just a way to remove the UUID token from memcache before it expired
18:37:29 <gyee> security-performance tradeoff
18:38:06 <gyee> jamielennox, if we really want to do it right, have a lightweight process to listening on the events and update the cache accordingly
18:38:23 <dolphm> gyee: i think caching should be a given, but how long you cache for is the trade off!
18:38:36 <jamielennox> gyee: yea, you mentioned that and i've no idea how you architect it
18:38:51 <jamielennox> gyee: really we should have all the auth_tokens listening for notifications from keystone
18:38:54 <gyee> dolphm, absolutely! but that's a decision customer needs to make
18:39:05 <jamielennox> but you can't really do something like that in middleware
18:39:42 <dolphm> jamielennox: why not?
18:39:47 <gyee> jamielennox, what is caching for anyway, if what you wanted is real time validation
18:40:22 <dstanek> i'd be worried if we only listened for revocation events and didn't have a list or something to catchup the process (or validate that is has what it needs)
18:40:28 <jamielennox> dolphm: well it
18:40:43 <dolphm> dstanek: ++ the list is critical, which is why we started there
18:41:01 <jamielennox> dolphm: well it's python you can do almost anything - but would you need to spawn a subprocess or something? because you need a server that can respond to notifications and middleware can't do that
18:41:29 <jamielennox> gyee: i was just under the impression that we used to allow that - i guess we must never have
18:42:13 <dolphm> jamielennox: oh i didn't read "lightweight process" as "subprocess" - i just read that as message listener
18:42:35 <gyee> jamielennox, security and performance is one of those things that will need constant calibrations
18:42:43 <gyee> its not a one size fits all
18:43:05 <gyee> what we can offer is flexibility, really
18:43:10 <jamielennox> dolphm: right - but middleware is only triggered on an incoming request as a wrapper. if we wanted to actually have a listener then that would require a new thread of control that could sit and listen somehow
18:43:37 <bknudson> it could gobble up all the messages when it woke up
18:43:58 <gyee> bknudson, there's no wake up
18:44:07 <bknudson> and if it got too far behind then it'd get the full list
18:44:07 <jamielennox> gyee: there is - per request
18:44:21 <gyee> its a separate process which always listening on the revocation events
18:44:31 <bknudson> amqp?
18:44:44 <dolphm> jamielennox: you should be able to create a listening on __init__, no?
18:44:44 <jamielennox> bknudson: do the queue implementations support that - what if it's getting a request/day
18:44:47 <dolphm> listener*
18:45:04 <gyee> ampq doesn't support pushing?
18:45:13 <dstanek> if you register a callback from a notification won't that callback be executed as the notification arrives and not need a request?
18:45:14 <jamielennox> dolphm: sure - but it still needs to be a thread/subprocess
18:45:20 <gyee> or it is strictly a pull model
18:45:22 <gyee> ?
18:46:09 <jamielennox> dstanek: all this stuff is controlled by an event loop somewhere, we *could* try to get access to that from middleware but that's crossign boundaries
18:47:05 <bknudson> btw -- the way nova works with the default setup is that there's a separate in-memory cache for each "thread"
18:47:32 <dolphm> gyee: both/either
18:47:33 <bknudson> so one thread could have the token cached and it works and another doesn't have the token cached and it fails
18:48:08 <gyee> dolphm, both/either sounds good :-)
18:48:15 <jamielennox> bknudson: is nova handling this differently?
18:48:45 <gyee> bknudson, they have the *option* to use a distributed cache no?
18:48:49 <dolphm> jamielennox: i think he's just referring to auth_token's default in-memory token cache
18:48:58 <dolphm> there's nothing specific about nova in the example
18:49:07 <bknudson> gyee: I'm guessing if they use memcache they'd have consistent results.
18:49:41 <bknudson> memcache for token caching seems like overkill
18:49:57 <morganfainberg> bknudson, heh
18:50:05 <jamielennox> so, does anyone know how the other projects support integrating the HTTP listener event loop with the AMQP event loop?
18:50:12 <jamielennox> i haven't done that
18:50:34 <morganfainberg> jamielennox, not sure.
18:50:40 <jamielennox> does it 'just work' because of socket.select()?
18:50:54 <morganfainberg> jamielennox, it might "just work"
18:51:42 <jamielennox> because in that case we might be able to spawn a listener in __init__
18:51:51 <bknudson> what project would be listening for amqp events?
18:51:56 <dolphm> bknudson: auth_token
18:52:05 <jamielennox> although then we would have a listener per worker process which is not ideal
18:52:27 <jamielennox> bknudson: ceilometer is the main one i think
18:52:27 <gyee> jamielennox, make it configurable, per process or shared
18:52:59 <morganfainberg> jamielennox, the way the fan-out queues work that would be most correct if auth_token itself was meant to listen for that for a thread-local cache
18:53:21 <morganfainberg> jamielennox, /for a/with a
18:53:27 <ayoung> bknudson, make revocation checking a configurable option is, I think the only solution.
18:53:42 <ayoung> And, no, we are not spawing a separate thread for it.
18:53:53 <jamielennox> morganfainberg: yea because it will be a lot of extra work for a memcache setup to have every listener try to remove a token from the cache
18:53:59 <bknudson> ayoung: ok, I'll take a look at that as a solution
18:55:02 <ayoung> bknudson, the issue is that the server doesn't know if the token format is PKI or UUID, and it doesn't know if it should be looking for revocation events.  With PKI, revocation (events or list) is a must have,  with UUID, it is a nice-to-have....but with caching, it really should be required
18:55:04 <morganfainberg> jamielennox, depending on the number of workers
18:55:06 <bknudson> ayoung: I might have an option to check revocation list for UUID tokens?
18:55:20 <ayoung> bknudson, there is no way to distinguish
18:55:35 <ayoung> it might have been issued as PKI, but thne the MD5/SHA256 submitted as the token itself
18:55:37 <morganfainberg> 5 minutes
18:55:58 <ayoung> it will be treated as a Keystone lookup....but by the time it gets put in memcahced, that detail is forgotten
18:56:00 <dolphm> morganfainberg: 2?
18:56:08 <bknudson> ayoung: if auth_token gets a MD5 hash of PKI token it typically goes to the server
18:56:28 <morganfainberg> dolphm, maybe the clock here is off then \
18:56:30 <dolphm> bknudson: why do you need the revocation list for UUID tokens?
18:56:36 <morganfainberg> dolphm, here = my computer
18:56:46 <dolphm> bknudson: you need to validate them online to populate headers anyway
18:56:50 <morganfainberg> dolphm, caching.
18:57:10 <morganfainberg> dolphm, if auth)_token is caching, you don't ask keystone for token validity
18:57:22 <dolphm> morganfainberg: because you already have, and trust that cached data for some duration
18:57:32 <dolphm> morganfainberg: what does that have to do with the revocation list?
18:57:38 <gyee> :-)
18:57:47 <dolphm> (time)
18:57:51 <morganfainberg> dolphm, you could use the revocation list to know if you should trust that token (uuid or not)
18:57:51 <bknudson> the revocation list is cached on a different schedule
18:58:00 <dolphm> #endmeeting