15:00:58 <dmendiza[m]> #startmeeting keystone
15:00:58 <opendevmeet> Meeting started Tue Aug  2 15:00:58 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:58 <opendevmeet> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:00:58 <opendevmeet> The meeting name has been set to 'keystone'
15:01:11 <dmendiza[m]> #topic Roll Call
15:01:18 <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:27 <dmendiza[m]> as usual the agenda is over here:
15:01:30 <dmendiza[m]> #link https://etherpad.opendev.org/p/keystone-weekly-meeting
15:03:12 <h_asahina> o/
15:03:23 <xek> o/
15:04:12 <dmendiza[m]> OK, let's get started
15:04:13 <dmendiza[m]> #topic Review Past Meeting Action Items
15:04:22 <dmendiza[m]> #link https://meetings.opendev.org/meetings/keystone/2022/keystone.2022-07-26-15.00.html
15:04:27 <dmendiza[m]> We didn't have any...
15:04:37 <dmendiza[m]> #topic Liaison Updates
15:04:42 <dmendiza[m]> I don't have any updates this week...
15:04:54 <dmendiza[m]> #topic Secure RBAC
15:05:08 <dmendiza[m]> I tried to join the pop-up meeting today, but I don't think it actually happened.
15:06:02 <dmendiza[m]> No updates on the "manager" role or the "service" role specs ...
15:06:37 <dmendiza[m]> #topic OAuth 2.0
15:06:42 <dmendiza[m]> h_asahina: any updates this week?
15:06:53 <h_asahina> I've updated spec.
15:07:04 <h_asahina> https://review.opendev.org/c/openstack/keystone-specs/+/843765
15:07:41 <h_asahina> please kindly review it again.
15:08:06 <h_asahina> ah, xek has already replied.
15:08:15 <h_asahina> thanks
15:08:55 <h_asahina> Also, I'd like to ask that can Yoga OAuth2.0 patch be mereged in Zed?
15:09:23 <knikolla> o/
15:09:28 <dmendiza[m]> Hi knikolla
15:10:05 <dmendiza[m]> h_asahina: we did review the spec last Friday, but I don't think knikolla has had a chance to leave feedback.
15:10:19 <dmendiza[m]> One thing that was not clear was how much of the mTLS is going to be done by the web server
15:10:38 <dmendiza[m]> Keystone is typically deployed behind Apache
15:10:43 <dmendiza[m]> so the mTLS heavy-lifting could be done by Apache
15:11:08 <h_asahina> In my understanding, verification of trust chain is done by apache.
15:11:08 <dmendiza[m]> Apache can be configured to provide the cert in a header
15:12:10 <h_asahina> what we have to do is just checking whether cert matches to one that stored in DB and binding the cert to a issued OAuth2.0 token.
15:12:30 <dmendiza[m]> OK, cool, I think we're all on the same page then
15:13:24 <h_asahina> that's good. knikolla: if you have additional comments I can further revise the spec.
15:13:26 <dmendiza[m]> h_asahina: maybe it would be good to update the spec to clarify that cert chain validation will be done by the web server
15:13:45 <h_asahina> that makes sense. I'll do that.
15:14:47 <dmendiza[m]> > can Yoga OAuth2.0 patch be mereged in Zed?
15:14:55 <dmendiza[m]> I'm not sure what patch you're talking about?
15:15:33 <h_asahina> https://review.opendev.org/c/openstack/keystoneauth/+/830734
15:15:39 <h_asahina> https://review.opendev.org/c/openstack/keystonemiddleware/+/830737
15:15:46 <h_asahina> https://review.opendev.org/c/openstack/keystone/+/830739
15:16:06 <h_asahina> The last one already has +1.
15:16:12 <knikolla> sorry, didn't have time to leave the feedback that we discussed on Friday
15:16:42 <knikolla> it basically boils down to: if we are leaving the verification to be done by Apache, and the CA is trusted, we don't need to use the credentials API at all.
15:16:54 <knikolla> We can get this to work similarly to how federation works
15:17:21 <knikolla> If apache lets the user in to a specific endpoint, then the user is issued a token
15:17:36 <knikolla> All we have to do is make that endpoint look and work like OAuth
15:18:13 <knikolla> The token that that endpoint issues can be bound to the thumbprint of the cert used to issue it
15:18:39 <h_asahina> but apache can't confirm that the cert has DN that registered to Keystone in advance.
15:18:55 <knikolla> if you control the CA you control what certs it issues.
15:19:26 <knikolla> You can have apache limit it to a specific group of DNs, I think.
15:20:06 <h_asahina> I see. we can limit who can get certs via CA and also apache is capable to limit it with DN.
15:20:17 <h_asahina> that you meant?
15:20:19 <knikolla> yes
15:21:04 <h_asahina> to be honest, we don't know that apache's feature. but if it's possible that's much easier to implement.
15:21:12 <knikolla> This makes it significantly easier to implement, yes
15:21:36 <h_asahina> we'll check apache's option
15:21:49 <h_asahina> and if we can confirm it works, i'll revise the spec.
15:21:50 <knikolla> Take a look at how federation works
15:22:05 <h_asahina> okey. thank you.
15:22:18 <h_asahina> thanks for the info.
15:22:38 <knikolla> The user has to get through apache and go to a specific endpoint. In that endpoint, keystone loads up the environment variables that apache adds and maps the user to a user.
15:22:53 <knikolla> And issues a token.
15:23:18 <h_asahina> the endpoin you mentioned is token issuing endpoin?
15:23:21 <xek> doesn't the RFE have a requirement to register the DN or other identifier first?
15:23:32 <xek> I don't have it on hand
15:23:43 <knikolla> no, it's the federation endpoint
15:23:50 <knikolla> under OS-FEDERATION
15:24:55 <knikolla> https://docs.openstack.org/keystone/latest/admin/federation/introduction.html
15:25:08 <knikolla> xek: good question.
15:25:32 <knikolla> but I don't think the API specifices the mechanism to register the DNs
15:25:33 <xek> https://www.rfc-editor.org/rfc/rfc8705.html#section-2.1.2
15:26:07 <xek> it references the  OAuth 2.0 Dynamic Client Registration Protocol  which I'm not familiar with
15:28:05 <h_asahina> in section 2.1
15:28:07 <xek> maybe it's only for the self-signed certs
15:28:09 <h_asahina> The PKI (public key infrastructure) method of mutual-TLS OAuth client
15:28:11 <h_asahina> authentication adheres to the way in which X.509 certificates are
15:28:13 <h_asahina> traditionally used for authentication.  It relies on a validated
15:28:15 <h_asahina> certificate chain [RFC5280] and a single subject distinguished name
15:28:17 <h_asahina> (DN) or a single subject alternative name (SAN) to authenticate the
15:28:19 <h_asahina> client.Y
15:28:50 <knikolla> h_asahina: is conformance to the dynamic client registration RFC a requirement for ETSI NFV?
15:29:08 <h_asahina> no
15:29:33 <h_asahina> but the above is rfc8705
15:30:56 <xek> ok, so as I understand it, the registration would be only required for self signed certs
15:31:16 <knikolla> I think the spec requires that the DN of the cert be "expected" and match to only 1 client.
15:31:33 <knikolla> We can make those guarantees.
15:32:00 <h_asahina> by apache?
15:32:40 <knikolla> "The client is successfully authenticated if the subject information in the certificate matches the single expected subject configured or registered for that particular client"
15:33:12 <knikolla> I think it means that one client can only have one subject name and no others
15:33:43 <dmendiza[m]> Would it make sense to require the DN or SAN to match the username in Keystone? 🤔
15:34:06 <knikolla> I think that's how we make that guarantee, yes.
15:34:13 <knikolla> The presence of the user signifies "registration"
15:35:20 <h_asahina> in that case, an OAuth2.0 client means a openstack user, right?
15:36:15 <knikolla> yes
15:36:25 <h_asahina> need to confirm that maches to our usecase
15:36:43 <h_asahina> maybe we need to separate users and `OAuth clients`
15:37:03 <knikolla> I'm really hesitant to do that
15:37:16 <knikolla> Nothing else in OpenStack will ever use OAuth clients
15:37:25 <knikolla> and we will be introducing an entire API just for this use case
15:37:50 <h_asahina> yeah, I remember what you said before
15:38:05 <h_asahina> OpenStack doesn't have features to manage clients, but uses.
15:38:13 <h_asahina> /uses/users/
15:38:22 <knikolla> yeah
15:39:00 <h_asahina> I'll see what we can do.
15:39:26 <h_asahina> I feel your suggestion will work for our usecase.
15:39:48 <h_asahina> intuitively
15:40:14 <knikolla> Great, let me know.
15:40:36 <h_asahina> got it. I'll reply on spec or next meeting.
15:40:46 <knikolla> I'm just trying to fulfill your use case in the path that creates the least amount of maintenance and work for the team.
15:41:03 <knikolla> In a lot of cases, we already have similar mechanisms that can be adapted, like here.
15:41:28 <knikolla> When that is no longer the case, we can start considering bigger changes
15:41:41 <h_asahina> I see. thank you for you suggestion.
15:42:07 <h_asahina> okey. I'd like to confirm Yoga patches.
15:42:12 <h_asahina> can I do that?
15:43:08 <h_asahina> I mean Yoga patches status.
15:43:40 <dmendiza[m]> h_asahina: I was confused because they're not "yoga" patches.  They're patches for the "master" branch, not "stable/yoga"
15:43:54 <dmendiza[m]> I'll add them to the reivews on Friday
15:43:57 <dmendiza[m]> for the Reviewathon
15:44:20 <dmendiza[m]> when they merge they will merge to "master" branch, which is currently Zed
15:44:38 <h_asahina> you're right. sorry.
15:45:49 <h_asahina> thank you for considering add them to reviewathon
15:46:13 <h_asahina> at least, we want to merge them within Zed cycle
15:46:33 <h_asahina> even if merging mTLS OAuth2.0 is not possible.
15:47:17 <h_asahina> sorry for taking a lot of time, but I'd like to confirm one more thing quickly.
15:47:33 <h_asahina> regarding mTLS patches, keystonemiddleware will depend on  keystoneauth1, i.e.,  mTLS keystonemiddleware will  not work properly if it is merged before keystoneauth1 is merged.
15:47:50 <h_asahina> In other words, it will have Cross repository dependencies
15:48:20 <h_asahina> and we're planing to use `Depends-On:` to handle it
15:48:40 <h_asahina> Do you have any other options?
15:49:19 <knikolla> Depends-On seems fine in this case
15:49:50 <h_asahina> that what you want to hear. thanks.
15:50:19 <h_asahina> that's all from my side. thank you for valuable adivce and discussion.
15:51:44 <dmendiza[m]> Thanks, h_asahina
15:51:48 <dmendiza[m]> Ok, we've only got a few minutes left
15:51:53 <dmendiza[m]> #topic Open Discussion
15:51:59 <dmendiza[m]> Anything else y'all want to talk about?
15:53:43 <noonedeadpunk> I was kind of wondering on proggress about the bug https://bugs.launchpad.net/keystone/+bug/1959674 Did anybody had a chance to dig into why application_Credentials do such weird things or this can be jsut safely dropped?
15:54:51 <dmendiza[m]> noonedeadpunk: I don't think anyone has looked into it
15:55:12 <noonedeadpunk> jsut fix is super trivial from the first sight
15:55:38 <noonedeadpunk> but I'm really afraid about just doing it as I can imagine some intention behind
15:55:39 <dmendiza[m]> We'd be happy to review a patch if you want to make one
15:56:48 <noonedeadpunk> ok, gotcha then will push it soon
15:57:17 <dmendiza[m]> Thanks, noonedeadpunk
15:57:41 <dmendiza[m]> Cool, that's about all the time we have for today
15:57:46 <dmendiza[m]> thanks for joining, eveyrone!
15:57:52 <dmendiza[m]> #endmeeting