15:00:02 <redrobot> #startmeeting keystone
15:00:02 <opendevmeet> Meeting started Tue Nov  9 15:00:02 2021 UTC and is due to finish in 60 minutes.  The chair is redrobot. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:02 <opendevmeet> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:00:02 <opendevmeet> The meeting name has been set to 'keystone'
15:00:07 <redrobot> #topic Roll Call
15:00:16 <redrobot> Courtesy ping for ayoung, bbobrov, crisloma, d34dh0r53, dpar, dstanek, gagehugo, hrybacki, knikolla, lamt, lbragstad, lwanderley, kmalloc, rodrigods, samueldmq, spilla, ruan_he, wxy, sonuk, vishakha,Ajay, raildo, rafaelweingartner, xek
15:00:25 <d34dh0r53> o/
15:01:26 <lbragstad> o/
15:01:32 <lbragstad> double booked atm
15:01:42 <knikolla> o/
15:02:19 <redrobot> Yeah, I had a lot of fun sorting out my schedule today.  Thanks, Daylight Savings Time.
15:02:40 <redrobot> #topic Review Past Meeting Action Items
15:02:44 <redrobot> #link https://meetings.opendev.org/meetings/keystone/2021/keystone.2021-11-02-15.00.html
15:02:50 <redrobot> We didn't have any
15:03:05 <redrobot> #topic Liaison Updates
15:03:10 <redrobot> knikolla anything on your radar?
15:03:37 <knikolla> i don't think so
15:04:54 <redrobot> OK, moving on
15:05:09 <redrobot> #topic OAuth 2.0
15:05:17 <redrobot> #link https://review.opendev.org/c/openstack/keystone-specs/+/813152
15:05:37 <redrobot> Thanks for reviewing knikolla.  Still looking for gagehugo and lbragstad reviews
15:09:30 <lbragstad> ack
15:09:47 <lbragstad> i'm not sure i'll be able to review it
15:10:32 <redrobot> 😔
15:10:52 <redrobot> Yeah, I don't know enough OAuth to give it a proper review
15:11:21 <redrobot> I'll keep bugging y'all 'til we merge this thing though. 😜
15:12:30 <redrobot> OK, let's move on
15:12:43 <redrobot> #topic Secure RBAC
15:12:46 <redrobot> lbragstad any updates?
15:13:01 <lbragstad> yep - i spent a bunch of time last week reworking https://review.opendev.org/c/openstack/governance/+/815158
15:13:06 <lbragstad> i'd love to get some reviews on that
15:13:21 <lbragstad> and it is time sensitive since we're in Yoga and that goal is targeted for Yoga
15:13:40 <knikolla> i'm going through it today
15:13:44 <lbragstad> knikolla thank you
15:15:49 <redrobot> I'll try to get to that today as well
15:17:03 <redrobot> #topic Open Discussion
15:17:28 <redrobot> Any other topics y'all want to talk about before we look at the mountain 'o bugs?
15:28:37 <redrobot> OK,moving on
15:29:02 <redrobot> #topic Bug Review
15:29:05 <redrobot> #link https://bugs.launchpad.net/keystone/?orderby=-id&start=0
15:29:30 <redrobot> #link https://bugs.launchpad.net/keystone/+bug/1950325
15:29:39 <redrobot> > domain list via projects api with domain-scoped token is always empty
15:29:47 <redrobot> This one is fresh out the bug factory
15:33:32 <lbragstad> i'm not sure listing domains with a domain-scoped token is the right thing
15:33:51 <lbragstad> i think you should have a system-scoped token to do that
15:34:50 <knikolla> hmmm, i think i feel that way too.
15:35:07 <lbragstad> that bug could be a filtering issue
15:35:20 <knikolla> though should it display the domains that are further down the tree, if the domain scoped token has the admin role on that domain?
15:35:23 <lbragstad> where it's getting a list of domains and then trying to filter out the domains outside of context
15:35:41 <lbragstad> knikolla i don't think you can have nested domains
15:35:52 <lbragstad> domains are top-level project trees
15:36:28 <knikolla> ah okay. i misremembered.
15:36:33 <redrobot> > you should have a system-scoped token <  - I kind of think so too
15:36:46 <redrobot> seems like the correct response should be a 403 - Forbidden?
15:37:49 <lbragstad> well - i could see if i listed domains using a domain-scoped token, i could get back the domain i have a token to
15:38:05 <lbragstad> so - a list of one
15:38:13 <lbragstad> or maybe a list of the domains i have a role assignment on?
15:38:21 <lbragstad> i'm not sure which would be the right response
15:38:32 <lbragstad> that's typically covered by the /v3/auth/domains API
15:38:52 <knikolla> Do you get any domains when you list for projects? with the appropriate system level scope? or just projects?
15:39:15 <lbragstad> i'm not sure - i haven't tried
15:40:57 <lbragstad> redeploying an environment now and I'll try
15:41:00 <knikolla> i don't think i'm leaning on a 40x type response, because you're putting a filter on an action that you have permission to perform.
15:41:10 <lbragstad> yeah
15:41:32 <lbragstad> i think returning an empty list is appropriate and I thought there was a guideline about that somewhere?
15:41:42 <lbragstad> maybe in the API working group?
15:42:01 <knikolla> and it's either a list of 1, with the scoped domain being returned. or a list of 0, because while the token is scoped to that domain, you may not have permission to query it? (which we should check if it's the case)
15:42:58 <lbragstad> https://specs.openstack.org/openstack/api-wg/guidelines/pagination_filter_sort.html#filtering
15:43:44 <knikolla> also it would be, hmmm, weird if the non-filtered /projects query doesn't return the current domain, but the filtered version does.
15:43:53 <lbragstad> right
15:44:08 <lbragstad> i think if you list projects with a project-scoped token, you get the project your token is scoped to
15:52:21 <lbragstad> yeah -  listing projects with a project-scoped tokens only gives you the projects you have access to
15:52:31 <lbragstad> it doesn't give you a full list
15:52:43 <redrobot> is_domain is a valid filter key?
15:53:15 <lbragstad> yeah
15:53:47 <redrobot> so /v3/projects?is_domain=true should return the domains you have access to, you think?
15:53:50 <lbragstad> https://docs.openstack.org/api-ref/identity/v3/index.html?expanded=list-projects-detail
15:54:03 <lbragstad> sure?
15:54:14 <lbragstad> the /v3/domains api does that i think
15:54:18 <lbragstad> and so does /v3/auth/domains
15:54:39 <knikolla> if the domain is included in the /projects query without the filter, yes.
15:55:23 <knikolla> aka being incorrectly filtered out with the is_domain filter present.
15:55:50 <redrobot> > If this is specified as true, then only projects acting as a domain are included. Otherwise, only projects that are not acting as a domain are included. <
15:56:15 <lbragstad> https://paste.opendev.org/show/810880/
15:56:18 <knikolla> oh, interesting
15:56:46 <knikolla> that's a weird filter
15:57:01 <redrobot> sounds like GET /v3/projects?is_domain=true should be the same as GET /v3/domains
15:57:12 <knikolla> ^ yes
15:57:53 <lbragstad> well - this seems wrong
15:57:53 <lbragstad> https://paste.opendev.org/show/810881/
15:58:26 <lbragstad> that user doesn't have a role assignment on the foo domain
15:58:46 <knikolla> yeah, that shouldn't appear there
15:59:01 <redrobot> Almost out of time
15:59:10 <redrobot> but this does sound like a valid bug
16:00:43 <lbragstad> i think there are probably workarounds for it though
16:00:53 <lbragstad> like using the domains API - but those would be patches to terraform
16:01:32 <redrobot> I'm going to leave a comment on the bug pointing to this discussion
16:01:38 <redrobot> we can revisit next week
16:01:50 <redrobot> That's all the time we have this week
16:01:57 <redrobot> Thanks for joining, y'all!
16:02:20 <redrobot> #endmeeting