New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support Multiple Origins #237
Support Multiple Origins #237
Conversation
Codecov Report
@@ Coverage Diff @@
## master #237 +/- ##
==========================================
- Coverage 79.31% 79.10% -0.21%
==========================================
Files 82 83 +1
Lines 3161 3173 +12
==========================================
+ Hits 2507 2510 +3
- Misses 654 663 +9
Continue to review full report at Codecov.
|
Src/Fido2/AuthenticatorResponse.cs
Outdated
|
||
// 5. Verify that the value of C.origin matches the Relying Party's origin. | ||
if (!string.Equals(fullyQualifiedOrigin, fullyQualifiedExpectedOrigin, StringComparison.OrdinalIgnoreCase)) | ||
throw new Fido2VerificationException($"Fully qualified origin {fullyQualifiedOrigin} of {Origin} not equal to fully qualified original origin {fullyQualifiedExpectedOrigin} of {expectedOrigin}"); | ||
if (!fullyQualifiedExpectedOrigins.Any(o => string.Equals(fullyQualifiedOrigin, o, StringComparison.OrdinalIgnoreCase))) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
While not a dealbreaker, I'm wondering if a HashSet would be better than a List?
My gut feeling is that it would be able to do a lookup without iterating (like linq Any does).
It is mostly relevant if the list of origins grow due to large number of unique origins.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sounds reasonable, just need to make sure to normalize the ordinal before comparing.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I changed it to HashSet, however to avoid iterating and converting them to FullyQualifiedOrigins each time, I had to store them in the Fido2Configuration
object. I'm not completely happy with it, but I don't see any other place to put it.
Src/Fido2/AuthenticatorResponse.cs
Outdated
@@ -73,7 +73,7 @@ protected void BaseVerify(List<string> expectedOrigins, byte[] originalChallenge | |||
|
|||
// 5. Verify that the value of C.origin matches the Relying Party's origin. | |||
if (!fullyQualifiedExpectedOrigins.Any(o => string.Equals(fullyQualifiedOrigin, o, StringComparison.OrdinalIgnoreCase))) | |||
throw new Fido2VerificationException($"Fully qualified origin {fullyQualifiedOrigin} of {Origin} not equal to fully qualified original origin {fullyQualifiedExpectedOrigins} of {expectedOrigins}"); | |||
throw new Fido2VerificationException($"Fully qualified origin {fullyQualifiedOrigin} of {Origin} not equal to fully qualified original origin {string.Join(", ", fullyQualifiedExpectedOrigins)} of {string.Join(", ", expectedOrigins)}"); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We should probably add a .Take(MAX_ORIGINS_TO_PRINT) to the list before string joining to stop a very long list of origins to generate huge strings in the exceptions
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sure, any suggestion of what it should be set to?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think 5-10 should be enough.
Our original intention was to make sure the developer understod what value we were expecting. I think we could include a count just to avoid confusion now that we are hiding some.
So all the unit tests seem ok, but this PR breaks conformance tests currently. This is what I am seeing:
|
@aseigler Hmm, I get a similar error if I leave We ended up not needing these changes after all, mainly due to iOS not natively supporting |
I am happy with this now. Thanks! |
@aseigler Thanks for the help in getting this merged. |
Objective
Native android applications supports the FIDO2 protocol, but diverges slightly from the WebAuthN spec in that they set the
origin
field in the Attestation and Assertion toandroid:apk-key-hash:<hash>
. Since settingFido2Configuration.Origin
to this value would cause web clients to fail we need a way to handle multiple allowed origins.This PR deprecates the
Fido2Configuration.Origin
property and replace it withFido2Configuration.Origins
. It falls back gracefully toOrigin
shouldOrigins
not be set.I aimed to not modifying any public API, but unfortunately both
AuthenticatorAssertionResponse
andAuthenticatorResponse
signature was changed slightly to support a list of origins. Let me know if I should look into adding new methods instead to ensure backwards compatibility.Noteworthy Code Changes
BaseVerify
to accept an list of origins.Origins
instead ofOrigin
. This file seemed to contain mixed linebreaks. When saving they all changed to LF (\n
). Let me know if we want to avoid these change)Resolves: #220