20:00:07 <r1chardj0n3s> #startmeeting keystone_horizon
20:00:08 <openstack> Meeting started Thu Dec  1 20:00:07 2016 UTC and is due to finish in 60 minutes.  The chair is r1chardj0n3s. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:00:09 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
20:00:12 <openstack> The meeting name has been set to 'keystone_horizon'
20:00:34 <r1chardj0n3s> stevemar: I'm always open to suggestions how to better run things!
20:00:36 <jamielennox> o/
20:01:06 <r1chardj0n3s> #link https://etherpad.openstack.org/p/ocata-keystone-horizon is our current list of issues
20:01:10 <david-lyle_> o/
20:01:49 <stevemar> what are we starting with first? :)
20:02:05 <r1chardj0n3s> looks like rderose has an update for Proper Domain-admin support
20:02:18 <r1chardj0n3s> "still in WIP"
20:02:51 <rderose> o/
20:03:04 <stevemar> i think the initial bug goes beyond the limitations imposed by a federated user
20:03:37 <r1chardj0n3s> (otherwise doesn't look like a lot of updates in the issues etherpad)
20:04:08 <rderose> yep, still in WIP, but once done, all federated users will belong to a real domain
20:04:35 <r1chardj0n3s> so, who has a topic they'd like to discuss?
20:04:50 <stevemar> r1chardj0n3s: we have edtubill and crinkle around, they're both working on bugs
20:05:00 <crinkle> o/
20:05:04 <stevemar> pick on one of them :P
20:05:09 <r1chardj0n3s> crinkle, what're you working on?
20:05:12 <rderose> also, I'd like to quickly discuss PCI
20:05:21 <stevemar> rderose: get in line!
20:05:23 <r1chardj0n3s> rderose: ack
20:05:38 <crinkle> https://review.openstack.org/#/c/389679/ and https://review.openstack.org/#/c/389337/ could use keystone and horizon eyes
20:06:15 <crinkle> i don't have an update beyond that
20:06:40 <stevemar> crinkle: so https://review.openstack.org/#/c/389679/ seems like an issue from when we moved to the bootstrap command?
20:07:29 <crinkle> stevemar: no, it's that different parts of the code were using a config setting as either an ID or a name
20:07:54 <stevemar> crinkle: hmm, yeah.. "OPENSTACK_KEYSTONE_DEFAULT_DOMAIN" isn't very clear is it
20:08:43 <stevemar> "NOTE: This value must be the name of the default domain, NOT the ID"
20:09:13 <stevemar> isn't that backwards incompatible?
20:09:20 <stevemar> this: https://review.openstack.org/#/c/389679/4/openstack_dashboard/local/local_settings.py.example
20:09:21 <stevemar> ?
20:09:57 <crinkle> no because it was a bug, if you were using it the way it was documented it wasn't working
20:10:05 <david-lyle> stevemar: the comment was incorrect before
20:10:08 <knikolla> o/
20:10:11 <david-lyle> we expect a name
20:10:12 <stevemar> ah okay
20:10:23 <david-lyle> because that's the only way the login form makes sense
20:10:23 <stevemar> david-lyle: so what's the hold up on getting this merged? :)
20:10:31 <stevemar> david-lyle: true
20:10:38 <david-lyle> crappy reviewer
20:10:45 * david-lyle points at self
20:10:52 <crinkle> :)
20:10:59 <r1chardj0n3s> that patch hasn't hit the mandatory 69-day minimum delay for Horizon reviews yet :/
20:11:16 <stevemar> r1chardj0n3s: team review in the meeting :P
20:11:24 <stevemar> ship it!
20:11:29 <r1chardj0n3s> :-)
20:11:33 <lbragstad> aaaand break!
20:11:42 <stevemar> (i am only half joking)
20:12:15 <r1chardj0n3s> stevemar: and I am intrigued by the idea!
20:12:35 <stevemar> okay, crinkle also has https://review.openstack.org/#/c/389337/ up
20:12:50 <crinkle> slightly more involved
20:13:17 <stevemar> crinkle: this was a bug you noticed when playing around with federation / sso?
20:13:24 <crinkle> stevemar: yes
20:13:39 <crinkle> this could use someone from keystone saying "yep that's how that API works" or "no that's not how it's supposed to work at all"
20:13:52 <david-lyle> just to reverify, the list_domains call will work with an unscoped token in the federation case?
20:14:19 <crinkle> david-lyle: yes, and only in the federation case
20:14:52 <stevemar> david-lyle: yes, that is correct i believe... http://developer.openstack.org/api-ref/identity/v3-ext/index.html?expanded=list-domains-a-federated-user-can-access-detail#list-domains-a-federated-user-can-access
20:15:48 <david-lyle> and that's not guarded by policy?
20:16:03 <knikolla> says deprecated
20:16:08 <jamielennox> that one only works in the federation case, but we replaced it with a general purpose api a while ago
20:16:22 <rderose> jamielennox: ++
20:16:35 <david-lyle> but that one is guarded to "admin" only?
20:16:44 <david-lyle> oh wait it's auth
20:16:46 <jamielennox> listing /v3/auth/projects or /v3/auth/domains should tell you the projects/domains a user has access to, regardless of federated/regular login
20:17:00 <jamielennox> checking on client equivalent...
20:17:12 <stevemar> jamielennox: right, those are the new APIs /auth/project not the one i pointed out (old ones)
20:17:29 <jamielennox> v3.Client.auth.projects
20:17:33 <jamielennox> v3.client.auth.domains
20:17:41 <lbragstad> yeah - i thought we deprecated the OS-FEDERATED apis a while ago
20:17:43 <crinkle> jamielennox: could you comment on the review and I'll fix it?
20:17:57 <stevemar> david-lyle: so why don't we check what domains a user has access to, in addition to projects?
20:17:57 <jamielennox> not all, but we deprecated those
20:18:24 <david-lyle> wasn't accessible when I wrote the original implementation
20:19:03 <stevemar> i suppose we can put that as a follow-on if someone wanted it
20:19:11 <david-lyle> but I'm not sure dumping into an arbitrary domain is ideal
20:19:13 <stevemar> but this is decently isolated
20:19:18 <lbragstad> jamielennox ah - yes... specifically the apis for getting domains and projects for federated users
20:20:29 <stevemar> crinkle: commented
20:20:36 <crinkle> thanks
20:20:43 <stevemar> david-lyle: r1chardj0n3s y'all good with this once crinkle updates?
20:21:00 <crinkle> david-lyle | but I'm not sure dumping into an arbitrary domain is ideal
20:21:08 <r1chardj0n3s> crinkle: also, as a matter of procedure, could you please link those to a bug to aid our tracking backports?
20:21:31 <stevemar> r1chardj0n3s: ++
20:21:32 <crinkle> r1chardj0n3s: okay
20:21:45 <r1chardj0n3s> thanks
20:21:59 <david-lyle> in the federation case, will there be more than 1 domain?
20:22:20 <stevemar> david-lyle: possible?
20:22:29 <rderose> david-lyle: federated users will belong to only a single domain
20:22:38 <rderose> different domain, different user
20:23:04 <david-lyle> because we're shadowing the users?
20:23:05 <stevemar> rderose: belong to != have access to
20:23:51 <david-lyle> horizon doesn't have a switch to change domains
20:23:56 <stevemar> oh no?
20:24:02 <stevemar> thats a bummer
20:24:11 <stevemar> is/was there a reason why?
20:24:11 <david-lyle> so if we dump into the first of possibly many then they can never get to the other
20:24:29 <rderose> david-lyle: yeah, because we're shadowing federated users, they are like any other keystone user and will have to belong to a single domain.
20:24:41 <david-lyle> until your newer API domain list was guarded to be "admin" only by the policy file
20:25:01 <david-lyle> so there was no point adding it
20:25:08 <stevemar> i see what you mean
20:25:12 <david-lyle> this all went into the Havana release, btw
20:25:22 <david-lyle> so it has some gray hair now
20:25:33 <stevemar> might be worth adding it since we have /auth/domains now
20:25:42 <stevemar> anywho, getting off topic for this specific change/bug
20:25:55 <r1chardj0n3s> good discussion tho, I think :-)
20:26:05 <stevemar> yep
20:26:09 <david-lyle> right, the method to switch would go into doa, but the actual user interface would be in Horizon
20:26:12 <stevemar> edtubill: still around?
20:26:20 <edtubill> stevemar: yeah
20:26:26 <edtubill> I can talk about k2k federation for horizon: david-lyle approved the new k2k dropdown blueprint. I am currently writing some patches, I'll push them out for review soon.
20:26:28 <stevemar> dammit, stupid call starting soon
20:26:29 <david-lyle> stevemar, I'm not sure it's off topic
20:26:52 <david-lyle> because the unnavigable domain issue above, based on the current patch
20:27:35 <crinkle> is it worth the effort to make domains navigable or is it usually expected that all users have projects and this doesn't need to be fixed?
20:27:55 <david-lyle> something is better than nothing I suppose, but adding the switch method to forms.py would be a good piece for this patch as well
20:28:01 <stevemar> david-lyle: okay, maybe crinkle's assumption that a federation setup result in a domain admin isn't a good one?
20:28:33 <crinkle> david-lyle: okay i can work on that
20:28:38 <stevemar> david-lyle: so it'll be like the project switcher?
20:28:44 <david-lyle> stevemar: yes
20:28:51 <stevemar> thanks for volunteering to do the work crinkle
20:28:58 <crinkle> ofc
20:29:14 <david-lyle> then once it's merged in doa and released we can put a user control in horizon
20:29:24 <stevemar> david-lyle crinkle okay, let's let crinkle tinker around for now, she can come back with an update next week?
20:29:39 <david-lyle> sounds good
20:29:43 <stevemar> a domain switcher would be all kinds of useful, i think
20:30:06 <david-lyle> yes, didn't realize we had gained access to the list for the user
20:30:16 <stevemar> has to dial into a call, will be half paying attention :(
20:30:37 <r1chardj0n3s> so edtubill, any issues or will we await the patches?
20:30:42 <stevemar> oh wait, meeting at 4!
20:30:44 <stevemar> yay!
20:30:48 <r1chardj0n3s> \o/ stevemar
20:30:58 <stevemar> \o/
20:31:14 <stevemar> david-lyle: edtubill: so what was actually decided?
20:31:15 <edtubill> No issues so far
20:31:42 <r1chardj0n3s> #link https://blueprints.launchpad.net/horizon/+spec/k2k-horizon this blueprint
20:32:30 <edtubill> And also I will make the 'K2K at login time' work with the new blueprint as well.
20:32:43 <stevemar> edtubill: so it'll be a drop down next to projects (and the new domains drop down ;)) ?
20:32:52 <david-lyle> edtubill: make that a separate bp
20:33:09 <david-lyle> stevemar: that's the current bp yes
20:33:13 <stevemar> david-lyle: cool
20:33:14 <edtubill> david-lyle: ok I'll make that a seperate bp for 'k2k at login time'
20:33:22 <stevemar> david-lyle: how is the list of SPs selected?
20:33:27 <stevemar> edtubill: ^
20:33:40 <edtubill> It's taken from the access info object for a scoped token.
20:33:43 <david-lyle> for the current bp, or the latter
20:34:15 <stevemar> david-lyle: i guess on login time it's a set of config options? and once logged in, from the token?
20:34:35 <david-lyle> the latter will require another hardcoded list unless keystone has an open call to obtain it, or we go to a two step login process, which I'm not excited about
20:35:20 <edtubill> stevemar: So the user logs in and gets to see the list of available sps in a dropdown. The blueprint is different from the 'k2k at login time'. It gets it dynamically from the token and not the config file.
20:35:32 <stevemar> so it sounds like both are on the table right now?
20:35:52 <stevemar> is there a reason we are not deciding one over the other?
20:36:01 <stevemar> or is it -- we can do both, so why not?
20:36:15 <david-lyle> hardcoded lists are bad
20:36:25 <stevemar> (sorry for all the questions, i think i've missed a few meetings :( )
20:36:59 <david-lyle> and my thoughts were the selector once logged in was cleaner and useful, but did not bar the login case
20:37:15 <david-lyle> I'm not excited about how we have to do the login case at this point
20:38:06 <stevemar> david-lyle: okay, sounds like since both can happily co-exist, we let them co-exist?
20:38:37 <edtubill> I am for having them co-exist incase someone wants them both.
20:38:47 <edtubill> But prioritize the drop down blueprint more.
20:38:56 <david-lyle> I think so, but I'm open to other opinions
20:39:03 <stevemar> i'm trying to get a firm decision on what will be accepted by the team, so we don't make edtubill go back and forth
20:39:05 <stevemar> :)
20:39:20 <stevemar> and if the decision is 'meh', that's cool too!
20:39:54 <stevemar> (we can move to another topic, i think i beat this horse to death)
20:39:56 <r1chardj0n3s> I'm deferring to people who know more about what's going on (hi, david-lyle)
20:40:02 <stevemar> hehe
20:40:11 <stevemar> david-lyle, pressure's on
20:40:11 <r1chardj0n3s> so, rderose, about about that PCI?
20:40:16 <david-lyle> I would think if you had other keystones that were cost inducing, you could use the current endpoint list on login page and let the user choose
20:40:23 <rderose> I've added a patch to support "PCI-DSS 8.2.6 Set passwords/passphrases for first-time use and upon reset to a unique value for each user, and change immediately after the first use"
20:40:29 <rderose> https://review.openstack.org/#/c/403916/
20:40:37 <rderose> So after first auth, the user's password will be set to expire and they will be required to change their password.
20:40:45 <rderose> 1) horizon gets token for user (first time after password reset)
20:40:45 <rderose> 2) horizon will inpsect the 'password_expires_at' attribute in the token
20:40:45 <rderose> 2a) if expired, show password dialog for user to change their password
20:41:37 <rderose> sound good?
20:41:53 <stevemar> lookin'
20:41:53 <rderose> questions?
20:42:08 <r1chardj0n3s> sounds good to me. we have some expiry interface work in progress, just not sure if we have the step 2) stuff covered yet