Option to disable strict validation of requested scopes

[Martin Kanis]

Hi,

we introduced a strict validation of requested scopes [0] to conform RFC 6749 spec. If the requested scope doesn't exist in Keycloak or isn't assigned to the client a "invalid_scope" error is returned.

This is a breaking change for someone and we already started to receive tickets about this [1][2].

Do you think it will be useful to have a configuration option for this? Even when it's no longer compliant with the spec if it's disabled?

Martin

[0] https://issues.redhat.com/browse/KEYCLOAK-8071

[1] https://issues.redhat.com/browse/KEYCLOAK-14042

[2] https://issues.redhat.com/browse/KEYCLOAK-14143

[Ricardo Camelo]

Hello folks, I got a problem with this validation, and raised a bug in keycloak, but I agree with the validation that is implemented, but I disagree the way that it was Implemented, a static method directely in the token endpoint. Couldn't it be an SPI that could be overriden? Or that validation could be overriden in a client level?

[Stefan Schwarz]

I would appreciate an option, at least to have a quick workaround for misconfigured services.

Thanks!

[Ricardo Camelo]

   Me too!!!

[Schuster Sebastian (IOC/PDL22)]

The quickest workaround is to just create the scopes… Before that switch becomes available, you might also have discovered all missing scopes.

 

Best regards,

Sebastian

 

Mit freundlichen Grüßen / Best regards

Dr.-Ing. Sebastian Schuster

Project Delivery Berlin 22 (IOC/PDL22)
Bosch.IO GmbH | Ullsteinstr. 128 | 12109 Berlin | GERMANY | www.bosch.io
Tel. +49 30 726112-485 | Mobil +49 152 02177668 | Telefax +49 30 726112-100 | Sebastian...@bosch.io

Sitz: Berlin, Registergericht: Amtsgericht Charlottenburg; HRB 148411 B
Aufsichtsratsvorsitzender: Dr.-Ing. Thorsten Lücke; Geschäftsführung: Dr. Stefan Ferber, Dr. Aleksandar Mitrovic, Yvonne Reckling

--
You received this message because you are subscribed to the Google Groups "Keycloak Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to keycloak-dev...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/keycloak-dev/ce6d6025-707f-4157-9e8f-a391fd03e905o%40googlegroups.com.

[Ricardo Camelo]

  For my company, the scopes are registered in a separated application, I made an SPI that receive events from this application, and register then. I have another SPI that validate the scopes with this application that I mentioned before. Altought, I think that this feature is usefull, to disable it, to let other party to validate de scopes.

  Ricardo Fraga Camelo

To unsubscribe from this group and stop receiving emails from it, send an email to keyclo...@googlegroups.com.

[jona...@backbase.com]

I guess it's the definition of an "unknown" scope that's the problem - the scope is rejected as unknown because it does not exist in a fixed set of scopes in the Keycloak database. 

For some use cases, we also use a scope to reference a specific resource in the relying party that the user is being requested to authorise, so our scopes have a structure, e.g. 'myresource:123456'. The first part is fixed, indicating the type of resource, but the second part is dynamic as it references the identifier of the resource (so the format is essentially a URI), and we implement custom validation for that in the authentication flow that ensures that the resource exists, that it belongs to the correct user and so on. In this case, the resource is not unknown, as the validator implemented understands how to verify the requested scope. Or, the scope is known to Keycloak by virtue of custom logic to establish if it is known.

If you provide an SPI for scope validation, or a feature flag to disable it, then Keycloak can be extended using that SPI or an authenticator to validate the requested scope, and you are still compliant with the spec (you can still reject the request with `invalid_scope` if the validator does not find it).

Does that sound like a valid use case, and is there consensus that this doesn't break the spec for such a use case?

Jon

[Réda Housni Alaoui]

Hi,

I also have protocol mappers relying on dynamic scopes. So I am interested in a way allowing to disable validation either via SPI or configuration or something else.

I am also willing to contribute with a pull request.

I though of an alternative to SPI and configuration that would be (IMO) more easy to implement. The validation would be moved after all protocol mappers execution. The validation would check that every scope from the requested scope attribute have a matching scope value in the JWT. If a requested scope is missing in the JWT scope attribute, the validation would fail. This allows protocol mappers to populate the claim scope before validation. This has the great benefit of always complying with the spec, even in case of protocol mapper custom behaviour.

Before I start, can I have Keycloak team opinion about that?

Should I implement the proposed alternative?

If the configuration path is preferred, at which level should the configuration be? Realm level? Client level?

If the SPI path is preferred, should it be an SPI dedicated to validation (returning true/false)? Should it be an SPI allowing to return additional dynamic client scope like ClientModel#getDynamicClientScope(String scope) method?

Best regards

[Réda Housni Alaoui]

After reading the code a little longer, I seems token scope was never expected to be populated by the protocol mapper.
So I think the alternative I proposed is not easy to implement.

Standing by for feedback

Best regards

[Réda Housni Alaoui]

https://github.com/keycloak/keycloak/pull/7721 has been waiting for review since January.

Could someone please take a look at it?