15:00:41 <redrobot> #startmeeting keystone
15:00:41 <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:41 <opendevmeet> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:00:41 <opendevmeet> The meeting name has been set to 'keystone'
15:01:48 <redrobot> #topic Roll Call
15:01:54 <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:02:06 <knikolla> o/
15:02:18 <redrobot> Hi knikolla
15:03:48 <redrobot> #topic Review Past Meeting Action Items
15:03:50 <redrobot> #link https://meetings.opendev.org/meetings/keystone/2021/keystone.2021-11-16-15.04.html
15:03:53 <redrobot> We didn't have any
15:04:28 <redrobot> #topic Liaison Updates
15:04:33 <redrobot> knikolla any updates for today?
15:04:45 <gagehugo> o/
15:04:57 <gagehugo> I am double booked today
15:06:10 <knikolla> no updates on my side, i've not had a lot of time to do things keystone-side.
15:06:58 <redrobot> gotcha, thanks knikolla
15:07:07 <redrobot> gagehugo no worries, lbragstad is double booked as well
15:07:49 <redrobot> #topic OAuth 2.0
15:07:58 <redrobot> #link https://review.opendev.org/c/openstack/keystone-specs/+/813152
15:08:09 <h_asahina> o/
15:08:30 <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:31 <redrobot> hi h_asahina
15:09:15 <redrobot> h_asahina do you want to give an update on the spec?
15:09:34 <h_asahina> Yes. I just replied to knikolla's comments, I'd like to discuss about it if you don't mind.
15:10:00 <redrobot> h_asahina go ahead
15:10:38 <h_asahina> knikolla suggestted that using the application creadentials and wrap it with OAuth2.0 client credentials APIs
15:11:23 <h_asahina> I basically agree with that idea, but I think I have to confirm some points.
15:12:38 <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:47 <h_asahina> Is that ok for keystone?
15:13:57 <redrobot> knikolla ^^^
15:14:09 <knikolla> yeah, i think so
15:15:15 <h_asahina> ok. that's good.
15:16:08 <h_asahina> You also mentioned that the client credentials is not a feature to delegate users' roles to client.
15:17:41 <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:20:03 <knikolla> good question
15:20:39 <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:22:19 <knikolla> sorry for the delay, i'm trying to collect my thoughts so i can give a clear answer
15:22:38 <h_asahina> It's ok.
15:23:32 <h_asahina> I think so too. And I guess the standard doesn't prohibit that.
15:24:33 <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:59 <h_asahina> Yes. I think so.
15:25:27 <h_asahina> So, it depends on the implementation of the authorization server.
15:25:49 <knikolla> yes, and the oauth 2.0 standard is very relaxed on that.
15:27:12 <h_asahina> yeah, and it is easy for me to use the existing application credentials.
15:27:45 <redrobot> Sounds like you have a path forward h_asahina
15:27:46 <redrobot> ?
15:29:25 <h_asahina> sorry, what do you mean?
15:30:33 <redrobot> h_asahina you have an answer to your question?
15:31:31 <knikolla> i'll also respond to your comments on the review in more details
15:31:42 <h_asahina> I got it. Yes. I have my answer, but I'd like to confirm it.
15:31:56 <knikolla> it does feel a bit like a workaround
15:32:27 <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:34 <knikolla> so there isn't an exact parallel
15:32:54 <knikolla> the exact parallel would be with OAuth 2.0 Resource Owner Password Credentials grant
15:33:26 <knikolla> which uses the user's credential to authenticate a client on behalf of the user
15:34:50 <h_asahina> strictly speaking, we need a new feature that makes clients as a resource owner.
15:34:56 <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:36:46 <knikolla> yes, but in keystone not even a user is a resource owner. a project is.
15:37:39 <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:41:31 <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:42:18 <h_asahina> And, someone has to create client credentials even the client credentials grant.
15:43:13 <h_asahina> That one must be a user. So, naturally, workaround you mentioned is the most realistic way. right?
15:43:34 <knikolla> yeah, and in keystone even services (like tacker, nova, neutron, etc) are users. rather than being clients.
15:43:39 <knikolla> so to me it makes sense.
15:44:41 <h_asahina> Thanks, I wanted to save the consensus. And, interpretation about OAuth2.0 you described matches my interpretation.
15:45:09 <h_asahina> I have one more question.
15:45:29 <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:49 <knikolla> Because it opens the door for other applications to possibly use keystone as an authorization server.
15:46:13 <h_asahina> I also agree with that.
15:47:13 <h_asahina> So, I'll remove sentences that mention the token type from the spec.
15:49:28 <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:35 <h_asahina> in keystone.
15:50:50 <h_asahina> I mean your comments on the spec.
15:51:50 <knikolla> You mean what use we could have for this work outside of the Tacker use case?
15:51:59 <h_asahina> yes
15:53:02 <h_asahina> I feel I need to understand what you want OAuth2.0 to be to answer your comments correctly.
15:54:32 <redrobot> 5 minute warning :)
15:55:18 <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:37 <knikolla> so you could possibly have keystonemiddleware use keycloak to validate tokens.
15:56:04 <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:58:13 <h_asahina> ok, I'll keep that in mind. I'd like to talk more but we don't have time.
15:58:41 <knikolla> please feel free to ping me on irc whenever you want to chat or have questions. or send me an email.
15:59:16 <h_asahina> Thank you. also, thank you for taking your time. I'd really appreaciate that.
15:59:34 <knikolla> thank you for your work too.
15:59:45 <redrobot> Thanks for the great discussion y'all.
15:59:52 <redrobot> That's all the time we have for today.
15:59:58 <redrobot> #endmeeting