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