16:00:22 <cmurphy> #startmeeting keystone
16:00:23 <openstack> Meeting started Tue Apr 23 16:00:22 2019 UTC and is due to finish in 60 minutes.  The chair is cmurphy. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:24 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:00:27 <openstack> The meeting name has been set to 'keystone'
16:00:31 <lbragstad> o/
16:00:36 <cmurphy> #link https://etherpad.openstack.org/p/keystone-weekly-meeting agenda
16:00:37 <vishakha> o/
16:01:22 <cmurphy> o/
16:01:47 <wxy|> o/
16:02:16 <cmurphy> okay let's get started
16:02:25 <cmurphy> #topic next meetings
16:02:26 <hrybacki> o/
16:02:32 <gagehugo> o/
16:02:50 <cmurphy> next week most of us will be at the summit so we will have to cancel that meeting
16:02:58 <cmurphy> wait
16:03:07 <cmurphy> yes next week
16:03:23 * cmurphy loses track of time
16:04:01 <cmurphy> the following week i'm going to take a couple of days off, I could ask for a volunteer to chair the meeting but i think most of us are going to be toast anyway and we may as well cancel
16:04:03 <cmurphy> thoughts?
16:04:18 <lbragstad> wfm
16:04:32 <lbragstad> i'll likely be working on summaries anyway
16:06:13 <cmurphy> okay
16:06:41 <cmurphy> #agreed next two meetings canceled, resume meetings Tuesday 14 May
16:06:57 <vishakha> ok
16:07:00 <gagehugo> wfm
16:07:12 <cmurphy> cool
16:07:16 <cmurphy> #topic reviews
16:07:27 <cmurphy> anyone want to highlight any reviews?
16:09:54 <cmurphy> I noticed jose was working on https://review.opendev.org/655166 and wanted to bring it up
16:10:25 <cmurphy> would that work? and would we need renewable app creds in that case?
16:10:43 <cmurphy> knikolla: kmalloc ?
16:11:09 <knikolla> o/
16:11:11 <kmalloc> that should be allowed, as long as if the group role assignment changes the app cred is likewise invalidated
16:11:25 <kmalloc> there is no reason a group-conveyed role assignment should be restricted from use in an app cred
16:11:33 <kmalloc> doesn't need renewable.
16:11:39 <kmalloc> assuming concrete group role assignment
16:11:41 <lbragstad> it looks like they're generated at validation time
16:12:17 <knikolla> we can't really check on group membership changes if they happen in idp
16:12:23 <knikolla> and user only uses app cred to log in
16:12:55 <kmalloc> IDP/Federation allowed appcreds are not concrete assignments
16:13:43 <cmurphy> but groups are concrete and have concrete role assignments
16:13:46 <lbragstad> #link https://review.opendev.org/#/c/655166/1/keystone/models/token_model.py@412
16:13:49 <kmalloc> group roles can't be divined from the IDP in any case, group membership can. either a role is conveyed to the user directly in federation or it's a role assignment on a group within keystone
16:14:07 <kmalloc> so, no reason group role assignments shouldn't be allowed in app creds.
16:14:10 <kmalloc> afaict
16:15:00 <lbragstad> well - i thought the main driver of renewable app creds was because we wanted to "force" the auditing of those groups
16:15:36 <lbragstad> so that a federated user couldn't just create an application credential with access that gets out of sync from the idp in the future
16:16:04 * lbragstad could be mis-remembering something though
16:16:10 <kmalloc> that is fair
16:16:18 <kmalloc> but this appears to be *any* group assignment
16:16:46 <cmurphy> ignoring auto-provisioned projects, when a federated user gets a scoped token the mapping gives them a membership in a group which gives them an effective role assignment
16:17:07 <cmurphy> if they lose membership to the group because their saml attributes changed then they don't have the effective role assignment any more
16:17:19 <cmurphy> because the mapping wouldn't apply any more
16:17:21 <cmurphy> right?
16:17:25 <lbragstad> and that's driven by the assertion, yeah?
16:17:32 <cmurphy> as i understand it
16:17:33 <kmalloc> right, but they could login with the app cred is the concern
16:17:39 <kmalloc> circumventing that effective bit.
16:17:43 <lbragstad> right
16:17:53 <lbragstad> so if i have membership to an admin group in an idp somewhere
16:17:57 <kmalloc> so, exempt federation from effective until we have renewable?
16:18:06 <kmalloc> but otherwise, this still feels like a gap in our functionality
16:18:14 <lbragstad> i can use my assertion to generate an application credential to that corresponding OpenStack group
16:18:38 <lbragstad> and nothing would force me to revisit that authorization, even if i'm removed from that group or company
16:18:54 <cmurphy> okay that's right, i'm remembering now
16:19:17 <lbragstad> iirc - renewability was our scapegoat
16:20:26 <lbragstad> in order to prevent that specific foot-gun scenario
16:21:35 <kmalloc> we could just do a "is_federated" and not do "effective"
16:22:03 <kmalloc> in that case. until we have renewable
16:22:21 <kmalloc> and we can do the same normal invalidation on group assignment change we do on direct assignment
16:25:06 <cmurphy> okay i'm in agreement, can someone comment on the patch?
16:25:25 <kmalloc> I'll comment.
16:25:33 <cmurphy> thanks
16:26:25 <cmurphy> i also wanted to mention https://review.opendev.org/649177 i haven't looked at the last revision but it seems like it fixes an important bug but needs some careful eyes on it
16:27:51 <cmurphy> #topic open discussion
16:27:57 <cmurphy> anything else anyone wants to bring up?
16:28:29 <lbragstad> my internal team is having a team dinner at some point next week, we just don't know when, where, or how.
16:28:49 <lbragstad> so - i'm not sure if that will conflict with the keystone team dinner at anypoint
16:29:11 <cmurphy> lbragstad: based on the poll i was going to go for wednesday
16:29:42 <lbragstad> sweet - if that's the consensus, i'll let my internal team know
16:29:56 <cmurphy> cool
16:30:20 <cmurphy> i'll be trying to organize that properly today
16:30:27 <kmalloc> commented.
16:31:19 <lbragstad> thanks cmurphy
16:34:04 <cmurphy> here's another question for the group, do we need branches for ldappool? see thierry's question https://review.opendev.org/654455
16:35:06 <lbragstad> interesting
16:36:05 <kmalloc> we had them for convenience not for any other reason
16:36:14 <kmalloc> probably don't need the branching
16:38:05 <cmurphy> i'll ask pas-ha since he had asked about the branch, i think we may as well drop them
16:38:59 <hrybacki> from a vendor perspective, branches are nice \0/
16:39:40 <cmurphy> hrybacki: from another vendor perspective we don't use the branches for that lib
16:39:43 <cmurphy> ¯\_(ツ)_/¯
16:40:09 <hrybacki> I don't have a strong argument tbh -- hence the weak shruggie :)
16:42:36 <cmurphy> yeah doesn't seem like there's a strong rationale either way
16:42:55 <cmurphy> seems like the meeting is winding down so let's go ahead and close it and get a few minutes back
16:43:01 <cmurphy> see most of you next week!
16:43:07 <cmurphy> #endmeeting