15:02:06 <dmendiza[m]> #startmeeting keystone
15:02:06 <opendevmeet> Meeting started Tue Aug  9 15:02:06 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:02:06 <opendevmeet> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:02:06 <opendevmeet> The meeting name has been set to 'keystone'
15:02:12 <dmendiza[m]> #topic Roll Call
15:02:33 <xek> o/
15:02:41 <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:02:49 <dmendiza[m]> Hi Grzegorz Grasza !
15:02:56 <knikolla> o/
15:03:27 <d34dh0r53> o/
15:03:30 <h_asahina> o/
15:04:14 <dmendiza[m]> HI everyone!
15:04:21 <dmendiza[m]> OK, let's get started ...
15:04:27 <dmendiza[m]> #topic Review Past Meeting Action Items
15:04:53 <dmendiza[m]> #link https://meetings.opendev.org/meetings/keystone/2022/keystone.2022-08-02-15.00.html
15:04:56 <dmendiza[m]> We didn't havea ny
15:04:59 <dmendiza[m]> *have any
15:05:15 <dmendiza[m]> Moving on ...
15:05:19 <dmendiza[m]> #topic Liaison Updates
15:05:34 <dmendiza[m]> No updates I can think of right now ... 🤔
15:05:52 <dmendiza[m]> #topic OAuth 2.0
15:05:56 <dmendiza[m]> HI h_asahina !
15:06:00 <h_asahina> hi
15:06:08 <dmendiza[m]> Any updates for this week?
15:06:37 <h_asahina> i'd like to discuss about mapping between DN and Keystone user's attributes
15:06:45 <h_asahina> https://review.opendev.org/c/openstack/keystone-specs/+/843765
15:07:37 <h_asahina> I replied your comment
15:08:39 <h_asahina> you suggested mapping UID and DC to Keystone username and domain_name
15:08:49 <h_asahina> and enforce that rule to CA
15:09:31 <h_asahina> but I think we can't always enfoce that rule to CA
15:09:55 <h_asahina> maybe CA want to use these fields for another purpose
15:10:28 <h_asahina> the border of tenant might be not domain_name, but project_id
15:11:17 <h_asahina> so, if we try to map DN fields to Keystone users' attributes, we have to add configuration for such mapping
15:11:19 <dmendiza[m]> Yeah, User IDs are unique
15:13:48 <dmendiza[m]> I suppose we could make that configurable ...
15:14:52 <h_asahina> but adding such configuration makes it a little bit complicated
15:15:09 <knikolla> We could tie this up to federation mappings, I guess.
15:15:25 <knikolla> This way the operator decides which attributes to use for what.
15:16:01 <knikolla> x509 seems to do the same https://docs.openstack.org/keystone/latest/admin/configure_tokenless_x509.html#create-a-map
15:16:01 <h_asahina> that makes sense, but to be honest I feel storing entire DN to credentials API is much simpler.
15:20:21 <h_asahina> do you think it's possible to use https://docs.openstack.org/keystone/latest/admin/configure_tokenless_x509.html#create-a-map directly for this purpose? knikolla:
15:20:31 <knikolla> Simpler, but you have to add each users DN to credentials API, which seems like an unnecessary step.
15:20:58 <knikolla> I think it shouldn't be hard to extend the same code used for that to look more like OAuth
15:21:50 <h_asahina> if we don't use credentials API, we still have to add a user.
15:22:37 <knikolla> Yes
15:23:08 <knikolla> But with that you can also support the use case where presenting the certificate to keystone is what registers the user
15:23:19 <knikolla> like with federation. though i don't think that's a requirement or desirable for you.
15:25:43 <h_asahina> I mean from the user's view, making a user and making a credential is not different.
15:27:57 <h_asahina> maybe I don't understand motivation behind using User API
15:28:14 <knikolla> the user can't make the credential, he has to request one from the CA
15:30:46 <h_asahina> could please elaborate on that?
15:31:05 <h_asahina> I understand it's like federation
15:31:24 <h_asahina> so if we say `credential` that should be managed by CA
15:31:57 <h_asahina> but what user have to do actually is to register its DN (or part of DN) to Keystone
15:32:00 <knikolla> For a user to authenticate to keystone using mtls (using the proposed credentials api) these are the required steps. 1) operator registers user 2) user gets a certificate from CA that operator sets up (PKI) 3) user uploads credential received from CA 4) user authenticates
15:32:43 <knikolla> step 3 runs into a chicken and egg issue with the user not having registered a trusted cert yet, therefore being unable to authenticate (especially if the entire of keystone is protected from mTLS)
15:33:15 <knikolla> so it makes sense to not require step 3, since the certificate is already coming from a trusted CA
15:34:25 <knikolla> does this make sense so far?
15:35:14 <h_asahina> I see. user who register credential itself has to be authenticated by CA, but if we use credentials api it's not possible.
15:35:43 <h_asahina> or I should say it's contradicted
15:36:56 <h_asahina> if we use User API, that means all user will be authenticated by CA, so such contradiction won't occur.
15:37:00 <h_asahina> am I correct?
15:38:53 <knikolla> yes, there are multiple way to not require uploading a credential for each user
15:39:14 <knikolla> they involve some mechanism to map a cert's attributes to a user
15:39:27 <knikolla> This is already done for all federation mechanisms via federation mappings
15:41:18 <knikolla> It might also be of interest to see how LDAP maps into a user
15:41:30 <knikolla> (which is a different method from federation)
15:41:34 <h_asahina> let me confirm. I think we can authenticate users with their id/password even if we use mutual TLS.
15:42:06 <h_asahina> I mean user can authenticate without registering their cert in advance.
15:42:30 <h_asahina> and then register the cert corresponding to the OAuth2.0 client to credentials API
15:43:02 <knikolla> What would happen if another user registers the same thumbprint?
15:43:04 <h_asahina> I think it's possible to ignore a chiken and egg issue you mentioned by the above step. but meaningless
15:43:06 <h_asahina> right?
15:45:50 <knikolla> You'd need to provide a mechanism for verifying that the user is in possession of the private part to prevent DN squatting
15:46:03 <knikolla> So it's not exactly as easy as just registering the public part
15:47:08 <h_asahina> yes. in the above step untrusted user can register thumbprint
15:47:33 <h_asahina> that makes checking DN itself meaningless
15:49:47 <knikolla> from my point of view, the mapping mechanism with federation mappings makes for sense and is already used by other cert/assertion/saml authentication methods
15:50:12 <h_asahina> okey. we'll try to transplant the mapping of federation to our case.
15:50:15 <knikolla> we also have an API now for pre-creating federated users https://specs.openstack.org/openstack/keystone-specs/specs/keystone/ussuri/support-federated-attr.html
15:51:50 <h_asahina> is this something like feature that we can reuse existing users for federation?
15:52:04 <knikolla> yes
15:52:46 <knikolla> you can patch an already existing user to be a federated user
15:53:12 <h_asahina> I see. i'm not sure it suitable for our use case now, but will check it. thanks.
15:54:53 <dmendiza[m]> Getting close to time, y'all.
15:55:10 <h_asahina> okey. I'll update spec based on today's discussion. thanks.
15:55:20 <dmendiza[m]> Thank you h_asahina
15:55:25 <dmendiza[m]> #topic Open Discussion
15:55:40 <dmendiza[m]> any < 5 min topic y'all would like to talk about?
15:57:46 <h_asahina> if there's no topic, i'd like to remind keystonemiddleware Zuul error I reported before. there're some patches this erros appear.
15:57:54 <h_asahina> https://review.opendev.org/c/openstack/keystonemiddleware/+/851319
15:58:01 <h_asahina> https://review.opendev.org/c/openstack/keystonemiddleware/+/830737
15:58:13 <h_asahina> the erros:
15:58:15 <h_asahina> File "/home/zuul/src/opendev.org/openstack/keystonemiddleware/keystonemiddleware/tests/unit/audit/test_logging_notifier.py", line 36, in test_api_request_no_messaging
15:58:16 <h_asahina> call_args = log.call_args_list[0][0]
15:58:18 <h_asahina> IndexError: list index out of range
15:58:36 <knikolla> yep, will quickly +2 once I see CI happy.
15:58:41 <knikolla> Thanks!
15:58:58 <h_asahina> got it. thanks
16:00:35 <dmendiza[m]> I'll keep an eye out for those too.
16:00:40 <dmendiza[m]> And that's all the time we have for the meeting.
16:00:50 <dmendiza[m]> Thanks for joining, y'all
16:00:51 <dmendiza[m]> #endmeeting