15:11:28 <dmendiza[m]> #startmeeting keystone
15:11:28 <opendevmeet> Meeting started Tue Jul  5 15:11:28 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:11:28 <opendevmeet> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:11:28 <opendevmeet> The meeting name has been set to 'keystone'
15:11:35 <dmendiza[m]> #topic Roll Call
15:11:55 <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:12:00 <knikolla> o/
15:12:14 <d34dh0r53> o/ sorry for being late
15:13:06 <dmendiza[m]> No worries, I was late too 😅
15:13:12 <dmendiza[m]> OK, let's get started
15:13:16 <h-asahina> o/
15:13:21 <dmendiza[m]> #topic Review Past Meeting Action Items
15:13:35 <dmendiza[m]> #link https://meetings.opendev.org/meetings/keystone/2022/keystone.2022-06-28-15.00.html
15:13:41 <dmendiza[m]> I did not do the thing
15:13:48 * dmendiza[m] kicks can down the road again
15:14:02 <dmendiza[m]> #action dmendiza[m] to try to run keystone from a fresh clone
15:14:16 <dmendiza[m]> Moving on ...
15:14:22 <dmendiza[m]> #topic Liaison Updates
15:15:32 <dmendiza[m]> I don't have any updates
15:15:40 <dmendiza[m]> #topic Oauth 2.0
15:16:04 <dmendiza[m]> h_asahina around?
15:16:08 <h-asahina> yes
15:16:15 <dmendiza[m]> Hi
15:16:20 <dmendiza[m]> Do you want to talk about your agenda topic?
15:16:32 <h-asahina> yes
15:16:34 <dmendiza[m]> >     The way of binding a client certificate to OAuth2.0 access token (h-asahina)
15:16:45 <h-asahina> thanks that's my topic
15:17:08 <h-asahina> I feel we have to confirm the way to bind a client certificate to an access token
15:17:37 <h-asahina> I think we have two options
15:18:04 <h-asahina> A) adding the information of cert (e.g., DN/thumbprint) to fernet/JWT token.
15:18:40 <h-asahina> B) adding a new DB table consisting of the information of cert and corresponding token that is bound to the certificate
15:19:02 <h-asahina> IMO, The straight forward way is A.
15:19:20 <knikolla> does the oauth mtls rfc require a bearer token be bound to a certificate?
15:20:24 <h-asahina> I think so. rfc8705 defines that case.
15:20:50 <h-asahina> https://datatracker.ietf.org/doc/html/rfc8705
15:21:59 <knikolla> ah, it's in the rfc title. "certificate-bound access tokens"
15:22:25 <h-asahina> yeah
15:23:13 <h-asahina> that's why I consider this as a fundamental requiremnt.
15:23:25 <knikolla> "
15:23:25 <knikolla> Mutual-TLS certificate-bound access tokens and mutual-TLS client authentication are distinct mechanisms that are complementary but don't necessarily need to be deployed or used together."
15:23:43 <knikolla> The rfc introduces both as separate mechanisms
15:24:24 <h-asahina> that menas the client authentication and binding token to certificate are separated process.
15:26:02 <h-asahina> in any case, to follow the rfc, token should be bound to the client certificate
15:26:58 <knikolla> i understand
15:27:05 <h-asahina> for instance, during the token introspection, thumbprint of the certificate is used to confirm the authenticity of the client.
15:27:16 <knikolla> i'd definitely favor approach A
15:27:30 <h-asahina> so do I
15:27:46 <h-asahina> but to do so, we need to modify the token payload class
15:28:03 <h-asahina> https://github.com/openstack/keystone/blob/master/keystone/token/token_formatters.py#L222-L225
15:28:19 <h-asahina> Specifically, args of the token payload
15:28:57 <h-asahina> because it is designed to only accept some predefined parameters.
15:29:12 <knikolla> yes
15:29:40 <h-asahina> there many places calling this class, so we have to change many parts, is that okey?
15:29:58 <d34dh0r53> I'm not sure that it is required per "Other methods of associating a
15:30:00 <d34dh0r53> certificate with an access token are possible, per agreement by the
15:30:02 <d34dh0r53> authorization server and the protected resource, but are beyond the
15:30:04 <d34dh0r53> scope of this specification.
15:31:13 <knikolla> d34dh0r53: yeah, you can only choose to support mtls for authentication, without bounding. But my understanding is that h-asahina requires the full implementation of the RFC for NFV certification?
15:31:27 <knikolla> you can choose to only*
15:31:37 <d34dh0r53> ahh, good point
15:32:35 <h-asahina> what knikolla: said is right. we need to implement it.
15:33:07 <d34dh0r53> ok
15:33:36 <h-asahina> I think adding an additional parameters to token payload won't ruin the Keystone functionalities.
15:34:10 <h-asahina> but if you can't accept it or if you have any alternative ideas, please let me know
15:34:28 <knikolla> I think I'm okay with it. But I'm not a cryptography expert.
15:34:37 <d34dh0r53> no, I think I'm ok, I just got hung up on the word required
15:35:36 <knikolla> d34dh0r53: based on my prior experience reading OAuth 2.0 specs, nothing is required, everything is optional, and hence everything is a confusing mess of who supports what.
15:36:32 <d34dh0r53> knikolla: lol, sounds about right
15:37:03 <h-asahina> that's what's giving me a headache when writing specs.
15:37:38 <h-asahina> netheir i'm expert for crypto
15:38:20 <h-asahina> but, as you know, the fernet is encrypted by the secret key of Keystone, there's no impact on the security if we add fields to the payload
15:39:01 <knikolla> yeah, just need to be careful with not putting too much stuff in there due to increasing size.
15:39:20 <h-asahina> sure
15:39:47 <knikolla> i guess it's not a concern here, since a thumbprint would be pretty small
15:40:18 <h-asahina> yes. that's right.
15:40:40 <h-asahina> okey. I'll go with the option A
15:41:36 <dmendiza[m]> Sounds good
15:41:39 <h-asahina> btw, the dead line of spec is 14 July, right? can we make it?
15:42:23 <h-asahina> https://releases.openstack.org/zed/schedule.html#z-2
15:42:26 <dmendiza[m]> I hope so. 🤞  We'll review the spec again on Friday for the Reviewathon
15:43:16 <knikolla> yeah, should be fine. worst case we may grant an exception/extensions.
15:43:28 <h-asahina> great. thanks a lot.
15:43:46 <dmendiza[m]> OK, moving on
15:43:50 <dmendiza[m]> #topic Secure RBAC
15:44:13 <dmendiza[m]> I still feel a bit out of the loop on the latest SRBAC happenings.  I'll have to catch up with gmann soon.
15:44:56 <dmendiza[m]> #link https://governance.openstack.org/tc/goals/selected/consistent-and-secure-rbac.html#z-release-timeline
15:45:04 <dmendiza[m]> We're still on the hook for:
15:45:04 <knikolla> my understanding is that we're keeping "project admin is global admin" and holding off on any system scope things.
15:45:13 <dmendiza[m]> > Keystone starts implementing support for manager across project, domain, and system scopes.
15:45:26 <knikolla> so we need to make sure our new policies work with project-admin for global admin operations
15:45:34 <dmendiza[m]> gotcha
15:45:36 <dmendiza[m]> I can work on that
15:45:49 <knikolla> and for actual project level admin operations, support manager
15:46:17 <dmendiza[m]> Yeah, I think the patch for the "manager" role was stalled on whether we're handling existing "manager" roles appropriately
15:46:32 <dmendiza[m]> I'll add that to my TODO list
15:47:00 <knikolla> I think a strongly worded release note and upgrade note should do the trick
15:47:20 <dmendiza[m]> Hehe, yeah, that should be the minimum
15:47:44 <dmendiza[m]> I was think maybe keystone-boostrap could throw an error if it finds an existing "manager" role?
15:48:00 <knikolla> I'd look at what we did for the "reader" role
15:48:02 <knikolla> when we introduced it
15:48:08 <knikolla> and just repeat the same
15:48:36 <knikolla> initially keystone didn't mandate any roles (except admin), and then we introduced member and reader
15:48:43 <knikolla> so the process that we followed then, can be the same
15:48:53 <dmendiza[m]> sounds good
15:50:09 <knikolla> i think throwing an error on the existence of a manager role is going to be hard, given that bootstrap is supposed to be idempotent
15:51:11 <knikolla> but also, i'm not sure that "bootstrap" is something that we tell people to run after their initial setup
15:53:27 <dmendiza[m]> Looks like we tell folks to `keystone-manage bootstrap` in the installation guides:
15:53:28 <dmendiza[m]> #link https://docs.openstack.org/keystone/latest/install/index.html
15:54:34 <dmendiza[m]> In any case, I'll do the needful to make sure we're on track for Keystone's SRBAC
15:55:48 <dmendiza[m]> Not sure we have enough time to talk about any other specs
15:55:54 <dmendiza[m]> So let's call it a meeting.
15:56:01 <dmendiza[m]> Thanks for joining, y'all.
15:56:10 <dmendiza[m]> #endmeeting