Add E2E tests for OIDC token validation

[alegacy]

This adds end-to-end tests and supporting material to execute tests that validate parts of the OIDC functionality.

Current tests include:

1. Using a valid token
2. Using an expired token
3. Using a token signed by an unknown signer
4. Using a token for an unknown user
5. Using a token matching a group binding
6. Using a token for an audience not matching the configured client-id

[stlaz]

Thank you for your pull request.

Please don't add private keys to this repository - ideally we would remove them from the manifests, too. Our test suite is in golang so please move your bash tests into golang.

[alegacy]

Please don't add private keys to this repository - ideally we would remove them from the manifests, too. Our test suite is in golang so please move your bash tests into golang.

@stlaz My apologies. Was just following what already existed in this repo since the private key for client testing is already stored. I'll do my best to refactor.

[stlaz]

No need to apologize 🙂 I don't think there were private keys before in the repo, which is a little bit of a difference. I believe Red Hat infosec detects that at least in their repos, not sure if by any chance for all of their employees. so you may still be getting an email from them 😁

I believe that generating cryptomaterial as a golang fixture will be a great improvement to the test suite, actually, and would be very welcome 👍

[alegacy]

No need to apologize 🙂 I don't think there were private keys before in the repo, which is a little bit of a difference. I believe Red Hat infosec detects that at least in their repos, not sure if by any chance for all of their employees. so you may still be getting an email from them 😁
😄
... what I meant was that the private key is currently in the clientcertificates/certificate.yaml

I reworked my changes on the weekend and now have fixtures for the certs and tokens. Still need to do a bit of testing before I update the PR with the new code.

Thanks for the quick review.

[alegacy]

@stlaz Pushed new changes with an attempt at refactoring to create certs/tokens dynamically. Please take another look when you have a chance.

[stlaz]

Thank you, this must have been a lot of work.

I think we'll need to change the mockserver though, the current one is unmaintained.

[stlaz]

that's a version from 10 years ago 😱

[alegacy]

I think we'll need to change the mockserver though, the current one is unmaintained.

Is there an alternative that you would recommend?

[alegacy]

@stlaz You've added comments to files that I've copied in directly from the sig-auth-acceptance branch from a commit that @ibihim authored. Do you want those changed considering that it will create merge headaches between those two branches?

[stlaz]

Is there an alternative that you would recommend?

An ideal alternative would be something we can actually run in a container but that might be hard. Basically you'd have an HTTP server and you'd instruct it with how it should respond to certain queries.
I remember looking for something like that before, and for OIDC mock servers, but there's probably nothing like that anywhere.

kubernetes/kubernetes is using https://github.com/uber-go/mock for mocking (it's actually using an older version that was originally in the golang org). Not sure whether we could actually use it here, too.

[alegacy]

Is there an alternative that you would recommend?

An ideal alternative would be something we can actually run in a container but that might be hard. Basically you'd have an HTTP server and you'd instruct it with how it should respond to certain queries. I remember looking for something like that before, and for OIDC mock servers, but there's probably nothing like that anywhere.

mock-server is the most popular out there as far as I can tell even though the maintainer seems to have disappeared. Given its popularity i would hope someone would pick it up, but if you don't like depending on that then may https://wiremock.org/ might work, i'll take a look at what its capabilities are.

[alegacy]

An ideal alternative would be something we can actually run in a container but that might be hard. Basically you'd have an HTTP server and you'd instruct it with how it should respond to certain queries. I remember looking for something like that before, and for OIDC mock servers, but there's probably nothing like that anywhere.

That's exactly what mock-server does. It's also what wiremock does -- i'm testing this one now to see if it'll do what we need.

[alegacy]

@stlaz I've updated with changes to use wiremock instead of mock-server. Please have another look.

[alegacy]

@stlaz Any chance you could re-review this so we can move this forward?