Repository navigation
Conversation
59a2038 to
1172c26
Compare
4e87f2e to
44a334e
Compare
b4e16c4 to
87a6861
Compare
Unreported flaky test detectedIf the flaky tests below are affected by the changes, please review and update the changes accordingly. Otherwise, a maintainer should report the flaky tests prior to merging the PR. org.keycloak.testsuite.model.session.UserSessionProviderModelTest#testCreateUserSessionsParallelKeycloak CI - Store Model Tests |
5d10a26 to
311c674
Compare
|
This is now 1st class PR (without dependency on tx_code) |
238b7a2 to
1e5abd8
Compare
Unreported flaky test detectedIf the flaky tests below are affected by the changes, please review and update the changes accordingly. Otherwise, a maintainer should report the flaky tests prior to merging the PR. org.keycloak.testsuite.forms.LevelOfAssuranceFlowTest#testNonEssentialAcrMinimumUpgradeKeycloak CI - Forms IT (chrome) org.keycloak.testsuite.forms.LevelOfAssuranceFlowTest#stepupToUnknownEssentialAcrFailsKeycloak CI - Forms IT (chrome) org.keycloak.testsuite.forms.LevelOfAssuranceFlowTest#optionalClaimNotReachedSucceedsKeycloak CI - Forms IT (chrome) org.keycloak.testsuite.forms.LevelOfAssuranceFlowTest#testBackwardsCompatibilityForLoaConditionConfigKeycloak CI - Forms IT (chrome) |
6e399e9 to
d0436f4
Compare
There was a problem hiding this comment.
-
Regarding the "pre-authorized code grant allowed": We should be consistent with other grants and apply client policies in same way like done for other grants. For other grants, we have executors like for example
RejectResourceOwnerPasswordCredentialsGrantExecutor(the one I had demo on the SIG meeting few weeks ago) orRejectImplicitGrantExecutor. When this is executor is used, the particular grant is always rejected. It is up to the condition on where the grant is applied. For example it can be applied toAnyClientCondition(which means all requests in the realm) or to the particular client scope (by usingclient scope condition). Pre-authorized code grant should be also option on the client (again for consistency with other grants) and executor should have a way to "auto-configure" that configuration option on the client. In other words, pre-authorized code grant should be consistent like other grants are doing instead of "pre-authorized grant" being handled in a special way inconsistent with other grants. Also considering this, it should not be an option on the credential client scope whether "pre-authorized code grant" is allowed or not. -
For "Credential offer required" - This makes sense to me if it is config option on the client scope. However in that case, the client scope condition should be evaluated even if the client-policy is not configured. It would be strange to have configuration option like "require credential offer" on the client scope, but at the same time, apply this requirement just if client policy is configured. In other words, having executor, which applies policy based on the configuration options on the client scope is strange to me.
So I would start with only option on client scope and perhaps initially without client scope policy involvement for this one. We can possibly have both configuration option on the client scope as well as an executor (or configuration option on some executor). This can be useful if client policy want to make sure that for example all client scopes in the realm should always require credential-offer.
In short: I think it can be nice to handle "pre-authorized code grant allowed" and "credential offer required" in separate PRs. The "pre-authorized code" grant should be done in a way consistent with other grants (Executor similar to RejectResourceOwnerPasswordCredentialsGrantExecutor).
The "credential offer required" can be initially added as a config option on the client scope (no client policy needed) as that one makes sense to be configurable on the credential scope. We can add integration with client policies for this one as well as a follow-up if needed.
|
@mposolda thanks for the detailed feedback. I may ask a few questions about that tomorrow & then we can do whatever is being decided. |
275abc5 to
a3fdf57
Compare
faeff8a to
e64bd3e
Compare
|
If possible, I'd like to come back to this after #47286 which it depends on. |
Signed-off-by: Thomas Diesler <tdiesler@proton.me>
Signed-off-by: Thomas Diesler <tdiesler@proton.me>
Signed-off-by: Thomas Diesler <tdiesler@proton.me>
closes #46896
depends on
This PR adds this client policy ...
which is triggered when a client is oid4vci enabled.