18:00:20 <dolphm> #startmeeting keystone 18:00:21 <openstack> Meeting started Tue Jul 16 18:00:20 2013 UTC. The chair is dolphm. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:00:22 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 18:00:25 <openstack> The meeting name has been set to 'keystone' 18:00:28 <gyee> \o 18:00:31 <henrynash> hi there 18:00:33 <lbragstad> Hey 18:00:37 <jamielennox> hello 18:00:38 <bknudson> hi 18:00:48 <dolphm> #topic Havana-m2 milestone-proposed 18:00:52 <spzala> Hi 18:00:57 <dolphm> is being cut today! 18:01:06 <ayoung> coolness 18:01:27 <gyee> today = end of day today? :) 18:01:30 <henrynash> are we all closed off for submissions? 18:01:36 <dolphm> henrynash: not yet 18:01:40 <henrynash> :-) 18:01:42 <dolphm> gyee: yes 18:01:44 <ayoung> dolphm, I take it that means token binding is definitely not going to make it? 18:01:46 <dolphm> i count 3 non-low bp's yet to be completed 18:01:47 <gyee> nice 18:02:02 <dolphm> ayoung: very doubtful 18:02:16 <jamielennox> damn 18:02:34 <gyee> code review day today 18:02:46 <henrynash> dolphm: so os-inherit is pretty much done, I think, I just code the sqlte migration working in the last 5 mins 18:03:02 <bknudson> I thought we didn't support sqlite migration 18:03:16 <ayoung> bknudson, we need to support for the time being 18:03:24 <henrynash> PITA 18:03:26 <dolphm> ayoung: pluggable remote user probably can 18:03:33 <dolphm> henrynash: awesome 18:03:41 <dolphm> bknudson: there's been more discussion on list 18:04:07 <ayoung> dolphm, so is there any real reason to avoid bind, or is it more a case of "this needs more scruitiny than we can pay it now"? 18:04:19 <dolphm> henrynash: morganfainberg has a -1 for you - is that addressed in your latest patch? (i assume you haven't submitted yet) 18:04:41 <ayoung> dolphm, bind is important enough to get jamielennox out of bed for this meeting. He is in Australia 18:04:43 <topol_> Hi 18:04:45 <ayoung> its like 4 am there or something 18:04:50 <henrynash> I think his only major point was on "list_projects_for_domain" which I have removed now anyway 18:05:58 <dolphm> ayoung: where is the bp? 18:06:02 <gyee> we can make some serious money out of the bind token stuff because it is highly deployment specific :) 18:06:13 <gyee> consulting money I mean 18:06:20 <dolphm> greeeeeaaat 18:06:31 <ayoung> #link https://blueprints.launchpad.net/keystone/+spec/authentication-tied-to-token 18:06:52 <ayoung> gyee, not really, but if it makes you feel better to think so 18:07:05 <ayoung> really, for Kerberos it is tied to principal, X509 it is tied to fingerprint 18:08:40 <ayoung> we can come up with more in the future, but I suspect we really only will use those two. Maybe SAML... 18:08:41 <gyee> hell yeah 18:08:41 <bknudson> ayoung: my question on auth tied to token is how do UUID tokens work? 18:08:41 <ayoung> jamielennox, can you rebase it 18:08:41 <ayoung> bknudson, no change 18:08:41 <ayoung> bknudson, the uuid tokens will also be bound 18:08:42 <jamielennox> ayoung, yep just doing that now 18:08:50 <ayoung> just, the remote system will have to go to keystone to get the bind data 18:09:04 <bknudson> when you call HEAD xxx how does it know that the token has bind requirements? 18:09:07 <jamielennox> bknudson, uuid tokens are retrieved from the server anyway so the bind information is just included in that 18:09:18 <dolphm> bknudson: ++ 18:09:19 <ayoung> bknudson, you won't. 18:09:32 <ayoung> bknudson, enforcement is a client side requirement. 18:09:33 <bknudson> so how can tokens be validated properly? 18:09:42 <ayoung> client will have a graduated approach to validation 18:09:53 <ayoung> we can't enforce the bind right out of the box 18:09:56 <bknudson> so now you do GET tokens/xxx to validate a token? 18:10:08 <ayoung> bknudson, yes. Or use PKI 18:10:15 <morganfainberg> hi sorry, little late. here now. 18:10:19 <ayoung> bknudson, things that do HEAD are tied to it being a bearer token. 18:10:32 <ayoung> bknudson, we need the mechanism in place to start changing that. 18:10:38 <ayoung> It is going to be a journey. 18:10:50 <ayoung> THe etherpad describes the expected enfrocement levels: 18:11:17 <gyee> ayoung, you can easily enforce bind in a customized token provider 18:11:56 <ayoung> gyee, bind needs to be enforced client side. We can add the bind data in a customized token provider, but it will take some reworking of the code 18:11:57 <gyee> just have Apache populate the header the same way it populates REMOTE_USer 18:12:12 <ayoung> gyee, for a HEAD call? 18:12:20 <gyee> any call 18:12:25 <jamielennox> bknudson, auth_token_middleware does a GET because it needs to retrieve roles etc 18:12:48 <bknudson> jamielennox: that makes sense 18:13:02 <bknudson> so it'll also get the bind stuff? 18:13:07 <jamielennox> yep 18:13:33 <jamielennox> so UUID vs PKI is a GET vs a decrypt but the token format is the same 18:13:43 <ayoung> +1 18:14:57 <ayoung> so does this sounds like a reasonable approach for H2? 18:15:17 <ayoung> V2 is in gate, tghen plugabble remote, then token binding? 18:15:17 <topol> when the python based decryption gets efficient it will really payoff :-) 18:15:27 <ayoung> henry's patch can go in at anypoint 18:16:31 <ayoung> gyee, v2 is once again at the head of the queue.... 18:16:45 <gyee> ayoung, looks like jenkins is holding it up? 18:17:04 <ayoung> dolphm, so, any firm objection to token binding ? 18:17:48 <dolphm> ayoung: no, just that the other 3 bp's have priority in my headspace 18:18:10 <dolphm> fabiog: are you rebasing https://review.openstack.org/#/c/33188/ ? 18:18:12 <topol> is the binding mandatory or optional? 18:18:20 <ayoung> topol, optional 18:18:30 <fabiog> dolphm, I am. 18:19:00 <fabiog> dolphm, I need to check where the context is now stored in the new code 18:19:02 <ayoung> topol, enforcement is laid out in the https://etherpad.openstack.org/link-authentication-tokens lines 70+ 18:19:05 <topol> ayoung, even for PKI tokens it is optional, correct? 18:19:13 <fabiog> I will check with gyee 18:19:16 <dolphm> gyee: any help for fabiog ^? 18:19:26 <jamielennox> topol, yes it will be always be optional by default 18:19:29 <gyee> dolphm, yeah, I'll work with him 18:19:56 <jamielennox> well it will be enforced if both sides know what to do about it by default otherwise it will be ignored 18:20:18 <jamielennox> so it will roll out with no impact 18:20:28 <ayoung> jamielennox, people will always be able to request an unbound token, just , in the future some service will be configured not to accept them. Right? 18:20:38 <gyee> its only enforceable with Apache front-end anyway 18:20:45 <ayoung> gyee, true 18:20:52 <bknudson> gyee: why couldn't I write middleware to set it? 18:21:01 <jamielennox> gyee, right you've really got to go out of your way to turn it on 18:21:10 <gyee> bknudson, see if you can get that kerberos principal from middleware :) 18:21:17 <topol> ayoung, so are you going to implement the x509 stuff by calling out from python to commandline operations? 18:21:23 <ayoung> bknudson, because Kerberos and Client Side certs should not be implemented in Pythion for sanity reasons 18:21:32 <topol> like you do for PKI? 18:21:34 <morganfainberg> topol: isn't that how we do it now w/ PKI signing? 18:21:35 <gyee> *sanity* 18:21:39 <ayoung> topol, yep 18:22:12 <gyee> ayoung, unless some smart guy figure out how to do it with Nginx :) 18:22:13 <ayoung> topol, we might be able to get the cert fingerprint from the web server, in which case we can do it with out a shell out, but shell out is always an option 18:22:22 <topol> K, any ETA on when python will have more efficient crypto libraries???? 18:22:37 <ayoung> topol, I have someone working on that, NSS based 18:22:55 <ayoung> icehouse timeframe, maybe earlier as an extension 18:22:58 <topol> K, excellent. 18:23:12 <dolphm> topol: whats the deficiency? 18:23:23 <topol> dolphm, performance 18:24:24 <brich1> ayoung: which of the crypto packages will pick up the NSS support? 18:24:36 <topol> and also the consumability pain of whether it is the gnu crypto or openssl crypto and those not being compatible with eachother 18:24:47 <ayoung> dolphm, crypto is really a python binding thing. The algorithms really are CPU intensive, and thus should be in native code. For correctness reasons, too. Python bindings need to release the GIL. But with eventlet,because the crypto is so long, it really should give up the CPU from time to time...not gonna happen, though 18:25:05 <ayoung> briancline, python-nss to start with 18:25:12 <gyee> what happen to m2crypto? 18:25:21 <morganfainberg> gyee: defuncty 18:25:25 <morganfainberg> no one is maintaining it 18:26:04 <gyee> m2crypto was basically c binding over openssl 18:26:20 <ayoung> lets stay on target. 18:26:24 <topol> morganfainberg, aren't you worried about the provenance of the crypto you will be relying on? 18:26:43 <topol> sorry, off target 18:26:54 <ayoung> for now, we'll havea potnetial soltuin using the Popen appraoch for crypto, which seems to be the right approach for eventlet 18:27:02 <gyee> ayoung, no objection with bind token from me 18:27:48 <jamielennox> the problem with the binding is it can't be done completely from a pluggable remote_user provider because it has to change the token format 18:28:09 <gyee> huh? 18:28:16 <gyee> token provider? 18:28:20 <ayoung> gyee, remote_user provider, not token provider 18:28:23 <ayoung> external 18:28:24 <jamielennox> so if it misses h2 the only way would be to essentially fork v3 token provider to add just a couple of bind lines 18:28:49 <ayoung> gyee, we really need a hook in the standard token provider for people to add custom data prior to the token signing 18:29:10 <gyee> ayoung, you can easily do that in token provider 18:29:13 <jamielennox> ayoung, maybe. do we want to allow custom data in the token? 18:29:14 <topol> ayoung +1 18:29:47 <gyee> that's what token provider is for, allows you to customize token data 18:29:50 <simo> jamielennox: not really a fan of cutom data in there 18:29:53 <ayoung> jamielennox, well, extension data is custom data if it is not core. 18:30:07 <simo> jamielennox: but then future-proofing is also good 18:30:14 <gyee> role mapping, federation, bind data, whatever 18:30:18 <ayoung> and bind should be core, but if it isn't... 18:30:55 <bknudson> since bind is optional and no clients are supporting it then I don't see why it needs to be core. 18:31:00 <ayoung> so, I think the short of it will be we either get binding in core, or we have to put some hooks into the default token provider 18:31:14 <ayoung> bknudson, optional but standardized 18:31:17 <gyee> ayoung, what hook? 18:31:32 <ayoung> and it needs to be in core in order for clients to be able to consume it in an expected manner 18:31:54 <ayoung> gyee, add bind data to the token, before signing 18:32:05 <jamielennox> gyee, if it doesn't become core then the approach would be to have a custom remote_user provider 18:32:10 <gyee> ayoung, you *can* do that today 18:32:29 <jamielennox> but they don't have access to the token itself, just a yes/no on auth 18:32:46 <gyee> token provider formats token data and signs it 18:33:07 <ayoung> gyee, right, and we need bind data in there before signing. Easier to do in the default provider 18:33:25 <gyee> ayoung, catch me after the meeting and I'll show you 18:33:43 <jamielennox> creating a new token provider for this is massive overkill, it wants to be at least a new remote_user 18:33:50 <dolphm> if PKI was an extension then the token could be signed in the response pipeline after other extensions have had their chance to modify the token 18:34:43 <ayoung> dolphm, yeah, agreed that the token production process can be more of an assembly, with signing being the last step of the pipeline. THat might be a good Icehouse architecture 18:34:54 <topol> whats the use case? Is thatw ell documented somewhere? 18:35:00 <gyee> jamielennox, since this is a *optional* feature, new token provider make sense 18:35:19 <ayoung> gyee, no, it is not an optional feature, it is an optional piece of a token 18:35:30 <jamielennox> gyee, the new token provider would be c&p v3 token with about +7 lines that would have to be kept in sync 18:35:37 <ayoung> if anyone in the system needs it, it has to be there in the registered token provider 18:35:56 <topol> jamielennox, do you have a use case or stakeholder for this? 18:36:25 <gyee> ayoung, jamielennox, I would think this is deployment-specific 18:36:37 <gyee> if I am not running Apache, no need to have this extra data right? 18:36:38 <ayoung> #link https://review.openstack.org/#/c/35093/13/keystone/token/providers/uuid.py 18:37:45 <ayoung> gyee, this is a step by step improvement on the way Keystone secures operations. Yes, it will require additional changes to be used. But if it isn ot there, those changes will be impossible 18:37:48 <jamielennox> topol, the point is to remove bearer tokens, there has been plenty of requests and the idea has been generally approved. 18:38:13 <topol> jamielennox, thanks for helping me to connect the dots! 18:38:56 <gyee> ayoung, all I am saying is we can and should make it configurable 18:39:13 <ayoung> If we delay binding this release, people will wait until icehouse is out before working to integate with binding tokens. We've seen how long PKI tokens have taken to get integrated into the process. 18:39:19 <jamielennox> gyee if you're not using apache then there is no extra data, the 'bind' element is not included in the token if there is no bind information 18:39:35 <jamielennox> so if it's off then there is no change to the token format at all 18:39:42 <ayoung> gyee, it is additional data that is only added if the original token request asks for it. 18:40:02 <topol> why can't a hook be provided now that allows this extension to be fully added later? 18:40:30 <gyee> topol, the hook is already there, we are debating whether it should be configurable 18:40:43 <dolphm> token provider merged 18:41:00 <ayoung> dolphm, wow, I just checked seconds ago 18:41:08 <jamielennox> gyee, the hook for modifying tokens isn't there 18:41:18 <morganfainberg> gyee: i think that since it is optional in the request, it doesn't require extra configuration options 18:42:05 <gyee> jamielennox, just extend uuid provider and V3TokenDataHelper 18:42:07 <jamielennox> also because keystone doesn't use keystoneclient we can't authenticate a bind unless we start hooking the token auth process as well 18:42:15 <topol> Unless you know now what configuration options you will need, shouldnt you just defer the configuration piece? 18:42:48 <ayoung> topol, we don't need configuration on the server side. Just on the client side, and that is not up for review. Client goes on its own schedule 18:44:33 <topol> ayoung, are we getting to the point where the client needs to be on the same schedule as the server? Who controls that? 18:44:49 <jamielennox> ayoung, mostly there is some server side config for enforcement which was copied from client side and there is the config to turn binding on 18:45:14 <ayoung> jamielennox, for enforcement? 18:45:46 <ayoung> topol, no, I think the client needs to lead the server, and then the server needs to always rely on the latest version of the client. 18:46:00 <jamielennox> ayoung, telling keystone how to deal with tokens it receives with bind information. disable, enforce etc 18:46:14 <ayoung> dolphm gets to say when we release a new verision of the client, usually on a month by month basis, right? 18:46:58 <dolphm> henrynash: can you revise the comment in etc/keystone.conf.sample ? 18:47:13 <dolphm> henrynash: it looks like you copy/pasted from the trust one which is inaccurate for os-inherit 18:47:14 <gyee> dolphm, you have a PO Box for folks to send money to in case they need the client faster? :) 18:47:22 <henrynash> dolphmL oops…! :-) 18:47:28 <dolphm> ayoung: as needed 18:47:29 <henrynash> dolphm: will do 18:47:30 <morganfainberg> gyee: lol 18:47:34 <dolphm> ayoung: do we need to do a release? 18:47:51 <ayoung> dolphm, not yet, not for this. 18:48:06 <ayoung> dolphm, just explaining. 18:48:18 <topol> seems like the current situation my need tighter release synchronization to get things right 18:48:18 <dolphm> ayoung: just poke me anytime 18:48:41 <dolphm> henrynash: also grep for 'inerit' 18:48:50 <bknudson> clients will either get bind in the token or not get bind 18:48:58 <bknudson> and they'll either use it or not use it 18:49:03 <henrynash> dolphm: yep, I can't seem to type that right :-) 18:49:12 <ayoung> bknudson, yep 18:49:33 <ayoung> bknudson, and we want this in as an enabling feature. Other projects need to build on it. 18:49:37 <bknudson> I assume the client just ignores bind if it gets it in a token now 18:49:46 <ayoung> Which is really the reason we are doing feature freeze in H2 18:49:51 <morganfainberg> ayoung: the client throws out unknown data right? e.g. current one sees a bind, it would be ignored? 18:49:58 <ayoung> morganfainberg, correct 18:50:02 <jamielennox> bknudson, yes - it'd just be random extra data 18:50:19 <dolphm> whoa, what did i push to get this modal thing going on? http://i.imgur.com/O1Af1kf.png 18:50:27 <ayoung> but we can update the client prior to H3 and allow a service to be able to use it. So it really should be in H2 18:50:31 <morganfainberg> then i see no problems with the way it's released now. server supports everything, we shore up client to match. etc. etc etc. or even vice-versa 18:50:56 <morganfainberg> dolphm: where did you click to see that? 18:51:09 <dolphm> morganfainberg: that's what i want to know 18:51:10 <topol> dolphm, doesnt it go away if you move the cursor? I saw that too 18:51:43 <bknudson> dolphm: probably f 18:51:55 <morganfainberg> dolphm: "f" 18:52:45 <morganfainberg> ayoung: +1 on that timeline. 18:53:31 <ayoung> reviews for bind API https://review.openstack.org/#/c/36166/ and server imp https://review.openstack.org/#/c/35093/ 18:53:39 <ayoung> please lets get this in today 18:54:09 <ayoung> plugable remote is probably ready to go: 18:54:13 <ayoung> #link https://review.openstack.org/#/c/36839/6 18:54:28 <ayoung> #link https://review.openstack.org/#/c/36166/ 18:54:38 <morganfainberg> oh, i meantt o look that pluggable remote one over this morning. 18:55:32 <topol> ayoung, I will review today 18:55:44 <ayoung> gyee, you are right, plugable is breaking backwards compat. I will fix that. 18:56:38 <gyee> ayoung, I am good with the bind token spec, will push a patch for the remote user plugin to show my angle 18:57:16 <ayoung> gyee, sounds good. 18:57:57 <dolphm> gyee: ayoung: how is backwards compat broken? 18:58:08 <ayoung> gyee, so external won't be specified in the token request, but instead we will look for the plugin labled "external" in the set of registered plugins? 18:58:25 <gyee> ayoung, yes 18:58:26 <ayoung> dolphm, I turned realm into domain name 18:58:39 <ayoung> dolphm, that is the "right" solution, but not what is currently implemented 18:58:41 <gyee> dolphm, the current impl doesn't allow explicit scope 18:58:56 <topol> ayoung, you will document that, correct? 18:58:57 <ayoung> dolphm, so I will make it so the default provider does what is now, and leave the other logic as an alternative provider 18:59:15 <ayoung> topol, yes, 18:59:16 <dolphm> ayoung: ah, that's exactly what i was just looking at. cool. 19:00:04 <dolphm> happy code reviewing! 19:00:05 <dolphm> #endmeeting