18:04:47 <heckj> #startmeeting keystone 18:04:47 <openstack> Meeting started Tue Oct 23 18:04:47 2012 UTC. The chair is heckj. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:04:48 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 18:04:49 <openstack> The meeting name has been set to 'keystone' 18:04:59 <heckj> hey boden! welcome all! 18:05:53 <ayoung> heckj, I did a little bit of damage^H^H^H modified the agenda a bit 18:06:09 <ayoung> http://wiki.openstack.org/Meetings/KeystoneMeeting 18:06:17 <heckj> Warning - I've got a viscious headcold, so operating at significantly less capacity than normal 18:06:22 <heckj> ayoung: word 18:07:32 <ayoung> viscous even 18:07:38 <heckj> yeah, yucky 18:07:41 <heckj> you were busy 18:08:03 <heckj> #topic high priority bugs 18:08:17 <heckj> https://review.openstack.org/#/c/14281/3 vs https://review.openstack.org/#/c/14208/ 18:08:23 <ayoung> So, to make sure everyone is aware, unit tests on checkins were failing due to an expired cert for the SSL tests 18:08:40 <ayoung> I was going through and rechecking all of the the ones that I knew of that failed due to that 18:09:03 <ayoung> heckj, yea, I thought those were the same ticket dual submitted 18:09:13 <ayoung> looks like you distinguished between them 18:09:19 <heckj> there was a pile of those backing on the SSL certs 18:09:31 <ayoung> "please reset after https://review.openstack.org/#/c/14208/ has been approved and applied" 18:09:43 <ayoung> comment on 14281 18:09:51 <ayoung> but on 14208 18:10:25 <ayoung> This seems the same as https://review.openstack.org/#/c/14281/3 18:11:00 <ayoung> dolphm, ^^any comments? 18:11:29 <heckj> they functionally solve the same issue - I was leaning towards Dolph's patch, but mostly because I saw it first 18:11:43 <ayoung> I think it is a duplicate patch submission 18:12:23 <ayoung> just one has a unit test. Pick one to go in. 18:12:24 <gyee> maybe its too late for this, but I am not sure about this "if not ..." checks 18:12:39 <gyee> why don't we do the schema check in one place? 18:12:44 <heckj> dolph had a comment on 14281 wanting a change to the message, and 14281 had useful additional tests, so I'd like both in place 18:13:08 <ayoung> gyee, what do you mean? 18:13:31 <gyee> I understand dolph have the json schema 18:13:53 <gyee> we can check the json request against the schema for any missing parts 18:14:46 <gyee> rather than having these "if not ..." all over the place 18:15:08 <heckj> gyee: good point - but significantly deeper than this patch. If it covers all the back-use cases as well, I think that would be a great patch 18:15:41 <gyee> much cleaner to have schema check in one place 18:15:53 <heckj> gyee: agreed, without a doubt 18:15:55 <ayoung> gyee, +1 Care to open a ticket for that? 18:16:01 <gyee> sure 18:16:19 <heckj> actually, a blueprint would be more appropriate - please open a BP for it 18:16:26 <heckj> (rather than a bug) 18:16:32 <heckj> Thierry keeps yelling at me... 18:16:44 <gyee> ok :) 18:17:09 <heckj> ayoung: any qualms with approving https://review.openstack.org/#/c/14208/ and then requesting Alvaro to rebase on latest and get in the tests on https://review.openstack.org/#/c/14281 18:17:52 <ayoung> heckj, none 18:17:54 <ayoung> will do 18:18:13 <heckj> Okay - next topic: moving auth_token into keystoneclient 18:18:21 <heckj> https://bugs.launchpad.net/keystone/+bug/1039567 18:18:23 <uvirtbot> Launchpad bug 1039567 in keystone "auth_token middleware should be stand alone" [High,Triaged] 18:18:53 <gyee> +0 18:18:55 <heckj> we've got it prioritized high, and the impact will be changes to everyone's "paste" file as a part of the upgrade process to this 18:19:31 <heckj> It will resolve the issue of wanting auth_token middleware packaged separately, albiet at the cost of changing the namespace (which looked to be happening anyway) 18:19:50 <heckj> ayoung: anything else on that? 18:19:53 <ayoung> heckj, agreed. Think we need to get moving on this. Who is going to take it. 18:19:58 <ayoung> ? 18:20:43 <heckj> ayoung: you're most familiar with the signing code. gyee? henrynash? any interest in jumping into assist with some of this - very well constrained. 18:20:51 <henrynash> I'd be happy to take it 18:21:01 <henrynash> good thing to start with 18:21:02 <ayoung> henrynash, thanks 18:21:14 <ayoung> It is moving into Keystone Client 18:21:31 <ayoung> and then the paste files for each of the projects need to be modified 18:21:40 <ayoung> lots of juggling 18:21:57 <henrynash> ok, I'll study and one back if I have questions :-) 18:22:07 <ayoung> heckj, how do we reassign bugs? 18:22:11 <heckj> henrynash - what's your launchpad ID? I'll assign it over. Also, will hook you up with dtroyer, who can help review any changes to devstack to verify the switchover as we do that dance. 18:22:32 <henrynash> henry-nash (I think) 18:22:40 <gyee> ayoung, paste file, you mean like nova api-paste.conf? 18:22:46 <ayoung> gyee, yes 18:22:47 <gyee> what about devstack etc 18:22:55 <heckj> gyee: that will need updating as well 18:23:39 <gyee> I wonder if we can setup a pointer/reference in Keystone 18:23:45 <heckj> the general two-step for this process is to replicate all the relevant code into keystoneclient, then update devstack to use keystoneclient, then submit patches to all the remaining projects to update their same paste.ini files 18:23:59 <ayoung> this will need to be done in stages, keeping the exisiting setups working so devstack passes, and eventually removing the file keystone/middleware/auth_token.py as a last step 18:24:06 <heckj> At the tail end, pull out the code from keystone when nothing is referencing it 18:24:16 <heckj> yep 18:24:19 <henrynash> ok, yep 18:24:22 <ayoung> Probably should create a ticket for each of the other projects 18:24:38 <ayoung> Lets get the keystoneclient piece working first 18:25:10 <ayoung> once that change has been made, I will queue up the work on PKI that allows other services to sign tokens 18:25:19 <ayoung> to keep too many hands from changing the same code 18:25:50 <ayoung> actually, until the keystoneclient changes, lets have a moritorium on all changes to auth_token 18:25:51 <heckj> henrynash: don't hesitate to holler if things get tricky or you get stuc in process somewhere 18:26:14 <henrynash> will do, not known for being shy... 18:26:42 <heckj> ayoung: good idea on lockdown on auth_token, concider that enabled - core will keep an eye and pause any changes heading in there 18:26:50 <heckj> #topic https://review.openstack.org/#/c/14167/ Should go before PKI Default gets rechecked 18:27:23 <heckj> ayoung: I think this just needs reviews, but thank you for the head's up on prior to PKI changover 18:27:51 <ayoung> heckj, are you OK with approving https://review.openstack.org/#/c/14167/ ? 18:28:03 <heckj> ayoung - yeah, based on prior - will do now 18:28:13 <ayoung> I can do a follow on for any documentation 18:28:26 <heckj> approved and rolling in now 18:28:49 <heckj> also available for backport to folsom stable 18:29:23 <gyee> why do we need issue time if id is unique? 18:29:37 <ayoung> gyee, ID is not unique 18:29:55 <gyee> no? 18:29:56 <ayoung> in PKI tokens, SQL ID is the hash of the signed CMS message 18:30:19 <gyee> ah 18:30:20 <ayoung> So issue-revoke-reissue could have an identical body. 18:30:38 <gyee> so salted hash :) 18:30:55 <heckj> request for reviews: https://review.openstack.org/#/c/14328/ <-- please review 18:30:59 <ayoung> with issue time, it makes sure the body is different for each one. Since time out is 1 minute. 18:32:04 <ayoung> heckj, should really be dolphm on 14328 since he objected. I think his points were covered, but would prefer him to say himself. 18:32:18 <ayoung> Maybe if I keep referring to dolphm the screen beeps will attract his attention 18:32:51 <boden> as noted in the agenda -- I have a REMOTE_USER change which is waiting for 14328 so would be nice to see that one resolved 18:32:53 <heckj> dolphm: please review https://review.openstack.org/#/c/14328/ 18:33:18 <ayoung> boden, you can do the following 18:33:34 <ayoung> git fetch https://ayoung@review.openstack.org/openstack/keystone refs/changes/28/14328/2 && git checkout FETCH_HEAD 18:33:53 <ayoung> then, in your branch, cherry pick that commit 18:34:35 <ayoung> and rebase -i so it is in front of your change. Then, when you submit your patch, it should show "depends on https://review.openstack.org/#/c/14328/" 18:35:48 <boden> ayoung - fair enough.. git n00b here so was hoping to not get into extensive workflows for this one, even though I need to learn them I have limited bandwidth right now 18:36:31 <heckj> boden: yeah, the other option is to just wait, but that puts the wait and check burden on you 18:36:46 <heckj> #topic Overview of Sessions/Decisions from Summit 18:37:02 <ayoung> heckj, not really an option, as he needs to work up some unit tests, and that can be done up front. Waiting will delay. 18:37:09 <ayoung> heckj, ah decisions! 18:37:15 <heckj> heh 18:37:15 <boden> ayoung -- unti tests are done 18:37:22 <ayoung> boden, rock on! 18:37:38 <ayoung> so one decision that I think people will find interesting is from multi factor 18:37:46 <heckj> ayoung has been anxiously awaiting those tests 18:38:08 <ayoung> we will start encoding what form of authN was used to generate the token 18:38:31 <ayoung> so to do multi factor, submit for one token, then use that token to get another, and the authN set grows 18:39:08 <ayoung> I think it is an elegant solution, and then it puts the onus on the policy writers to consume that 18:39:35 <heckj> ayoung: resolved to leaving it to end services to validate multi-factor based on the authN annotations? 18:39:51 <heckj> Or is there an expected auth_token middleware update to count for 2+ assertions, etc. 18:39:58 <ayoung> heckj, possibly, but could even be on the authenticate method in Keystone 18:40:01 <heckj> (or variation on that theme) 18:40:17 <ayoung> heckj, I think first step is getting the mechanism in 18:40:26 <ayoung> second is figureing out how people want it enforced. 18:40:41 <heckj> mechanism = adding assertions onto token with AuthN usage 18:40:50 <ayoung> I could see an argument that you don't want to hand out tenant-scoped tokens until all the multi-factor rules are met 18:40:50 <heckj> sounds good - I'm with that 18:41:24 <heckj> seems like my dream of killing unscoped tokens is dying away :-) 18:41:40 <gyee> s/dream/nightmare/ 18:41:40 <ayoung> heckj, no, they are just getting renamed to "starting tokens" 18:41:51 <heckj> david's point of assertions on the tokens is a good one though 18:42:04 <ayoung> heckj, we need them to make sure we reimplement *all* of Kerberos in Keystone 18:42:05 <gyee> ayoung, is mechanism going to baked into the token string? 18:42:14 <ayoung> gyee, I don't think so 18:42:31 <gyee> in token access? 18:43:10 <ayoung> mechanism is probably going to be a swappable function, with the default being "get starting token with user Id an password, and use that to get tenant/endpoint scoped tokens.: 18:43:12 <ayoung> " 18:44:27 <ayoung> gyee, authenticate has been in desperate need for a refactor for some time. Maybe as part of this effort, we'll break it apart into a series of rules that we can then mix and match. Separate functions, and some way of saying "rules apply in this order" 18:44:50 <gyee> I was thinking PAM/JAAS style 18:45:14 <gyee> abstracting authentication and token validation, like like driver/manager backend 18:45:16 <ayoung> gyee, that would tie in with the Pluggable Auth Blueprint, too 18:45:18 <heckj> gyee: what's PAM/JAAS? 18:45:29 <ayoung> heckj, a typo. He meant Pajamas 18:45:35 <gyee> ha 18:45:45 <ayoung> heckj, PAM is Unit 18:45:46 <ayoung> Unix 18:45:50 <ayoung> JAAS is Java 18:45:52 <gyee> PAM = Pluggable Authentication Module 18:45:54 <gyee> I think 18:45:57 <heckj> yep, ok 18:46:00 <ayoung> Java Authentication and Authorization Services 18:46:09 <ayoung> in both case, pluggable modules registered with the system 18:46:18 <ayoung> in the case of PAM, in /etc/pam.d 18:46:25 <gyee> right 18:46:33 <ayoung> JAAS is in A JDK specific location. 18:46:39 * heckj updated the blueprint https://blueprints.launchpad.net/keystone/+spec/multi-factor-authn with some of the above detail on plan of attack 18:47:08 <gyee> I was going to do it as part of generic access key authentication 18:48:04 <gyee> I can take another crack at it if you guys want 18:48:33 <ayoung> gyee, yeah. Make sure you get boden's change in there 18:48:58 <heckj> sounds good 18:49:01 <ayoung> http://fpaste.org/UvUH/ is the heart of the Java security configuration from my system 18:49:11 <ayoung> from /usr/lib/jvm/java-1.7.0-openjdk.x86_64/jre/lib/security/java.security 18:49:43 <ayoung> bascially says, try each of these classes in order. Then, something like Tomcat can modify when authenticating. 18:49:56 <gyee> ayoung, sorry I miss the first part, which one is boden's change? 18:50:02 <ayoung> gyee, REMOTE_USER 18:50:15 <ayoung> that is going to be one of the auth mechanisms allowed. 18:50:24 <gyee> which review? 18:50:32 <boden> ayee -- its not submitted for review yet, but its ready to go including unit tests.. I'm waiting on https://review.openstack.org/#/c/14328/ 18:50:45 <gyee> ok thanks 18:51:26 <ayoung> http://www.fpaste.org/fd2a/ 18:51:28 <ayoung> that is from 18:52:04 <ayoung> gyee, I'd say the PAM format is probably the clearer of the two 18:52:20 <gyee> yeah, that should give us authn 18:52:53 <heckj> gyee: assigned you to the blueprint https://blueprints.launchpad.net/keystone/+spec/pluggable-identity-authentication-handlers, which I think covers this work (boden, you wrote it up, so correct me if I'm wrong) 18:52:58 <ayoung> gyee, I would really like it if the default configuration was in Python code, for debugging/clarity, with the overload being specified in something like paste 18:53:18 <gyee> ayoung, everything will be in Python 18:53:21 <gyee> I promise 18:53:37 <ayoung> gyee, I would also allow for configuration in paste 18:53:56 <ayoung> there are places where they can't change python code, but they can edit config files 18:54:26 <ayoung> 5 minutes lefrt 18:54:28 <ayoung> left 18:54:47 <ayoung> OK other decisions from summit 18:55:04 <gyee> resource collections 18:55:07 <gyee> aka, groups 18:55:14 <ayoung> we are going to indicate on a token which user signed it. Then, the X509 certs will be associated with a user 18:55:15 <gyee> bout time 18:55:41 <ayoung> heh 18:55:53 <henrynash> so on groups….are we aiming at something more broad, or just UserGroups? 18:56:01 <ayoung> this will provide enough info to someone that is trying to validate a token as far as who signed the token 18:56:31 <henrynash> ayoung: sorry, finish your topic first 18:56:32 <gyee> henrynash, we can start with user groups, then expend it if needed 18:57:00 <heckj> the user groups have a very clear and immediate use case, and make a good first-step starting point there 18:57:11 <gyee> I agree 18:57:26 <henrynash> agreed. I suggest i put together a bp for disussion 18:57:31 <ayoung> once we have Id of "who signed" we can distribute the load of signing tokens 18:58:03 <gyee> ayoung, +1 on signer identifier 18:58:04 <ayoung> so in the cases where user auth's to Horizon 18:58:13 <ayoung> the horizon user will sign the starting tokens 18:58:18 <heckj> whcih means it'll be dependent on getting the signing code into keystoneclient to allow that client code to sign? 18:58:26 <dolphm> (sorry i completely missed the meeting -- i'm catching up) 18:58:27 <ayoung> heckj, yes 18:58:54 <ayoung> heckj, that is my intent, I'll wait until I am just modifying client code before making any changes 18:59:31 <heckj> ayoung: sounds good - we'll want to marry that with a convience method in policy to react to that information to allow policy files to be crafter to support it 19:00:11 <ayoung> heckj, yes, and may need to indicate it in the set of signing credentials, too 19:00:54 <heckj> henrynash: definitely +1 to putting together a blueprint for usergroups 19:01:10 <gyee> henrynash, I can help as well 19:01:19 <heckj> excellent! 19:01:27 <ayoung> dolphm we were trying to untangle a few reviews due to cross communication etc. One for you is https://review.openstack.org/#/c/14328/ 19:01:57 <heckj> Going to wrap this so CI can have the room 19:01:58 <ayoung> Since you had the -1 comments before, we felt is fair to wait for you to say it was OK to submit 19:02:04 <heckj> #endmeeting