Clarifications about userHandle computation in FinishAssertionSteps class

[CyrilCadoux]

Hi,

I am facing a problem with the userHandle computation during the assertion verification. But before entering into the details of my specific problem, there are two things I would like to clarify about the FinishAssertionSteps class code itself:

---

1. FinishAssertionSteps class: Step6 class (line 131) To me, it seems that orElseGet(...) will never get executed, since it gets called on an Optional<Optional<ByteArray> object (worst case is that the inner Optional<ByteArray> is Optional.EMPTY... so actually, the outer one will never be Optional.EMPTY itself). Am I missing something here ? Using the same objects on my own setup, I could never end up in the orElseGet(...) part.

---

2. My second question is a bit broader: why is there even a orElseGet(...) scenario in this case ? If response.getResponse().getUserHandle() is Optional.EMPTY, is it really fine to retrieve the userhandle via the credentialRepository and the request.getUserName() ? Would the authentication ceremony still be successful ? If yes, then why do we even bother with retrieving it from the response ?

---

Now I can finally explain why I am asking all this. We use FIDO2 as a second factor authentication, and it seems to work as desired on Windows machines. On MAC OS machines though, authentication fails (registration works fine).

For some reasons (maybe linked to Yubico/libfido2#464 ?), response.getResponse().getUserHandle().toString() returns Optional[ByteArray()]. Of course, my CredentialRepository.lookup() function (called by FinishAssertionSteps class (line 152)) cannot work with such an empty ByteArray and returns an error.

So now (relating to point 2 above): Should this sitaution by handled by the orElseGet(...) scenario? . IE, could we still finish the authentication ceremony if userHandle is not provided in the response? The request object contains the username and I can fetch the userHandle via the CredentialRepository without any issue on my test setup.

If yes, is it correct to say that the library must be patched ?

• -> to ensure that the Optional<Optional<ByteArray> does not prevent the orElseGet(...) execution (point 1 above)
• -> to ensure that orElseGet(...) is executed not only for Optional.EMPTY but also for any Optional<ByteArray> containing an empty ByteArray object

---

This problem here is based on a lot of "what if?", I hope I made it clear enough !
Any input appreciated !

Thanks a lot for your answers,

Cyril

[emlun]

Hi!

1. This is a work-around to the fact that unlike scala.Option, java.util.Optional doesn't have a method like .orElse(Option<T>), where the fallback is also an Optional. Instead, we work around it by wrapping any present value in another layer of Optional, so we can use .orElseGet() to get the original value back if it was present, or otherwise return a different Optional value.

2. This is a known bug in Safari - an empty user handle is distinct from a null/undefined user handle. Second-factor credentials typically do not return a user handle, so Safari should be setting it to null/undefined instead of an empty byte array.

   We do not intend to add a workaround for this in the library, but you can work around it on the application layer. Either by overriding AuthenticatorAssertionResponse.toBuilder().userHandle(null).build() (or .userHandle(Optional.empty())), or by omitting the userHandle property from JSON before parsing it.

   See also issue RelyingParty.finishAssertion() fails when called with assertion result from Safari v15.4 #194.

Does that help?

[CyrilCadoux]

Thanks a lot for the quick answer.
Simply applying a regex replace on the JSON before parsing it does the trick ! I should not have worried so much ;)

Have a nice end of the week !