Make acceptable AAGUID ckeck in WebAuthn stricter#48404
Conversation
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.MultipleTabsLoginTest#testWithAuthSessionExpiredInTheMiddle_badRedirectUriKeycloak CI - Forms IT (chrome) org.keycloak.testsuite.authz.PolicyEvaluationTest# |
|
@tnorimat I have added you as a reviewer. Your review would be awesome if you have time. If not, don't worry. |
|
@rmartinc Hello, yes I will review the PR soon. |
tnorimat
left a comment
There was a problem hiding this comment.
@rmartinc Hello, I added minor comments. Could you check them?
Also, it seems that you implemented the tests by arquillian integration test. Is that OK?
It seems that it might be better to implement the tests by new JUnit test.
|
Thanks @tnorimat! Added the two suggestions. Regarding the tests, yes, it's better to use the new TS. But some of the new tests need to disable the keycloak trustmanger (chrome virtual webauthn authneticator uses a self-signed certificate). In the old TS we do it using a method in the testing API, but that is complicated in the new TS. We have to add that to the new TS before, so I decided to not move this class to the new TS for this PR. |
|
@rmartinc Thank you for the clarification why using old arquillian integration tests. Yes please keep it. |
mabartos
left a comment
There was a problem hiding this comment.
@rmartinc Thanks for the PR! But I think it's the responsibility of the admin to properly set it up the policies. AFAIK, there's no negotiation of the attestation conveyance on the authenticator level, but tied to the policies themselves.
Would it be possible to add some validation even on the admin console to deny this case? Because otherwise the admin is able to set the denied case for policies, but the user will face the error. I think it's better to have some more boundaries here. If we provide just console validation, the existing realms should not be affected at all - or potentially consider to validate it on the server level when accepting these policies.
WDYT?
|
@mabartos I modified the admin console to not allow none if acceptable AAGUIds are defined. Does this work for you? |
|
Maybe this conflicts with #46960, so better wait the other to be merged and then move this one forward. Let's see if there is a conflict finally. |
Closes keycloak#48388 Signed-off-by: rmartinc <rmartinc@redhat.com>
…one in admin console Closes keycloak#48388 Signed-off-by: rmartinc <rmartinc@redhat.com>
Closes keycloak#48388 Signed-off-by: rmartinc <rmartinc@redhat.com>
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.user.UserModelTest#testAddDirtyRemoveFederationUsersInTheSameGroupConcurrentKeycloak CI - Store Model Tests |
Closes #48388
PR to make the AAGUID check in WebAuthn strict. Previously we were accepting some corner cases that allow to inject the AAGUID from an untrusted source. The PR also limits the AAGUID to not include the none attestation (which is also untrusted). Normally the none format anonymizes the AAGUID to the zero AAGUID, so it's totally useless. I added a note as notable change, but it's between notable and breaking, a proper configuration is OK, but maybe some weird configurations can fail (like allowing none with the zero AAGUID as accepted, it's useless, you are accepting any authenticator with no attestation). I can move the note to a breaking change if you think it's more a breaking change than a notable one. The note is for 26.6.2, I'll move it if not ready for the new version. Tests added but in the old TS, we need to disable the trust-store for keycloak and that is going to be complicated in the new TS. So I prefer to not do it for this PR.