18:00:07 <dolphm> #startmeeting keystone
18:00:07 <openstack> Meeting started Tue May  6 18:00:07 2014 UTC and is due to finish in 60 minutes.  The chair is dolphm. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:00:09 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
18:00:11 <openstack> The meeting name has been set to 'keystone'
18:00:18 <henrynash> hey
18:00:21 <dolphm> #topic Reminder: there are two summit schedules
18:00:29 <stevemar> topol, nicely done!
18:00:38 <dolphm> as in HK, there are two sched.org schedules: one for the design summit and one for the main conference
18:00:49 <dolphm> #link http://junodesignsummit.sched.org/ design summit
18:00:56 <dolphm> #link http://openstacksummitmay2014atlanta.sched.org/ main conference
18:01:15 <bknudson> there's some security presentations on monday
18:01:32 <ayoung> dolphm, Do we have any coders from sched.org attending?  We need to get them to do the whole Hierarchical Multitenacy for Events
18:01:48 <dolphm> i recommend registering for sessions/events on each and then sync them both to your phone so you A) get updates B) can see conflicts
18:01:49 <morganfainberg> ayoung, lol
18:02:07 <ayoung> dolphm, when do you give the state of the Keystone Address?
18:02:20 <dolphm> ayoung: we don't do that anymore -- it's a web conference post-summit now
18:02:32 <stevemar> booo
18:02:37 <ayoung> http://openstacksummitmay2014atlanta.sched.org/event/4656993707ba7b22d5f8df0aaa246603#.U2kjtTkjPiU
18:02:44 <ayoung> Lets sit in there and Heckle, then
18:02:49 <topol> I would like a transcript of the state of keystone address
18:02:56 <dolphm> ayoung: unfortunately the icehouse one wasn't recorded (as i think i went first + technical difficulties)
18:03:02 <mfisch> where is the invite for the webconf announced?
18:03:20 <morganfainberg> topol, we also need to have the immediate rebuttle to the state of keystone address >.>
18:03:25 <morganfainberg> topol, i mean...
18:03:32 <bknudson> some of the summit meetings say FULL already
18:03:34 <dolphm> mfisch: good question... i recall it being on twitter.com/openstack, but i'm sure there was something more formal (operator list?)
18:03:46 <topol> yeah, how can they be FULL?
18:03:46 <mfisch> dolphm: ops list works for me
18:03:47 <ayoung> I'm just going to go the that one and sit on the stage
18:03:50 <marekd> o/
18:03:54 <dstanek> bknudson: ha, i didn't realize there was a capacity limit
18:04:00 <morganfainberg> bknudson, wow full?
18:04:08 <mfisch> a lot of the workshops have capacity limits
18:04:15 <lbragstad> bknudson: which one were you looking at?
18:04:23 <morganfainberg> dstanek, if past summits were any indicator... rooms will be overfull for some talks
18:04:25 <dolphm> for everyone here, the state of the union shouldn't be surprising, it'll be a summary of icehouse + what we talked about during the juno conference
18:04:26 <stevemar> lbragstad, there's a bunch
18:04:55 <dolphm> mfisch: ++
18:05:04 <stevemar> some even say 'filling'
18:05:10 <dstanek> if they are marked as full can you not add them to you schedule?
18:05:16 <bknudson> sign up and scalp tickets
18:05:19 <mfisch> I panic signed up for some last week, but I'm overbooked
18:05:22 <morganfainberg> bknudson, ++
18:05:22 <stevemar> bknudson, ++
18:05:25 <mfisch> will sell tickets for +2s
18:05:37 <morganfainberg> mfisch, oh thats downright dirty (i approve)
18:05:38 <dolphm> design summit sessions shouldn't have any capacity, beyond actually filing the room
18:05:46 <dolphm> so, first come, first heard
18:05:47 <stevemar> mfisch, you'd have better luck with beer
18:05:57 <dolphm> filling*
18:06:28 <topol> yeah, mfisch after you one gives you the +2 another one behind the scenes gives you a -2
18:06:32 <bknudson> "Take a Break with Red Hat" - FILLING
18:06:35 <bknudson> I could handle that one
18:06:37 <dolphm> rofl
18:06:51 <mfisch> thats where redhat gives you snacks in exchange for a resume I bet
18:06:57 <ayoung> Its ok,  this whole OpenStack thing is a flash in the pan.  All the cool kids are moving to CoreOS
18:07:14 <dolphm> sounds like a commercial break ;)
18:07:21 <ayoung> mfisch, Heh.  Maybe for you
18:07:32 <ayoung> Red Hat doesn't feed me.  Least, not that way
18:07:48 <dolphm> ayoung: they already have your resume
18:08:08 <dolphm> #topic Design summit scheduling conflicts?
18:08:24 <dolphm> just a reminder to poke me with any potential conflicts you find, today is basically the last day to resolve tehm
18:09:06 <ayoung> dolphm, I have yet to get someone hired here in Engineering.  Ops and Services, yes....the easy way of getting into RH Engineering is to build a Successful OpenSource Project and We'll  Acquire your company.
18:09:19 <dolphm> the only one i'm aware of, and will attempt to resolve, is that the federation design session conflicts with a federation-related topic from the main conference: http://junodesignsummit.sched.org/event/ab0966f5ec41f78e929effd499e0286f conflicts with http://openstacksummitmay2014atlanta.sched.org/event/11b6f75c349b0bffe204e3cb2880d4c0
18:10:16 <dolphm> that'll likely result in the federation design session moving to a later timeslot, although there aren't many options to do so
18:10:17 <stevemar> ah that mystery one
18:10:20 <morganfainberg> ah that would be good to resolve if possible
18:10:29 <marekd> morganfainberg: ++
18:10:57 <dolphm> i'd rather not swap it with another keystone session (so that we can attend the main conference session)
18:11:07 <dolphm> but that's my backup plan
18:11:19 <morganfainberg> dolphm, ++
18:11:33 <dolphm> anyway, if anyone finds anything else, speak up- thanks!
18:11:49 <dolphm> #topic Design summit etherpads
18:11:53 <dolphm> #link https://wiki.openstack.org/wiki/Summit/Juno/Etherpads#Keystone
18:12:24 <dolphm> I started preseeding the etherpads a bit, and linking them on sched.org
18:13:06 <dolphm> the only thing i'd *really* like to have before we get to atlanta, is one or two specific desired outcomes for each session so that we can stay on track while we're there :)
18:13:16 <stevemar> ++
18:13:51 <dolphm> a couple sessions are completely missing them, as the session descriptions were ... vague ... so i'd appreciate everyone's input here on what we'd like to accomplish in those topics
18:13:53 <stevemar> a rough outline, and desired outcomes are great things to put in the etherpads
18:13:54 <dolphm> #link https://etherpad.openstack.org/p/juno-keystone-client
18:13:59 <dolphm> #link https://etherpad.openstack.org/p/juno-keystone-authorization
18:14:24 <bknudson> keystoneclient and authorization are pretty broad topics to begin with
18:14:51 <stevemar> which is why the folks who propsed the session should help narrow it down :P
18:14:53 <jamielennox> we have a seperate authorization track to just normal client?
18:15:00 <dolphm> bknudson: stevemar: ++
18:15:48 <dolphm> jamielennox: authorization steps into token authz attributes, policy.json and oslo.policy land
18:16:23 <jamielennox> oh right, server side
18:17:20 <jamielennox> client is vague because while i've got a few things i'm hoping others to have topics as well
18:18:03 <dolphm> jamielennox: the "topics" you mentioned in the session description don't have clear justification or desired outcomes, though
18:18:03 <bknudson> I guess with the client I'm a little more interested in if the other projects are going to use it
18:18:13 <bknudson> rather than re-implementing everything
18:18:16 <dolphm> jamielennox: "Splitting middleware out from the client repo" - what's the challenge we need to overcome at the summit?
18:18:34 <dolphm> jamielennox: "Ideas for fixing auth_token middleware" what's wrong with it, exactly, that we need to solve?
18:18:36 <dolphm> etc
18:19:18 <dolphm> i'd like to have a desired outcome(s) for these, *and* revise the session description to be much more specific for both of these
18:19:37 <jamielennox> dolphm: yep, i definetly think we need to revise the description
18:19:43 <topol> dolphm, do we anywhere cover having a strategy to getting one of the integrated projects to adopt V3 APIs
18:20:01 <bknudson> heat is using v3 apis
18:20:11 <bknudson> e.g., trusts
18:20:16 <dolphm> topol: i have a bp filed specifically to document our approach to that -- i intend on focusing on it this week actually :)
18:20:37 <topol> bknudson, I was thinking more nova, cinder, glance
18:20:59 <topol> dolphm, sounds good
18:21:22 <dolphm> topol: the bottom line is that the work is on us to make it happen, but we need a roadmap defined for ourselves, and for our stakeholders to monitor
18:21:30 <bknudson> nova's got an issue where they accept a token and then start using it with neutron... but the token might have expired between when they accepted it and when they hand it off to neutron
18:21:36 <topol> dolphm, +++++
18:22:01 <jamielennox> topol: i consider that part of client's responsibility, whilst ever people have to do there own integration with different API versions it won't happen
18:22:13 <topol> we need to save cycles for making that happen
18:22:34 <bknudson> we should also have a target -- j2?
18:23:00 <topol> jamielennox, so its on us to make happen. Otherwise V3 APIs arent relevant. and not being relevant is a bad place to be
18:23:07 <jamielennox> having said that a large amount of what is actually required in terms of features are either implemented or in review, so there is work to be done but i don't know what is left in terms of discussion
18:23:19 <jamielennox> topol: absolutely - we are going to need to make the changes
18:23:32 <dolphm> bknudson: my personal goal is for the end of juno, but i like the ambition :)
18:23:46 <henrynash> yes
18:24:14 <dolphm> we could also replace one of these sessions with a v3 roadmap session
18:24:19 <topol> dolphm, ideally we could pair up a core from keystone with a core from the other projects to have a two in the box approach to insuring folks upgrade to V3
18:24:37 <dolphm> topol: i like that idea
18:25:33 <dstanek> topol: pairing is a good idea
18:26:01 <morganfainberg> topol, ++
18:26:54 <dolphm> s/Authorization/What it will take to kill Identity API v2/ ?
18:27:57 <morganfainberg> v2 auth isn't hard, it's the rest of v2... that's a pain
18:28:37 <henrynash> dolphm: maybe s/User IDs/Entity IDs/ ….since we are taling about user and group IDs
18:28:47 <ayoung> dolphm, first and foremost it will take:  https://review.openstack.org/#/c/90632/
18:28:51 <jamielennox> dolphm: again, generally a client issue so happy to take it, I just need to rewrite that description
18:29:07 <ayoung> we need to make it possible for people to use V3 APIs while stuck with V2.0 clients
18:29:26 <ayoung> other clients, that is
18:29:48 <dolphm> jamielennox: make that a desired outcome of the client session, you mean?
18:29:52 <henrynash> dolphm: or maybe just User/Group IDs
18:30:00 <dolphm> henrynash: "entity" is a bit vague, but happy to expand to user & group
18:30:14 <dolphm> henrynash: i wasn't thinking group id's because i had identity federation in mind
18:30:16 <henrynash> dolphm: ++
18:30:37 <ayoung> In federation, we need to let the groups be defined completely in the mapping layer, with nothing in identity
18:31:00 <jamielennox> dolphm: again, my issue here is that i would love the feedback but as far as i'm concerned most of the pieces for the transition are in place or in review
18:31:01 <stevemar> ayoung, you mean no existing groups in identity backend?
18:31:07 <marekd> ayoung: something like 'ephemeral' groups?
18:31:10 <ayoung> stevemar, yes, that is what I mean
18:31:19 <morganfainberg> ayoung, i agree
18:31:20 <morganfainberg> marekd, ++
18:31:29 <stevemar> ayoung, you want the groups created on the fly?
18:31:33 <ayoung> marekd yeah,  let the IdP manage the set of groups
18:31:34 <marekd> stevemar: yes
18:31:57 <morganfainberg> stevemar, group shouldn't need to be "Stored" in identity imo
18:32:05 <ayoung> stevemar, I don't want to have to define them in two places.  So if I have them in the IdP, I want to be able to use them from the IdP
18:32:08 <marekd> stevemar: ayoung: or rather fake groups that are just a bridge to the roles...
18:32:12 <ayoung> NO!
18:32:17 <ayoung> Nothing Fake
18:32:25 <ayoung> They are real, they just don't live in Keystone
18:32:31 <stevemar> morganfainberg, ayoung, i'm not understanding how authz could happen then?
18:32:38 <dolphm> jamielennox: we have a substantial amount of cross-project work to follow - i'd like to enumerate that too. plus, what we expect from deployers to make a transition
18:32:43 <ayoung> stevemar, role is still assigned based on Group Id
18:32:51 <stevemar> a role has to have a user|group and project|domain
18:32:53 <morganfainberg> stevemar, the same way as now, you just wouldn't have a group in identity backend.
18:32:56 <ayoung> you just don;'t confuirm that the group is in the identity backend a-priori
18:33:03 <ayoung> that is why there is no FK constrain there.
18:33:26 <jamielennox> dolphm: ok, i couldn't see any way to edit that summary, do i just have to send it to you?
18:33:45 <dolphm> jamielennox: oh sure - i have no idea what the options look like on your side at this point :(
18:34:09 <dolphm> jamielennox: i think it's all the same to me up until the conference, except after today it's
18:34:11 <dolphm> "pencils down"
18:34:16 <stevemar> morganfainberg, ayoung i suppose
18:34:19 <morganfainberg> stevemar, it's the same as a federated user, the ID doesn't get "stored" in the identity backend.
18:34:27 <henrynash> ayoung: we will still need to support groups in identity right…e.g. I’m ust using LDAP….just not for federation…unless, as we have discussed before, we make LDAP a subset of federation
18:34:43 <jamielennox> dolphm: alright, i'll fix something up soon and email/put it on etherpad and link it to you
18:34:47 <dolphm> jamielennox: danke
18:34:49 <ayoung> henrynash, done by the web server
18:34:49 <morganfainberg> henrynash, correct, though i'd like to see LDAP as a subset of federation
18:34:56 <ayoung> mod_lookup_identity
18:35:14 <ayoung> http://adam.younglogic.com/?p=3175&preview=true
18:35:31 <morganfainberg> ayoung, right there are other ways, but if we maintain a raw ldap connection, we woiuld still need groups in identity.
18:35:38 <morganfainberg> ayoung, similar to SQL backend.
18:35:55 <ayoung> morganfainberg, I said explicitly for Federation
18:36:02 <morganfainberg> ayoung, yeah.
18:36:04 <ayoung> LDAP Id Backend doesn't go away.
18:36:10 <henrynash> ayoung: assuming everyone is happy to use apache plugins for this…(no, don’t start that argument now)…’cause  I think that’s too strict an implementation requiremnet
18:36:12 <ayoung> http://adam.younglogic.com/2014/05/keystone-federation-via-mod_lookup_identity/
18:36:29 <dolphm> henrynash: (what's too strict, exactly?)
18:36:30 <ayoung> henrynash, "make it possible to"  not require
18:36:36 <morganfainberg> ayoung, ++
18:36:43 <bknudson> I don't think deployers really want an LDAP ID backend if they have federation
18:36:49 <morganfainberg> henrynash, more options = better. this is an alternative deployment.
18:36:50 <bknudson> they want to store their service users in sql
18:36:53 <ayoung> henrynash, I don't want to have to explicitly enumerate all of the groups if the Apache module populates them for me
18:37:05 <ayoung> bknudson, ++
18:37:08 <marekd> ayoung: ++
18:37:19 <morganfainberg> bknudson, somewhat, some of my users do want LDAP direct, but that is more of an edgecase than the norm
18:37:33 <morganfainberg> bknudson, i agree most cases federation supplants the need for LDAP
18:37:35 <henrynash> dolphm: that we make apache plugins the only way we can get certain key keystone fucntionality (e.g. groups for LDAP)
18:37:57 <ayoung> http://adam.younglogic.com/2014/05/mod_lookup_identity/  can use the ldap pam Module
18:38:05 <dolphm> bknudson: i agree in the long run, and would appreciate being corrected if anyone has an opposing use case :)
18:38:16 <bknudson> they don't have to be apache plugins, could also handle via keystone middleware
18:38:19 <dolphm> morganfainberg: (why?)
18:38:19 <topol> bknudson++
18:38:23 <morganfainberg> bknudson, ++
18:38:35 <morganfainberg> dolphm, because they are picky about how things interact with LDAP
18:38:48 <morganfainberg> dolphm, it's a silly edge case requirement
18:38:50 <ayoung> bknudson, for an example of that:  https://review.openstack.org/#/c/92137/
18:38:52 <dolphm> morganfainberg: so they don't want users authenticating with ldap or what?
18:38:59 <bknudson> if somebody was picky about interaction with LDAP they'd be surprised by how keystone works.
18:39:10 <dolphm> bknudson: plus plus
18:39:19 <morganfainberg> dolphm, i'll need to get more info on it and we're using some very odd hybrid backends
18:39:57 <ayoung> bknudson, we could take LDAP an make it into a middleware piece like the Basic_Auth one I just posted, and populate REMOTE_GROUPS  from there.
18:40:07 <stevemar> henrynash, i get your concern, i had planned to talk about the dependency at the summit
18:40:21 <morganfainberg> ayoung, middleware would be good if we wanted to support non-apache wsgi implementations
18:40:30 <ayoung> morganfainberg, ++
18:40:39 <topol> stevemar, how hard is it to get rid of that dependency?
18:41:10 <ayoung> I think that is the way to go, and then we can add or remove them from the pipeline, but Identity is an optional component.  We need a way to deal with domains  in the Basic_Auth case (that really is just an example one)
18:41:11 <stevemar> topol, not sure, we agreed on the dependency to get something up and running quickly
18:41:36 <topol> stevemar, makes sense
18:41:42 <stevemar> topol, it'll be different for the different federation protocols too
18:41:49 <morganfainberg> ayoung, exactly
18:42:28 <henrynash> ayoung: the thing is I see many customer who just want coroprate LDAP user/groups mapping…and then use keystone to add roles to those users and groups… I don;t see how we get that with a pipeline plug in
18:42:47 <ayoung> henrynash, that is exactly what you get
18:43:03 <morganfainberg> henrynash, if it provided the remote_user/group mechanism the apache module would have otherwise done, you get the same net effect, right?
18:43:40 <bknudson> we'd have REMOTE_USER and REMOTE_GROUPS?
18:44:02 <ayoung> henrynash, instead of doing a lookup against the backend, it used LDAP to populate REMOTE_USER and REMOTE_GROUPS.  Then  The Mapping backend (as per SAML plugin)  will convert those to the USER_ID and Groups for Keystone consumption
18:44:07 <ayoung> bknudson, yes
18:44:09 <bknudson> and roles map group names to roles instead of IDs?
18:44:20 <ayoung> groups only have ids
18:44:22 <henrynash> how do I have an keystone API that says “pick the group that I add a role to for a project”?
18:44:29 <ayoung> henrynash, you don't
18:44:36 <henrynash> i knew you would say that
18:44:41 <henrynash> :-)
18:44:51 <ayoung> henrynash, you can query them from LDAP
18:44:53 <marekd> ayoung: and how would you like to link groups from REMOTE_GROUPS with a set of roles?
18:45:04 <marekd> in the mapping rules?
18:45:32 <ayoung> mapping just converst REMOPTEE_GROUPS to Keystone groups.  The rest of the mechanism is the same, except you do not "confirm the group exists"
18:45:43 <henrynash> ayoung: ok, agreed….in that model we say there is no idenitty api as we know it today, you go to the “source”
18:45:59 <marekd> ah, so some local groups would have to exist apriori...
18:46:19 <bknudson> we'll have to change the project name from openstack identity to openstack assignment.
18:46:33 <ayoung> bknudson, ++
18:46:47 <dolphm> ayoung: how do you assign project/domain-based authorization to groups that don't exist?
18:47:48 <ayoung> dolphm, there are a couple ways we could address that.  Probably the most logical is that an assignement to a group requires that the user doing it has the group in their Assertion (SAML, LDAP whatever)
18:48:22 <ayoung> dolphm, is that really such a problem, though, if the groups are not enumeratable in Keystone?
18:48:38 <ayoung> the mappings are going to be set up by external users.  They know about their attributes
18:49:01 <ayoung> If they say "pass through the list of groups that the user has" so long as it is limited to a domain, let it pass.
18:49:24 <dolphm> ayoung: i don't care if their enumerable or not - if the user comes into keystone with groups that keystone has never seen before, they won't be authorized to do anything in the cloud, right?
18:49:32 <morganfainberg> ayoung, i think there might be some usability issues in that.
18:49:38 <ayoung> dolphm, correct.
18:49:50 <dolphm> ayoung: but you want the user to have authorization to grant themselves authorization?
18:49:54 <ayoung> dolphm, you would need to set up a role assignment before the group means anything
18:50:22 <ayoung> dolphm, no,  I was saying "if you need enumeration"
18:50:31 <ayoung> that was just one possible solution,. not the berst
18:50:31 <dolphm> ayoung: so the deployer needs to know about the groups they care about before the user authenticates?
18:50:32 <ayoung> best
18:50:33 <jamielennox> morganfainberg, ayoung: maybe not usability, but i'm trying to imagine the headache of getting keystone setup with all these mappings
18:50:56 <ayoung> Not "must"  just "may"
18:51:19 <morganfainberg> jamielennox, ooh we probably need to work w/ horizon folks to make a "friendly" way of defining mapping.s
18:51:20 <dolphm> ayoung: so you want to basically ignore "groups" that don't exist?
18:51:21 <bknudson> jamielennox: would be interesting to see an example mapping setup
18:51:45 <ayoung> If I have an LDAP server with 1000s of groups already defined, I don't want to have to copy each and everyone in to the Keystone Backend (assuming it will not be using direct LDAP, But Rather Federation)
18:52:03 <ayoung> dolphm, yes I want the option to ignore groups with no role assignments
18:52:31 <ayoung> morganfainberg, and of testing them....
18:52:35 <dolphm> ayoung: that seems like a trivial change relative to how federation is implemented today; why fuss with a radically different implementation to achieve that?
18:53:00 <ayoung> dolphm, I'm not suggesting a radical change.  Just that it is something we need to resolve and support.
18:53:06 <marekd> dolphm: ++
18:53:27 <ayoung> An option on the domain:  don't enumerate groups.
18:53:38 <dolphm> if CONF.federation.ignore_unrecognized_groups: discard_group(); else: raise Exception()
18:53:44 <ayoung> Or "don't confuirm group existinence when creating a role mapping"
18:53:58 <ayoung> dolphm, could be CONF, but probably makes more sense as an option on the domain
18:54:04 <ayoung> Or on the mapping
18:54:36 <dolphm> (3 minutes)
18:54:42 <ayoung> I could see a need for the current functionality for say, public cloud, and then Non-enumeration for a public cloud setup.
18:54:52 <ayoung> er, privateCLoud setup
18:54:59 <bknudson> before we're done I wanted to mention that it's pretty easy to try out the compressed token change --
18:55:00 <dolphm> ayoung: i'm lost on whether you're talking about ignoring groups during role assignment or after processing a federation mapping
18:55:07 <ayoung> bknudson, ++
18:55:08 <bknudson> just checkout the 2 commits and devstack
18:55:20 <ayoung> dolphm, both.
18:55:24 <ayoung> bknudson, and it worked OK?
18:55:31 <bknudson> ayoung: yes, it worked fine
18:55:38 <bknudson> and the tokens were obviously starting with PKIZ
18:55:41 <ayoung> One commit for Keystone, one commit for client, and devstack.
18:56:09 <ayoung> https://review.openstack.org/71181   https://review.openstack.org/91145
18:56:31 <ayoung> bknudson, BTW, that mechanism is what I am proposing as the basis for PKI usage in Oslo Messaging
18:56:44 <dolphm> ayoung: there's a patch for devstack?
18:56:51 <ayoung> dolphm, No.
18:56:54 <bknudson> it works with plain devstack
18:57:01 <dolphm> good
18:57:07 <dolphm> time-ish!
18:57:10 <ayoung> dolphm, I think he meant it worked with Devstack if you tell it "don't reclone"
18:57:18 <dolphm> ayoung: gotcha
18:57:29 <morganfainberg> ayoung, i think devstack doesn't reclone by default
18:57:45 <dolphm> #endmeeting