18:00:09 <stevemar> #startmeeting keystone
18:00:09 <openstack> Meeting started Tue Oct 18 18:00:09 2016 UTC and is due to finish in 60 minutes.  The chair is stevemar. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:00:09 <knikolla> o/
18:00:10 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
18:00:12 <openstack> The meeting name has been set to 'keystone'
18:00:15 <gagehugo> o/
18:00:16 <rderose> o/
18:00:19 <crinkle> o/
18:00:21 <dolphm> o/
18:00:24 <bknudson> hi
18:00:38 <lbragstad__> o/
18:00:42 <stevemar> hey bknudson crinkle gagehugo dolphm rderose lbragstad__
18:00:47 <stevemar> and knikolla :)
18:01:04 <stevemar> agenda is here: https://etherpad.openstack.org/p/keystone-weekly-meeting
18:01:05 <stevemar> #link https://etherpad.openstack.org/p/keystone-weekly-meeting
18:01:06 <jaugustine> o/
18:01:34 <stevemar> wait for any other late comers...
18:01:56 <stevemar> small crowd this week
18:02:05 <dolphm> stevemar: freenode seems to be having problems, so i'm not sure we should expect a normal attendance
18:02:12 <gagehugo> :/
18:02:18 <stevemar> dolphm: thanks for the heads up
18:02:21 <stevemar> #topic project update
18:02:28 <dolphm> and those that are here might drop randomly
18:02:34 <stevemar> summit design sessions are on the wiki: https://wiki.openstack.org/wiki/Design_Summit/Ocata/Etherpads#Keystone
18:02:35 <stevemar> #link https://wiki.openstack.org/wiki/Design_Summit/Ocata/Etherpads#Keystone
18:02:35 <breton> o/
18:02:49 <stevemar> also available to view online: https://www.openstack.org/summit/barcelona-2016/summit-schedule/global-search?t=Keystone%3A
18:02:52 <stevemar> #link https://www.openstack.org/summit/barcelona-2016/summit-schedule/global-search?t=Keystone%3A
18:03:06 <dstanek> o/
18:03:17 <stevemar> so last time i looked at the session, i swear the time changed (to an hour earlier)
18:03:24 <stevemar> so please look at the live schedule
18:03:49 <stevemar> looking forward to seeing folks next week!
18:03:55 <breton> why is there %3A in the end?
18:04:13 <dolphm> breton: for security?
18:04:16 <stevemar> breton: cause that's what came up in the address bar when i searched for it? :P
18:05:12 <breton> because of ":"
18:05:15 <stevemar> breton: oh, the %3A will make sure it searches for "Keystone:" and not just "Keystone" (which would bring up a lot of results)
18:06:00 <dolphm> if you take it off, you potentially get mentions of keystone in other tracks
18:06:07 <stevemar> the design sessions all have "keystone:"
18:06:13 <dolphm> more of a problem for Nova vs Nova:
18:06:46 <stevemar> any summit questions?
18:06:52 <dolphm> what's for tapas
18:06:57 <stevemar> design session or otherwise
18:06:59 <raildo> dolphm, ++
18:07:13 <stevemar> dolphm: whatever you decide on, you're the chef of the group
18:07:17 <dstanek> how will i ever get along without you guys?
18:07:35 <dolphm> stevemar: i should have planned ahead
18:07:40 <stevemar> dstanek: lbragstad__ will keep you company
18:07:54 * lbragstad__ highfives dstanek
18:08:07 <stevemar> rough timeline for ocata: https://releases.openstack.org/ocata/schedule.html
18:08:16 <stevemar> #link https://releases.openstack.org/ocata/schedule.html
18:08:39 <stevemar> we'll pick dates for the various proposal freezes and such next week
18:08:41 * dstanek is satisfied with that answer
18:08:48 <stevemar> but 17 November is the ocata-1 milestone window
18:08:58 <stevemar> so 3 weeks or so til ocata-1
18:09:27 <stevemar> nows the time to fix bugs and do big things (looking at you fernet as default)
18:09:39 <stevemar> so we have the rest of the cycle to handle the fall out
18:09:52 <lbragstad__> everything is ready for review
18:09:57 <lbragstad__> as far as making fernet the default
18:09:59 <stevemar> lbragstad__: ++
18:10:14 <stevemar> lbragstad__: was just an example, but thanks for the heads up
18:10:26 <stevemar> lastly -- PTG info: http://www.openstack.org/ptg
18:10:35 <stevemar> #link http://www.openstack.org/ptg
18:10:44 <stevemar> any questions about the pTG? i can try to answer them :\
18:10:48 <stevemar> 20-24 February 2017 in Atlanta, Georgia
18:10:58 <stevemar> it replaces the midcycle for us
18:11:05 <rderose> mid-cycle == ptg?
18:11:09 <rderose> :)
18:11:18 <stevemar> rderose: yeah, except its all devs
18:11:24 <knikolla> except it's start-cycle
18:11:30 <breton> Atlanta is far from Russia
18:11:39 <stevemar> so no more nova-specific and keystone-specific midcycles
18:11:42 * breton hopes there will be ptgs in europe
18:11:42 <stevemar> :(
18:12:00 <stevemar> breton: don't quote me, but i think there will be in the future
18:12:00 <bknudson> that's coming up quick
18:12:12 <dstanek> stevemar: oh, i thought those were replaceing all devs at summits
18:12:36 <stevemar> dstanek: i'm not sure, we'll all learn a lot after the first one
18:12:51 <dolphm> dstanek: we'll still have the "forum" which will have the traditional dev / ops / user intermix
18:13:11 <dolphm> i'm not super clear on how the forum will differ from previous summits though
18:13:35 <stevemar> i believe some of the active ops will also be at the PTGs
18:14:00 <dstanek> so still dev summit + new fangled thing? or we still don't know?
18:14:24 <dolphm> PTG + Forum
18:14:33 <dolphm> PTG = centralized midcycle
18:14:39 <dolphm> Forum ~= Summit
18:14:48 <dolphm> that's all i got
18:14:52 <stevemar> yep
18:15:28 <stevemar> whether the summit becomes less dev focused, and more marketing, i don't know yet
18:15:33 <stevemar> i don't believe that's the case though
18:15:33 <knikolla> still the downside is that PTG is at the start of the cycle.
18:15:58 <raildo> only ptg will be enough for decide anything to the whole cycle?
18:16:20 <knikolla> the way i see it, PTG == design summits.
18:16:30 <dolphm> stevemar: that is the case, sort of
18:16:42 <dolphm> with the shift in schedule, the forum will be further from a release
18:16:55 <dolphm> so that operators and users show up with feedback from the latest release
18:17:06 <dolphm> rather than "yeah, but we haven't had time to test it yet"
18:17:38 <stevemar> i'm being cautiously optimistic with the whole switch, it'll be harder for some folks to get funding for both, and the operators and kinda left out in the cold, but i trust the foundation knows what they are doing
18:17:49 <dolphm> PTL and TC election cycles are also being adjusted to occur at different times (i forget the details)
18:18:06 <stevemar> dolphm: right, PTL elections are coming up sooner this time around
18:18:16 <dolphm> Thierry has an [all] post on the mailing list about it IIRC
18:18:21 <stevemar> the transition stage is going to be weird
18:18:27 <dolphm> stevemar: ++
18:18:36 <stevemar> but the foundation will learn a lot and act quickly
18:18:59 <stevemar> so make sure you all submit travel requests for the PTG!
18:19:03 <dolphm> this also means we can expect to have a summer PTG somewhere
18:19:19 <stevemar> yes, unannounced but yes
18:19:22 <dstanek> i ready several of the posts about this, but i really just want the bullet points....most of the things i read spent too much time explaining the problem and justifying the solution
18:20:07 <stevemar> dstanek: poke ttx :P
18:20:12 <dolphm> so, Barcelona Summit (now) -> Atlanta PTG (Feb) -> Boston Forum (April) -> Unannounced PTG (summer) -> Sydney Forum (next oct/nov)
18:20:16 <knikolla> https://www.openstack.org/assets/Uploads/summit-ptg-timeline-revised.png
18:20:36 <stevemar> those were well timed messages
18:21:04 <samueldmq> dolphm: nice
18:21:04 <stevemar> i'm not sure if future "forums" will have design sessions
18:21:07 <dolphm> always with the infrographics
18:22:06 <stevemar> alrighty
18:22:13 <stevemar> on to the first real topic
18:22:15 <stevemar> #topic bug 1632924
18:22:18 <openstack> bug 1632924 in OpenStack Identity (keystone) "Lingering sql backend role assignments after deletion of ldap user." [Medium,Confirmed] https://launchpad.net/bugs/1632924
18:22:18 <stevemar> lbragstad__: ^
18:22:18 <samueldmq> So there will always be some time after the cycle
18:22:35 <samueldmq> Before the next fórum presenting it
18:22:44 <samueldmq> Oops sorry
18:22:45 <lbragstad__> alright i was doing some bug triage and stumbled across https://bugs.launchpad.net/keystone/+bug/1632924
18:22:56 <lbragstad__> I wasn't really sure how we should approach it
18:22:59 <bknudson> this is deleting ldap user through keystone?
18:23:09 <lbragstad__> so i left a comment promising to bring it up during the meeting
18:23:11 <lbragstad__> bknudson: ues
18:23:13 <lbragstad__> yes*
18:23:23 <bknudson> did we get rid of that code?
18:23:29 <knikolla> don't we not support that anymore?
18:23:31 <lbragstad__> bknudson: we are suppose to in Ocata
18:23:36 <stevemar> bknudson: not yet, it's WIP to be removed for this cycle
18:23:36 <knikolla> i'm getting rid of it
18:23:36 <lbragstad__> but we haven't yet
18:23:50 <bknudson> if something only exists in an old release we can fix the old release.
18:24:14 <lbragstad__> bknudson: we can do that with the backport policy?
18:24:14 <stevemar> lbragstad__: i say mark it as WONTFIX, we will not fix it in ocata, and it was deprecated in M/N, and on anything older than that we can't backport since it's not a security fix
18:24:26 <dolphm> bknudson: ++
18:24:27 <dolphm> lbragstad__: yes
18:24:32 <lbragstad__> got it
18:24:33 <lbragstad__> ok
18:24:43 <dolphm> lbragstad__: won't fix on master, but target the bug to previous series
18:24:46 <stevemar> bknudson: depends if this is even worth fixing for deprecated behaviour
18:24:52 <lbragstad__> that's the tricky part
18:24:56 <lbragstad__> it's a deprecated thing
18:25:08 <lbragstad__> do we support fixing deprecated things?
18:25:14 <dolphm> sure
18:25:18 <dolphm> we just don't add features
18:25:22 <bknudson> If someone shows up with a fix I don't think we should reject it.
18:25:27 <dolphm> i.e. adding a new command to v2 keystoneclient cli
18:25:28 <lbragstad__> ok
18:25:48 <stevemar> it's low impact, the worst thing that happens is lingering role assginments
18:25:59 <stevemar> i wouldn't mark this higher than a medium
18:26:17 <lbragstad__> the lingering role assignment are breaking some openstackclient calls they are making though
18:26:31 <stevemar> really? bah
18:26:37 <dolphm> still sounds like a medium :)
18:27:06 <bknudson> is it breaking deleting the role assignment?
18:27:12 <samueldmq> Also it shouldn't be a hard fix
18:27:49 <knikolla> is there a precedent for commiting fixes directly to stable branches without backport?
18:27:54 <samueldmq> Also it could have a migration that cleans up the existing table by comparing with the usr list
18:27:55 <stevemar> ohh actually this isn't related to write support for LDAP
18:28:09 <stevemar> i think the user was actually removed from the LDAP (by an admin)
18:28:11 <dolphm> knikolla: in this sort of scenario, yes
18:28:19 <stevemar> like the employee was terminated or something
18:28:33 <dolphm> knikolla: the patch will just be scrutinized more harshly for risk
18:28:35 <samueldmq> stevemar: lbragstad Said it was deleted by keystone
18:28:47 <stevemar> samueldmq: the bug report says different
18:28:48 <samueldmq> When someone asked a frw lines abobe
18:29:01 <lbragstad__> " The issue being encountered is when a ldap user is removed, the id for that user(actor_id) remains in the keystone.assignment table."
18:29:05 <stevemar> the resource or in this case the user id no longer being found as it was deleted from ldap
18:29:06 <lbragstad__> ^ from the bug report
18:29:14 <stevemar> it doesn't say how it was removed
18:29:32 <knikolla> this case does affect master though
18:29:44 <knikolla> if it's ldap deletion
18:29:51 <samueldmq> So perhaps we don't care
18:29:55 <samueldmq> Wont fix?
18:30:04 <stevemar> we should still clean it up then
18:30:16 <lbragstad__> ok - here is what i'll do
18:30:26 <lbragstad__> i'll update it to target the older releases
18:30:41 <lbragstad__> and ask for more information about how the use was removed
18:30:45 <lbragstad__> before marking it as Won't Fix
18:30:47 <stevemar> lbragstad__: i just did :)
18:30:47 <samueldmq> Do we still support ldap for roles in that same release?
18:30:53 <samueldmq> There can be the same issue
18:31:02 <stevemar> samueldmq: don't believe so...
18:31:21 <lbragstad__> stevemar: ah thanks (I'm having a hell of a time with my Mac right now due to the garbage that is the Sierra update)
18:31:45 <lbragstad__> stevemar: I will keep tabs on it and follow up with Alberto
18:31:45 <stevemar> lbragstad__: we good on this bug report?
18:31:51 <stevemar> coolio
18:31:52 <lbragstad__> yeah - i got what i needed
18:31:55 <lbragstad__> thanks
18:32:03 <stevemar> dstanek: you're up
18:32:03 <stevemar> #topic spec saml-logout-token-revocation
18:32:18 <dstanek> yay.
18:32:43 <dstanek> topol_: created this a while ago and it looks like it is interesting to enterprise use
18:33:08 <dstanek> has anyone read the spec and have strong feeling one way or another?
18:33:34 <dstanek> the general idea is to support the enterprise concept of a global logout
18:33:47 <stevemar> sounds liek thats the case
18:34:34 <dstanek> there are some technical challenges that i haven't figured out yet and we'd likely need to start storing more information about how tokens are created
18:34:43 <stevemar> havent looked at the etherpad yet :(
18:35:02 <dstanek> i did a small brain dump here:
18:35:05 <dstanek> link: https://etherpad.openstack.org/p/keystone-single-logout
18:35:06 <stevemar> #link https://etherpad.openstack.org/p/keystone-single-logout
18:35:40 <stevemar> we had a few bugs reported with similar feedback
18:36:08 <stevemar> federaed user would log out of horizon, but they'll stay logged into their other application
18:36:10 <dstanek> shibboleth itself does this quite easily. it's when you have to invalidate our tokens that you run into problems.
18:36:30 <dstanek> stevemar: that's actually pretty easy. it the IdP initiated logout that's hard
18:36:42 <stevemar> yeah
18:36:50 <stevemar> much harder
18:36:53 <dstanek> someone logs out somewhere else and keystone/horizon gets the logout message
18:37:40 <stevemar> yeah, sounds necessary, not sure how to go aboout doing it
18:37:50 <dstanek> so challenge right now is that if i get a logout message directly to keystone which tokens to i invalidate?
18:38:23 <dstanek> i was just hoping to see if anyone have a need for this or maybe has reason to say not to do it
18:38:37 <dstanek> dolphm: will also be following up at the summit
18:38:40 <stevemar> you'd need info abt the idp and user in the message
18:38:55 <dolphm> ++
18:39:43 <knikolla> we can't just invalidate all user tokens right?
18:39:50 <knikolla> that specific user*
18:40:10 <stevemar> dstanek: if you're gauging work items, i think we'll get more mileage out of the pysaml handler instead of mod_shib; rather than this one
18:40:12 <stevemar> but i could be wrong
18:40:18 <bknudson> it's easy to invalidate all user tokens. we already do it when password changes
18:40:56 <dstanek> knikolla: that's certainly a possiblity. we'll have to start recording saml2 session-id to user-id mapping somewhere at a minimum
18:42:38 <stevemar> invalidating all user tokens would handle on scenario
18:42:55 <stevemar> not the one where the user logs out from the IDP directly though
18:43:32 <dstanek> so this means, for example, when horizon creates a token on behalf of a user that we would create a new database record (only one per user required)
18:44:15 <dstanek> i'm trying to find a clever way to utilize shibboleth's builtin stuff, but i've come up empty so far
18:45:18 <stevemar> i'll try to dig into it, but no promises :\
18:45:24 <dolphm> dstanek: you can't have more than one session ID per user at a time?
18:45:24 <knikolla> does the idp call an endpoint when initiating logout? i'm not familiar with how it works.
18:45:57 <knikolla> as in, is there any idp-sp communication during idp logout
18:46:05 <dstanek> dolphm: not to my knowledge
18:46:15 <stevemar> knikolla: i believe so, you setup a specific SSOLogOut url
18:46:25 <dstanek> basically the SP advertises a SLO url in its metadata
18:46:55 <dstanek> the idp will the send an XMl message like '<LogOut><SessionId>dkdkjkgjgkkgjdf</SessionId></LogOut>' to it
18:47:17 <dstanek> normally that goes right to shibboleth
18:47:17 <knikolla> so we have session_id -> user_id mapping, and we revoke tokens for that user
18:47:52 <dstanek> i'm looking for a way to have shibboleth actually call our code
18:47:58 <dstanek> knikolla: right
18:48:16 <bknudson> dstanek: keystone has a rest api you can call ;)
18:48:35 <dstanek> bknudson: that's the problem. i can't figure out how to call it yet.
18:48:44 <bknudson> curl
18:49:14 <dstanek> i'd actually just like mod_shib to kill off it's session data for forward the request to horizon's logout.
18:50:19 <dstanek> my almost attempt was to have a horizon logout url that redirected to the shibboleth url. almost got that working before i called it a day on Friday
18:50:54 <dstanek> that's the way i will continue to pursue it for right now, but i wanted to raise some awareness and get some feedback
18:51:09 <stevemar> dstanek: keep us posted
18:51:27 <stevemar> open discussion?
18:51:32 <dstanek> the problem is i don't know if IdPs support redirects :-)
18:51:35 <dstanek> stevemar: sure
18:51:48 <stevemar> dstanek: thanks, i wanted to poke about something with PCI
18:51:52 <stevemar> #topic open discussion
18:52:16 <stevemar> rderose: gagehugo tossed up https://review.openstack.org/#/c/383832/ to check for users with expired passwords
18:52:17 <dstanek> how are the Jays doing?
18:52:25 <gagehugo> yes
18:52:36 <stevemar> dstanek: i will politely ignore that
18:52:38 <rderose> stevemar: have it on my to do list :)
18:53:17 <stevemar> my question was whether we should automatically set a user to 'disabled' if the password expires
18:53:22 <stevemar> but i guess we can't easily do that
18:53:36 <stevemar> gagehugo provided a useful paste: http://paste.openstack.org/show/586034/
18:54:02 <gagehugo> I think you would have to just periodically check everyone's times to see if that date time had passed
18:54:16 <gagehugo> But that seems not easy
18:54:23 <stevemar> which, just won't happen :P
18:54:45 <knikolla> an admin api that ops register to cron?
18:55:02 <rderose> stevemar: hmm... we could easily disable a user if their password is expired actually
18:55:07 <stevemar> gagehugo: i like the suggestion in the patch, to query if password_expires_at < current time
18:55:26 <rderose> stevemar: shall I throw up a patch on this?
18:55:39 <gagehugo> Yeah thats what we were going for originally but the wording was bad in the first few iterations
18:56:14 <stevemar> rderose: review the patch if possible
18:56:20 <rderose> sounds good
18:56:28 <bknudson> are they automatically enabled when they change their password?
18:56:46 <rderose> bknudson: no
18:57:00 <bknudson> Can I change my password if I'm disabled?
18:57:02 <knikolla> an admin has to change the password for them IIRC
18:57:03 <gagehugo> Users are not disabled when their password expires, nor are they disabled when they try to auth after expiration
18:57:21 <bknudson> usually if my password is expired I can still change my password
18:57:41 <stevemar> bknudson: usually, yes
18:58:18 <stevemar> don't think we're going to figure it out in < 2 minutes, but please review the spec and we can chat in -keystone
18:58:25 <rderose> bknudson: if your password expires, you will need admin password reset
18:58:58 <AJaeger> could the admin password expire as well?
18:59:11 <stevemar> AJaeger: yep
18:59:21 <AJaeger> And who would reset that one?
18:59:24 <gagehugo> Yes, I accidentally locked my admin user out
18:59:30 <AJaeger> ;)
18:59:31 <knikolla> keystone-manage
18:59:33 <rderose> AJaeger: another admin
18:59:43 <rderose> :)
18:59:53 <stevemar> AJaeger: you can mark certain user IDs as being privileged and not subject to the PCI expiry settings
18:59:55 <bknudson> as an admin I don't want to have to deal with users.
19:00:22 <AJaeger> stevemar: I see - that works
19:00:24 <stevemar> times up
19:00:27 <stevemar> #endmeeting