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