| lbragstad | just a heads up - i have a conflict during todays meeting | 14:53 |
|---|---|---|
| redrobot | #startmeeting keystone | 15:00 |
| opendevmeet | Meeting started Tue Nov 30 15:00:41 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 |
| opendevmeet | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 15:00 |
| opendevmeet | The meeting name has been set to 'keystone' | 15:00 |
| redrobot | #topic Roll Call | 15:01 |
| 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, rafaelweingartner, xek | 15:01 |
| knikolla | o/ | 15:02 |
| redrobot | Hi knikolla | 15:02 |
| redrobot | #topic Review Past Meeting Action Items | 15:03 |
| redrobot | #link https://meetings.opendev.org/meetings/keystone/2021/keystone.2021-11-16-15.04.html | 15:03 |
| redrobot | We didn't have any | 15:03 |
| redrobot | #topic Liaison Updates | 15:04 |
| redrobot | knikolla any updates for today? | 15:04 |
| gagehugo | o/ | 15:04 |
| gagehugo | I am double booked today | 15:04 |
| knikolla | no updates on my side, i've not had a lot of time to do things keystone-side. | 15:06 |
| redrobot | gotcha, thanks knikolla | 15:06 |
| redrobot | gagehugo no worries, lbragstad is double booked as well | 15:07 |
| redrobot | #topic OAuth 2.0 | 15:07 |
| redrobot | #link https://review.opendev.org/c/openstack/keystone-specs/+/813152 | 15:07 |
| h_asahina | o/ | 15:08 |
| redrobot | I need to do some more OAuth learnin'. I got some good resources from lbragstad, but then I went on PTO and haven't had a chance to review the spec | 15:08 |
| redrobot | hi h_asahina | 15:08 |
| redrobot | h_asahina do you want to give an update on the spec? | 15:09 |
| h_asahina | Yes. I just replied to knikolla's comments, I'd like to discuss about it if you don't mind. | 15:09 |
| redrobot | h_asahina go ahead | 15:10 |
| h_asahina | knikolla suggestted that using the application creadentials and wrap it with OAuth2.0 client credentials APIs | 15:10 |
| h_asahina | I basically agree with that idea, but I think I have to confirm some points. | 15:11 |
| h_asahina | First of all, If we use the application credentials as a back-end of the OAuth2.0 client credentials, these two features share the same tables. | 15:12 |
| h_asahina | Is that ok for keystone? | 15:12 |
| redrobot | knikolla ^^^ | 15:13 |
| knikolla | yeah, i think so | 15:14 |
| h_asahina | ok. that's good. | 15:15 |
| h_asahina | You also mentioned that the client credentials is not a feature to delegate users' roles to client. | 15:16 |
| h_asahina | I think you're right but the application credentials is also such a kind of feature. Which do you think a better way, following the standard or using application credentials as you suggested. | 15:17 |
| knikolla | good question | 15:20 |
| knikolla | i think application credentials are a better fit because they allow restricting the access of that specific credential to either a specific role, or a specific API call | 15:20 |
| knikolla | sorry for the delay, i'm trying to collect my thoughts so i can give a clear answer | 15:22 |
| h_asahina | It's ok. | 15:22 |
| h_asahina | I think so too. And I guess the standard doesn't prohibit that. | 15:23 |
| knikolla | to conform to the standard you only need to make sure that you're able to authenticate using client credentials, and creation of the client credentials is not covered by the standard, is that correct? | 15:24 |
| h_asahina | Yes. I think so. | 15:24 |
| h_asahina | So, it depends on the implementation of the authorization server. | 15:25 |
| knikolla | yes, and the oauth 2.0 standard is very relaxed on that. | 15:25 |
| h_asahina | yeah, and it is easy for me to use the existing application credentials. | 15:27 |
| redrobot | Sounds like you have a path forward h_asahina | 15:27 |
| redrobot | ? | 15:27 |
| h_asahina | sorry, what do you mean? | 15:29 |
| redrobot | h_asahina you have an answer to your question? | 15:30 |
| knikolla | i'll also respond to your comments on the review in more details | 15:31 |
| h_asahina | I got it. Yes. I have my answer, but I'd like to confirm it. | 15:31 |
| knikolla | it does feel a bit like a workaround | 15:31 |
| knikolla | but that is because oauth allows for clients which are not users, whereas for us, these credentials would be mapped to a user | 15:32 |
| knikolla | so there isn't an exact parallel | 15:32 |
| knikolla | the exact parallel would be with OAuth 2.0 Resource Owner Password Credentials grant | 15:32 |
| knikolla | which uses the user's credential to authenticate a client on behalf of the user | 15:33 |
| h_asahina | strictly speaking, we need a new feature that makes clients as a resource owner. | 15:34 |
| knikolla | the way i have usually understood clients in oauth, is that their credentials don't effectively give any authorization, except maybe allowing them to receive a token after authentication of a user. | 15:34 |
| knikolla | yes, but in keystone not even a user is a resource owner. a project is. | 15:36 |
| knikolla | and in oauth, the way a client accesses a user's resources is through that user's access token. and to get that access token, is why a client needs their client credentials (for the authorization code flow, or to refresh the token) | 15:37 |
| h_asahina | Like you said, in Openstack, a user is not a resource owner, which means it is also impossible for clients to be a resource owner. | 15:41 |
| h_asahina | And, someone has to create client credentials even the client credentials grant. | 15:42 |
| h_asahina | That one must be a user. So, naturally, workaround you mentioned is the most realistic way. right? | 15:43 |
| knikolla | yeah, and in keystone even services (like tacker, nova, neutron, etc) are users. rather than being clients. | 15:43 |
| knikolla | so to me it makes sense. | 15:43 |
| h_asahina | Thanks, I wanted to save the consensus. And, interpretation about OAuth2.0 you described matches my interpretation. | 15:44 |
| h_asahina | I have one more question. | 15:45 |
| knikolla | And I really like the idea of allowing normal keystone tokens to be treated like OAuth 2.0 tokens and validated in a conforming API. | 15:45 |
| knikolla | Because it opens the door for other applications to possibly use keystone as an authorization server. | 15:45 |
| h_asahina | I also agree with that. | 15:46 |
| h_asahina | So, I'll remove sentences that mention the token type from the spec. | 15:47 |
| h_asahina | Although you asked about the OAuth2.0 use case in Tacker, I also want to hear what use cases you envision. | 15:49 |
| h_asahina | in keystone. | 15:49 |
| h_asahina | I mean your comments on the spec. | 15:50 |
| knikolla | You mean what use we could have for this work outside of the Tacker use case? | 15:51 |
| h_asahina | yes | 15:51 |
| h_asahina | I feel I need to understand what you want OAuth2.0 to be to answer your comments correctly. | 15:53 |
| redrobot | 5 minute warning :) | 15:54 |
| knikolla | For example, if we add support for keystone to validate token using a oauth 2.0 token endpoint conforming API, we could have other applications use keystone to protect their API. And we could have keystonemiddleware check for the authorization header, rather than x-auth-token header, so other oauth services could use keystone as well. but also keystonemiddleware could use something besides keystone. | 15:55 |
| knikolla | so you could possibly have keystonemiddleware use keycloak to validate tokens. | 15:55 |
| knikolla | of course we're not there yet. but to me it's important that the steps we take, don't prevent us from moving in that general direction of being more interoperable outside of openstack. | 15:56 |
| h_asahina | ok, I'll keep that in mind. I'd like to talk more but we don't have time. | 15:58 |
| knikolla | please feel free to ping me on irc whenever you want to chat or have questions. or send me an email. | 15:58 |
| h_asahina | Thank you. also, thank you for taking your time. I'd really appreaciate that. | 15:59 |
| knikolla | thank you for your work too. | 15:59 |
| redrobot | Thanks for the great discussion y'all. | 15:59 |
| redrobot | That's all the time we have for today. | 15:59 |
| redrobot | #endmeeting | 15:59 |
| opendevmeet | Meeting ended Tue Nov 30 15:59:58 2021 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 15:59 |
| opendevmeet | Minutes: https://meetings.opendev.org/meetings/keystone/2021/keystone.2021-11-30-15.00.html | 15:59 |
| opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/keystone/2021/keystone.2021-11-30-15.00.txt | 15:59 |
| opendevmeet | Log: https://meetings.opendev.org/meetings/keystone/2021/keystone.2021-11-30-15.00.log.html | 15:59 |
| *** whoami-rajat__ is now known as whoami-rajat | 16:20 | |
| *** xek_ is now known as xek | 16:48 | |
| gmann | lbragstad: can you please check my reply on this https://review.opendev.org/c/openstack/keystone/+/818624/comment/5b9c40fe_7f0e7826/ | 18:30 |
| gmann | lbragstad: these warning tests verified in tests are different for oslo.policy <3.10 and >=3.10 that is why i used assertIn | 18:30 |
| gmann | I can make those assert explicitly as you suggested but that need to bump oslo.policy version to 3.10 in keystone because of this tests only | 18:32 |
| lbragstad | gmann ack - right now we're using 3.7 | 18:33 |
| lbragstad | bumping to 3.10 shouldn't be an issue i don't think | 18:33 |
| gmann | lbragstad: ok. once 818624 merge and requirement patch (https://review.opendev.org/c/openstack/requirements/+/815820) merge then I will push in keystone | 18:34 |
| lbragstad | gmann excellent - thanks! | 18:36 |
| opendevreview | Ghanshyam proposed openstack/keystone master: Explicitly check policy name in policy warning tests https://review.opendev.org/c/openstack/keystone/+/819916 | 19:08 |
| gmann | lbragstad: done ^^. can you approve this now so that we cna merge the requriement patch https://review.opendev.org/c/openstack/keystone/+/818624 | 19:10 |
| lbragstad | gmann done | 19:11 |
| gmann | lbragstad: thanks | 19:18 |
| opendevreview | Merged openstack/keystone master: Fix oslo policy warning assert in unit tests https://review.opendev.org/c/openstack/keystone/+/818624 | 20:34 |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!