15:00:38 <dmendiza[m]> #startmeeting keystone
15:00:38 <opendevmeet> Meeting started Tue Jul 12 15:00:38 2022 UTC and is due to finish in 60 minutes.  The chair is dmendiza[m]. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:38 <opendevmeet> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:00:38 <opendevmeet> The meeting name has been set to 'keystone'
15:00:47 <dmendiza[m]> #topic Roll Call
15:01:01 <knikolla> o/
15:01:06 <dmendiza[m]> Courtesy ping for admiyo, bbobrov, crisloma, d34dh0r53, dpar, dstanek, hrybacki, knikolla, lbragstad, lwanderley, kmalloc, rodrigods, samueldmq, ruan_he, wxy, sonuk, vishakha, Ajay, rafaelwe, xek
15:01:13 <dmendiza[m]> As usual teh agenda is over here
15:01:21 <h_asahina> o/
15:01:29 <dmendiza[m]> #link https://etherpad.opendev.org/p/keystone-weekly-meeting
15:01:49 <d34dh0r53> o/ lurking, in another meeting
15:02:46 <dmendiza[m]> Cool, let's get started
15:03:00 <dmendiza[m]> #topic Review Past Meeting Action Items
15:03:55 <dmendiza[m]> #link https://meetings.opendev.org/meetings/keystone/2022/keystone.2022-07-05-15.11.html
15:04:04 <dmendiza[m]> I'm still kicking this can down the road
15:04:16 <dmendiza[m]> #action
15:04:16 <dmendiza[m]> dmendiza[m] to try to run keystone from a fresh clone
15:04:49 <dmendiza[m]> #action dmendiza[m] to try to run keystone from a fresh clone
15:05:41 <dmendiza[m]> #topic Liaison Updates
15:05:52 <dmendiza[m]> This week is milestone Zed-2 week
15:06:32 <dmendiza[m]> #link https://releases.openstack.org/zed/schedule.html
15:07:08 <dmendiza[m]> I haven't seen any automatic patches come through for the release
15:07:19 <dmendiza[m]> but I haven't looked very hard
15:07:25 <dmendiza[m]> I'll make sure we get a release out this week.
15:07:38 <dmendiza[m]> #action dmendiza[m] to make sure we get a Zed-2 release out
15:07:53 <dmendiza[m]> Any questions/comments about Zed-2 ?
15:10:22 <dmendiza[m]> OK, moving on
15:10:24 <dmendiza[m]> #topic OAuth 2.0
15:10:30 <dmendiza[m]> h_asahina: any updates this week?
15:10:46 <h_asahina> yes, i've updated the patch.
15:10:55 <h_asahina> https://review.opendev.org/c/openstack/keystone-specs/+/843765
15:11:08 <h_asahina> according to the comments you all given me.
15:11:23 <dmendiza[m]> Oh great.
15:11:35 <dmendiza[m]> We didn't have a reviewathon last week, but I'm happy to see xek_ was able to review it
15:11:46 <dmendiza[m]> We'll look at it again this week for the Reviewathon hopefully
15:12:04 <h_asahina> thanks
15:12:15 <h_asahina> do you have any comments now?
15:12:21 <h_asahina> or questions
15:13:14 <dmendiza[m]> I don't have any yet ... (haven't had a chance to dig into the spec)
15:13:17 <dmendiza[m]> knikolla: ?
15:14:43 <knikolla> no unfortunately
15:15:32 <h_asahina> okey. please do it on the gerrit if you have. I'll update the patch asap after you comment on it.
15:16:10 <dmendiza[m]> Thanks h_asahina
15:16:17 <dmendiza[m]> #topic Secure RBAC
15:16:49 <dmendiza[m]> #link https://review.opendev.org/c/openstack/governance/+/847418
15:16:58 <dmendiza[m]> Just making sure y'all keep an eye out for this review
15:17:22 <dmendiza[m]> Looks like gmann is working through another set of refinements for the SRBAC goal
15:19:54 <dmendiza[m]> OK moving on
15:20:17 <dmendiza[m]> #topic Gate inherited assignments from parent (bbobrov)
15:20:31 <dmendiza[m]> #link https://review.opendev.org/c/openstack/keystone-specs/+/334364
15:20:34 <dmendiza[m]> bbobrov: around?
15:22:19 <dmendiza[m]> Looks like a no
15:22:21 <dmendiza[m]> le'ts move on
15:22:34 <dmendiza[m]> #topic  Keystone identity mapping to support project definition as a JSON
15:22:43 <dmendiza[m]> #link https://review.opendev.org/c/openstack/keystone-specs/+/748748
15:23:02 <dmendiza[m]> rafaelweingartner: around?
15:24:55 <dmendiza[m]> Looks like also no
15:25:03 <dmendiza[m]> OK, let's move on to the bug review
15:25:09 <dmendiza[m]> #topic Bug Review
15:25:54 <dmendiza[m]> There's a downstream bug I wanted to get your opinion on knikolla
15:26:32 <dmendiza[m]> The use case is:  User has an application credential that expires in 5 minutes
15:26:52 <dmendiza[m]> Within those 5 min the user uses the appcred to get a token
15:27:17 <dmendiza[m]> the token is issued with the default token duration in keystone.conf (default 1hr)
15:28:01 <dmendiza[m]> From the bug reporter's point of view, this is an issue because the user is able to extend their access by the default token duration
15:28:50 <dmendiza[m]> knikolla: is it reasonable to expect that tokens issued using an appcred should expire at the same time the appcred expires
15:28:52 <dmendiza[m]> ?
15:29:37 <knikolla> good question.
15:30:20 <knikolla> the application credential is an authentication method, therefore a user can authenticate until that method is valid.
15:30:40 <knikolla> a different question would be, does changing a user's password invalidate a user's tokens?
15:32:51 <d34dh0r53> hmm
15:32:56 <dmendiza[m]> Gut feeling is yes
15:33:17 <dmendiza[m]> let's say you're changing the pw because you think the old pw might be compromised
15:33:38 <d34dh0r53> yeah, you don't want old tokens being able to change the password again
15:33:43 <dmendiza[m]> in that case you'd want any outstanding tokens to be invalidated to make sure no one else is using your account
15:34:11 <knikolla> d34dh0r53: you also need the old password to change the password, just a token is not enough IIRC
15:34:38 <d34dh0r53> ahh, I was just thinking about that, but regardless what dmendiza[m] said also applies
15:35:11 <dmendiza[m]> You kind of see it in some services that let you "sign out everywhere" when you change your pw
15:35:13 <knikolla> if changing a password (invalidating an old authentication method) revokes tokens, then i think there is a good argument for expiring app creds to revoke tokens.
15:35:29 <knikolla> (less about the general case, and more about the keystone case)
15:35:49 <dmendiza[m]> Yeah, that's a good argument.
15:36:00 <dmendiza[m]> OK, I was on the fence on this one, but you've convinced me that we should probably fix that
15:37:18 <dmendiza[m]> Moving on to upstream bugs ...
15:37:20 <dmendiza[m]> #link https://bugs.launchpad.net/keystone/?orderby=-id&start=0
15:39:20 <dmendiza[m]> #link https://bugs.launchpad.net/keystone/+bug/1981365
15:39:46 <dmendiza[m]> > Do not allow updating ephemeral users attributes via API
15:40:20 <dmendiza[m]> Seems pretty straightforward
15:40:47 <knikolla> seems expected behavior to me
15:40:52 <knikolla> idp is the source of truth
15:41:22 <dmendiza[m]> This could be a good one for d34dh0r53 since he's our Federation guy.
15:41:38 <d34dh0r53> ack
15:41:57 <knikolla> i'm against it
15:42:44 <dmendiza[m]> 🤔
15:43:01 <knikolla> i think a documentation fix is more appropriate. the linked spec also proposes changing the api in a non backwards compatible way.
15:43:32 <knikolla> the fundamental thing to understand is that the IdP is the source of truth, it SHOULD overwrite
15:44:00 <knikolla> the CRUD API for federation is there mostly to provide a way to create users ahead of time and query them.
15:44:57 <dmendiza[m]> Hmm...  I need to look into the API more to have an educated opinion.  Is the API sued for both regular users and federated users?
15:45:24 <knikolla> yes
15:45:41 <knikolla> you can modify a users' "federation attributes"
15:45:48 <knikolla> hence turning a normal user into a federated user
15:46:15 <knikolla> there is no practical difference between an ephemeral user and a normal user created from the API with federated attributes.
15:55:57 <dmendiza[m]> > changing the api in a non backwards compatible way
15:55:57 <dmendiza[m]> Is that because there would be a new response status? 🤔
15:56:46 <knikolla> yes, for a specific type of API call the behavior would change
15:57:16 <knikolla> but outside of that, i disagree with the direction
15:59:19 <dmendiza[m]> K,
15:59:35 <dmendiza[m]> Can you leave a comment on the bug?
15:59:40 <dmendiza[m]> And that's all the time we have
15:59:42 <knikolla> will do
15:59:46 <dmendiza[m]> Thanks for joining, y'all!
16:00:04 <dmendiza[m]> #endmeeting