We will be able to provide you with OIDC secret (either as ansible variable or we can provide it by secure way). The documentation for OIDC ipsilon setup could be found here.

We need few details from you:

• Name of the application
• Redirect URI
• Contact for application
• Client URI

These authorizers don't use a secret, which is partly why they're separate from the 'normal' client for the system - see mbs-authorizer vs. mbs-prod , waiverdb-authorizer vs. waiverdb , and so on. Well, technically they have a secret, but it is always the string notsecret.

I'm aware of the process for setting up a new application, but that's not exactly what this is, which is why I didn't use that template. We already have the kerneltest client in the existing config, but that client cannot be used for this kind of interactive CLI authentication via python-openidc-client, AIUI.

Just out of interest, is this for users to upload via CLI? or a once-set-and-forget thing for another tool to upload to kerneltest?

IIRC, we don't have any other tool that lets users use this authorize things right? if we need this behaviour, we use kerb?

also, if you get a chance, i'd also love to track this issue on the repo -- https://github.com/fedora-infra/kerneltest/issues

Just out of interest, is this for users to upload via CLI? or a once-set-and-forget thing for another tool to upload to kerneltest?

it's for use via a CLI. See https://fedoraproject.org/wiki/QA:Testcase_kernel_regression . That's the thing we get people to run at kernel test days, which happen for every new kernel version, and we get a few hundred testers.

IIRC, we don't have any other tool that lets users use this authorize things right? if we need this behaviour, we use kerb?

Sure we do, that's why at least some of these authorizer clients exist. The wikitcms one exists to make it possible to use the relval tool to change the wiki, either to create validation events or to submit test results, for instance (that one doesn't have authorizer in its name because the 'regular' client is called fpwiki). fedpkg-authorizer is pretty clearly intended for the use of the fedpkg CLI tool. etc...

also, if you get a chance, i'd also love to track this issue on the repo -- https://github.com/fedora-infra/kerneltest/issues

well, we already have a ticket in the client repo - https://pagure.io/kernel-tests/issue/50 - and one here. adding a third seems a bit excessive :D but we can if you really want. I don't really see this as an 'issue' in the server, though, it's more that we need to adapt the client to a change that already happened in the server, AIUI.

We can also look at how the bodhi-client authorizer is defined, it has:

bodhi-client client_secret=""
bodhi-client redirect_uris=["urn:ietf:wg:oauth:2.0:oob"]
bodhi-client application_type="native"
bodhi-client token_endpoint_auth_method="none"

ok. I went and took a stab at config for it... can you see if it works now?

yikes, another item for the tab backlog pile, will get to it when i can yep. thanks!

It doesn't work, gives 400 "Invalid redirect_uri". Looking at the entry you added, you listed the redirect_uris as:

kerneltest-client redirect_uris=["urn:ietf:wg:oauth:2.0:oob"]

I don't think that's right, it needs to be:

kerneltest-client redirect_uris=["http://localhost:13747/", "http://localhost:12345/", "http://localhost:23456/"]

like the other similar configs. The client literally does need to redirect to localhost - the way this whole thing works is that it spins up a temporary local web server, captures the redirect, and gets the token out of it.

Also you set:

kerneltest-client client_secret=""

where all the others have it as "notsecret". I don't know whether an empty secret works or not. And finally, I think it should be token_endpoint_auth_method="client_secret_post", at least that's what all the other authorizer-style configs have.

I just copied those from the bodhi-client entry since I thought this was like that?

or is bodhi-client not the cli one? I guess it's weird and not like the other authorizor ones. ;(

We can try changing them to that... ok, done.

it seems bodhi actually implemented its own OIDC client, so I guess that's why it's different. For kerneltest I just went with using openidc_client because I was somewhat familiar with it from its use in wikitcms. The configs that have redirect_uris like this (localhost with a few ports following patterns openidc_client uses) are all intended for use with openidc_client, I think, though looking through the code of the apparent users, I think some of them may actually not be used any more.

ugh, it still doesn't work right, not sure why not. will look at it tomorrow.

OK, the issue was the submitted file's mime type, nothing to do with the auth stuff. I cannot explain why that's a problem now when it wasn't before, but never mind. This is resolved, the authenticator is working - thanks.