| opendevreview | Grzegorz Grasza proposed openstack/keystone master: Change the min value of pool_retry_max to 1 https://review.opendev.org/c/openstack/keystone/+/824140 | 10:41 |
|---|---|---|
| *** whoami-rajat__ is now known as whoami-rajat | 13:36 | |
| dmendiza[m] | #startmeeting keystone | 15:00 |
| opendevmeet | Meeting started Tue Jan 11 15:00:13 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 |
| opendevmeet | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 15:00 |
| opendevmeet | The meeting name has been set to 'keystone' | 15:00 |
| dmendiza[m] | #topic Roll Call | 15:00 |
| dmendiza[m] | 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, rafaelweingartner, xek | 15:00 |
| knikolla | o/ | 15:01 |
| d34dh0r53 | o/ | 15:01 |
| dmendiza[m] | Hi y'all! | 15:02 |
| * dmendiza[m] is the dev formerly known as redrobot | 15:02 | |
| dmendiza[m] | in case anyone is wondering | 15:02 |
| dmendiza[m] | Let's get started. | 15:02 |
| dmendiza[m] | #topic Review Last Year's Action Items | 15:03 |
| dmendiza[m] | #link https://meetings.opendev.org/meetings/keystone/2021/keystone.2021-12-07-15.04.html | 15:03 |
| dmendiza[m] | We didn't have any | 15:03 |
| dmendiza[m] | #topic Liaison Updates | 15:03 |
| dmendiza[m] | knikolla: any updates for us? | 15:03 |
| knikolla | No updates. Still getting back in the rhythm of things after PTO | 15:03 |
| dmendiza[m] | Same | 15:04 |
| dmendiza[m] | Okay, let's move on | 15:04 |
| dmendiza[m] | #topic Specs | 15:04 |
| *** xek_ is now known as xek | 15:04 | |
| dmendiza[m] | Let's start with OAuth 2.0 spec | 15:04 |
| dmendiza[m] | #link https://review.opendev.org/c/openstack/keystone-specs/+/813152 | 15:04 |
| dmendiza[m] | Looks like there's a new patch up for review | 15:05 |
| dmendiza[m] | I have not had a chance to look at it yet | 15:05 |
| dmendiza[m] | (I just came back from PTO yesterday) | 15:05 |
| knikolla | I haven’t had a chance to review the new patchset either. | 15:06 |
| h_asahina | o/ | 15:07 |
| dmendiza[m] | Do we have a spec freeze? I see Cinder and Manila have Spec freezes in R-15 https://releases.openstack.org/yoga/schedule.html | 15:07 |
| h_asahina | I'd like to discuss bout that update later | 15:07 |
| dmendiza[m] | hi h_asahina ! | 15:08 |
| h_asahina | hi | 15:08 |
| dmendiza[m] | Now would be a good time for updates if you have any | 15:09 |
| dmendiza[m] | since OAuth is the current topic | 15:09 |
| h_asahina | okey | 15:09 |
| h_asahina | Today I'd like to talk bout four topics as I wrote in the etherpad | 15:10 |
| h_asahina | The first three topics are not heavy, which are basically confirmations. | 15:10 |
| h_asahina | and the last topic is discussion. | 15:11 |
| h_asahina | The fist topic is about `scope` function. | 15:11 |
| h_asahina | We'd like to omit the scope function of OAuth2.0 in Yoga release. | 15:12 |
| h_asahina | The reason behind this is that the scope definition in OAuth2.0 and that in Application credentials are different and thus we have to further discuss how to map the OAuth scope to Application credentials scope. | 15:13 |
| h_asahina | but we don't have enough time to do that. So, we've dicided to omit it. If you feel any concern please tell me. | 15:14 |
| h_asahina | This is the first topic. any comments? | 15:15 |
| dmendiza[m] | Seems reasonable to reduce the scope (no pun intended) of the implementation for Yoga | 15:15 |
| knikolla | if 'scope' is an optional word in an authentication request for oauth 2.0 client credentials, sure. | 15:16 |
| knikolla | i'll have to reread the spec. my memory is rusty from before the new year's break. | 15:16 |
| h_asahina | Yes it's an optional parameter. :knikolla. | 15:17 |
| knikolla | ok, works for me then. | 15:17 |
| h_asahina | thanks, I've already removed scope from the spec. | 15:19 |
| h_asahina | Please put a comment on the spec if you find a problem on the new version. | 15:19 |
| h_asahina | So, I'll move on to the next topic. | 15:20 |
| h_asahina | The second topic is about the permission. | 15:20 |
| h_asahina | As the OAuth2.0 APIs uses Application credential APIs as its backend, users have to get permissions to access both OAuth2.0 APIs and Application credential APIs. This is the straight forward way to manage the users' permission for the OAuth2.0 that I thought. | 15:22 |
| h_asahina | Do you agree with this? | 15:22 |
| h_asahina | If you have any other options, please kindly tell me. | 15:23 |
| knikolla | yeah, the application credentials are created through the application credential api. and authenticating with them will use the oauth 2.0 api, so makes sense. | 15:23 |
| h_asahina | Thanks. | 15:24 |
| h_asahina | but please note that we are going to create a new application credential automatically when an OAuth2.0 client is created. | 15:25 |
| knikolla | can you elaborate on that? why does an oauth 2.0 client need to be created and how is that different from an application credential? | 15:26 |
| h_asahina | This is beacuse the OAuth2.0 client has some different attributes like `token_endpoint_auth_method`, `grant_type`, etc, which are not available on the application credentials. | 15:27 |
| knikolla | can you describe what those attributes mean and why they are necessary? | 15:28 |
| h_asahina | okey. These attributes are necessary to distinguish the grant type basically that is how a client get an OAuth2.0 token. | 15:30 |
| knikolla | but the only grant type that we are supporting is client_credentials | 15:30 |
| h_asahina | yes | 15:30 |
| h_asahina | If we'll not extend that in the future, we can fix this to client_credentials | 15:31 |
| knikolla | are there any reasons not to treat all application credentials as clients? | 15:31 |
| knikolla | as in, if an application credentials is created, that can be used to authenticate through the oauth 2.0 api. without the need for new data models. | 15:33 |
| h_asahina | If we make OAuth2.0 general, we should create a new API. | 15:33 |
| d34dh0r53 | go 55 | 15:33 |
| d34dh0r53 | oops, sorry | 15:33 |
| h_asahina | that what I thought. | 15:34 |
| h_asahina | but maybe you're right. | 15:34 |
| knikolla | if we start implementing more grant types, yes. But that requires further thought in how to map the attributes between the two. | 15:35 |
| knikolla | especially with regards to how to convey projects and roles, for which oauth 2.0 is very vague about. | 15:36 |
| knikolla | application credentials already carry all the authorization information that we need and map very cleanly to client credentials. | 15:36 |
| h_asahina | I see. That's true. We don't have to implement redundant APIs for the future. | 15:36 |
| knikolla | so, in my opinion, for now it's sufficient to just provide an authentication API for application credentials that looks like Oauth 2.0. | 15:36 |
| h_asahina | Got it. I'll discuss it with our development team. | 15:37 |
| knikolla | Thanks. I'm just trying to reduce the attack surface that implementing a new authentication type introduces. | 15:38 |
| knikolla | But if there are obvious benefits to going all in and implementing more general oauth 2.0, i'm open to it. | 15:38 |
| h_asahina | Thanks. I basically agree with your suggestion. | 15:39 |
| knikolla | Though I think we should be conservative about such an approach given out very small team size. | 15:39 |
| knikolla | And I'd prefer starting with adding support for oidc in keystonemiddleware and bypassing keystone entirely, haha. | 15:39 |
| knikolla | for that thing in specific. | 15:39 |
| h_asahina | Actually, it's benefit for us as the implementation gets easier. | 15:40 |
| h_asahina | okey, thanks. I'd like to move on to the next. | 15:41 |
| h_asahina | The third topic is the API endpoint. | 15:42 |
| h_asahina | In the current spec, I wrote `/identity/v3/auth/OS-OAUTH2/clients` as an endpoint URL for the OAuth2.0. is it okey? | 15:42 |
| h_asahina | other options can be i) `/identity/v3/auth/OS-OAUTH2/<user_id>/clients` ii) `/identity/v3/users/{user_id}/OS-AUTH2/clients`. | 15:43 |
| h_asahina | Could you give me your opinion as it affects to keystone users. | 15:44 |
| knikolla | For the authentication request? | 15:44 |
| h_asahina | Ah, sorry, a token request considering the today's discussion. | 15:45 |
| dmendiza[m] | What is the benefit of having the user_id in the URL? Is it not present in the body of the request? | 15:45 |
| dmendiza[m] | or can it not be inferred from the body of the request? | 15:45 |
| h_asahina | I thought body doesn't contain user_id but we can obtain it from X-Auth-Token at least. | 15:46 |
| h_asahina | The reason why we put user_id is just following the URL of Application credentials. | 15:46 |
| knikolla | That would have been for the CRUD of OAuth 2.0 requests, at this point we just need to decide on what we'll be the `token_endpoint` for OAuth 2.0. | 15:47 |
| knikolla | As that's the only API that is needed after today's discussion. | 15:47 |
| h_asahina | Yes indeed. | 15:48 |
| knikolla | Part of me thinks it shouldn't be in /v3 at all, as this is part of the OAuth 2.0 API, not the OpenStack Identity v3 API. | 15:48 |
| knikolla | But that might be troublesome given the auth_url usually including v3 in the path. | 15:49 |
| knikolla | But in this case it wouldn't be openstack clients authenticating, so maybe it doesn't matter. | 15:49 |
| h_asahina | but we'll implement token endpoint inside the keystone as well as the existing OAuth1.0 APIs. In this case, it's still better to remove v3? | 15:52 |
| h_asahina | https://docs.openstack.org/api-ref/identity/v3-ext/#os-oauth1-api | 15:53 |
| knikolla | perhaps /v3/auth/tokens, then. since oauth1.0 is using that as well? | 15:53 |
| knikolla | or v3/OS-AUTH2/tokens | 15:54 |
| knikolla | or v3/oidc/tokens | 15:54 |
| knikolla | I'm don't have a strong opinion. | 15:55 |
| h_asahina | /v3/auth/tokens or v3/OS-AUTH2/tokens sound reasonable. | 15:55 |
| h_asahina | If it doesn't serious problem I'll choose from one of them. | 15:55 |
| h_asahina | it isn't | 15:55 |
| dmendiza[m] | 5 minute warning | 15:56 |
| knikolla | I don't feel strongly about any of them. | 15:56 |
| h_asahina | okey. | 15:56 |
| dmendiza[m] | We're almost out of time. | 15:57 |
| dmendiza[m] | h_asahina: maybe we can continue this next week, or after the meeting. | 15:58 |
| h_asahina | got it. we don't have to discuss the last topic as it is soleved by today's discussion. | 15:58 |
| dmendiza[m] | Great | 15:58 |
| knikolla | cool! | 15:58 |
| dmendiza[m] | Thanks for joining, everyone! | 15:58 |
| d34dh0r53 | I have something really quick, I'd like to host another reviewathon this Friday, the 14th. Please let me know if you're interested | 15:58 |
| dmendiza[m] | #endmeeting | 15:58 |
| opendevmeet | Meeting ended Tue Jan 11 15:58:43 2022 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 15:58 |
| opendevmeet | Minutes: https://meetings.opendev.org/meetings/keystone/2022/keystone.2022-01-11-15.00.html | 15:58 |
| opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/keystone/2022/keystone.2022-01-11-15.00.txt | 15:58 |
| opendevmeet | Log: https://meetings.opendev.org/meetings/keystone/2022/keystone.2022-01-11-15.00.log.html | 15:58 |
| h_asahina | thanks a lot. bye | 15:58 |
| dmendiza[m] | d34dh0r53: count me in for review-a-thon | 15:59 |
| knikolla | d34dh0r53: sounds great! | 15:59 |
| knikolla | outside of 10-12 EST, i'm free. | 15:59 |
| d34dh0r53 | ack, thanks knikolla | 16:00 |
| d34dh0r53 | I'll send out the invite shortly | 16:00 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!