Make token issuer validation optional

[Afanas10101111]

Reason/Context

In some cases, Microcks' clients may receive an auth token from sources other than the Microcks' realm. Now in this case we get Bearer error="invalid_token", error_description="An error occurred while attempting to decode the Jwt: The iss claim is not valid". And there is no way to fix this without total keycloak disabling. We can't just override this spring.security.oauth2.resourceserver.jwt.issuer-uri= in kube config, because '' is not the same as null for Spring when it creates the validator.

Description

All we need to fix this is to make spring.security.oauth2.resourceserver.jwt.issuer-uri optional. There will be no breaking changes.

Implementation ideas

Idea

[lbroudoux]

Hello! Thanks for raising this issue.
Can you bring some details on the situation this can happen? I can't imagine why we would have to handle such case and what is the current impact... Is it related to Microcks' own API invokations?

[Afanas10101111]

Is it related to Microcks' own API invokations?

Yes.
For example, I don`t want to bring Microcks' settings to the realm, where my other apps recieve tokens. In this case I have two realms:

1. realms/microcks
2. realms/systemAuth

If I set spring.security.oauth2.resourceserver.jwt.issuer-uri=.../realms/microcks, I get The iss claim is not valid for app tokens. If I set spring.security.oauth2.resourceserver.jwt.issuer-uri=.../realms/systemAuth, I get The iss claim is not valid for Microcks' tokens - UI unavalable :(
Or for apps there could even be a deferent auth server implementation than Keycloak, without any iss value in the token.

[lbroudoux]

Ok. But wouldn't that mean that the token is not checked at all? And that people not authenticated at all would have access to the Microcks UI? Also how could we get access to user' roles if the token has been issued by another realm?

[Afanas10101111]

No, only the iss value from the token will not be validated. And if the iss validation is required, we can always enable it. But we can't disable it while we have this property in application.properties (in image).

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity 😴

It will be closed in 30 days if no further activity occurs. To unstale this issue, add a comment with a detailed explanation.

There can be many reasons why some specific issue has no activity. The most probable cause is lack of time, not lack of interest. Microcks is a Cloud Native Computing Foundation project not owned by a single for-profit company. It is a community-driven initiative ruled under open governance model.

Let us figure out together how to push this issue forward. Connect with us through one of many communication channels we established here.

Thank you for your patience ❤️

[lbroudoux]

Hey there!

I thought bout this one and have a few questions to make it clearer ;-)

Let me rephrase a bit and please tell me if I understand things correctly...

As I understand it, you have apps or users with JWT tokens created by a systemAuth issuer (actually a Keycloak realm). Those apps or users want to use those tokens to invoke Microcks API and it fails today because Microcks has the issuer-uri property set that tells Spring Security to validate the iss claim value to the one referencing the ../realms/microcks URL. Right?

I understand that removing the property would disable the iss claim check because, on Kube, we also have the jwk-set-uri property, whose value overrides the URL from issuer-uri. Still right?

Now I have those questions:

• As it is set today, the jwk-set-uri references the ../realms/microcks/... URL. Does that mean that you can validate JWT created by systemAuth realm using the public keys retrieved from microcks realm? Don't you need to put here the URL from the systemAuth realm here? (something like ../realms/systemAuth/protocol/openid-connect/certs)

• If disabling iss validation and validating JWT coming from systemAuth that means that those tokens don't embed role information of the subject... Even the default user role that is assumed by Microcks for read-only operation will not be present so how API invokation could work? How does you JWT can include those information if you don't have some Microcks realm settings in systemAuth?

• I'm wondering if disabling iss validation is the correct answer to this problem ... Shouldn't we have a configurable issuer-uri value instead with a configurable jwk-set-uri possibly different from the auth-server-url?

Any help is appreciated in making this clearer! Thank you,

[Afanas10101111]

Hi @lbroudoux !

As I understand it, you have apps or users with JWT tokens created by a systemAuth issuer (actually a Keycloak realm). Those apps or users want to use those tokens to invoke Microcks API and it fails today because Microcks has the issuer-uri property set that tells Spring Security to validate the iss claim value to the one referencing the ../realms/microcks URL. Right?

Yes, but it's about apps and mock invocations only, I need this in order not to change the logic of the tested applications. Microcks users are still in the microcks realm.

I understand that removing the property would disable the iss claim check because, on Kube, we also have the jwk-set-uri property, whose value overrides the URL from issuer-uri. Still right?

Yes, we need at least one of them to configure the resource server according to the manual.

As it is set today, the jwk-set-uri references the ../realms/microcks/... URL. Does that mean that you can validate JWT created by systemAuth realm using the public keys retrieved from microcks realm? Don't you need to put here the URL from the systemAuth realm here? (something like ../realms/systemAuth/protocol/openid-connect/certs)

No, all we need is to add the key(s) from the realm-issuer(s) (systemAuth, superSystemAuth, ets.) to the microcks realm, so that it can validate tokens from these sources.

If disabling iss validation and validating JWT coming from systemAuth that means that those tokens don't embed role information of the subject... Even the default user role that is assumed by Microcks for read-only operation will not be present so how API invokation could work? How does you JWT can include those information if you don't have some Microcks realm settings in systemAuth?

As I mentioned above, I need only the invocations of the mock URLs by the tested apps. All servicing users and roles are still in the microcks realm, so here nothing changes.

I'm wondering if disabling iss validation is the correct answer to this problem ... Shouldn't we have a configurable issuer-uri value instead with a configurable jwk-set-uri possibly different from the auth-server-url?

At the moment I have no other solution :(
The implementation of the issuer-uri validation in org.springframework.security.oauth2.jwt.JwtIssuerValidator is a bit not flexible

[lbroudoux]

As I mentioned above, I need only the invocations of the mock URLs by the tested apps. All servicing users and roles are still in the microcks realm, so here nothing changes.

Oh oh oh... I missed something here... I thought it was for calling Microcks APIs (you know /api/* paths). I wonder if all of this is not in fact due to this regression that was introduced in 1.8.0 and that we fixed recently: #1121

In fact, present oauth bearer in mock invocations shouldn't be validated as they can come from many different issuers - you were on the simple case where they were actually issued by a Keycloak as well but we have so many diverse situations. Could you check that one? Validate if switching to latest fix of 1.9.0 will do the trick?

You may come back saying that you'd like basic validation of JWT even on mock invocations though ;-) This is another topic IMHO and may lead to another issue in my opinion ... For that we can imagine different strategies/policies:

• Just checking that bearer is JWT,
• Validating issuer or not,
• Trusting JWT using keys (dynamically or statically retrieved)
• ...

What do you think?

[Afanas10101111]

Yes, new configureMockSecurityFilterChain bean completely solves my 401 problem. I thought it was a feature, not a bug, though, and wondered only why issuer-uri is not optional :)
And you are right about my thoughts on a possible JWT validation on mock invocations :)
What if we make configureMockSecurityFilterChain bean conditional on the property? Combining it with the optional issuer-uri already gives us some space to configure a preffered JWT policy.