gecko-dev/dom/webauthn/tests/test_webauthn_get_assertion...

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

235 строки
7.3 KiB
HTML
Исходник Обычный вид История

<!DOCTYPE html>
<meta charset=utf-8>
<head>
<title>Tests for GetAssertion for W3C Web Authentication</title>
<script src="/tests/SimpleTest/SimpleTest.js"></script>
<script type="text/javascript" src="u2futil.js"></script>
<script type="text/javascript" src="pkijs/common.js"></script>
<script type="text/javascript" src="pkijs/asn1.js"></script>
<script type="text/javascript" src="pkijs/x509_schema.js"></script>
<script type="text/javascript" src="pkijs/x509_simpl.js"></script>
<link rel="stylesheet" type="text/css" href="/tests/SimpleTest/test.css" />
</head>
<body>
<h1>Tests for GetAssertion for W3C Web Authentication</h1>
<a target="_blank" href="https://bugzilla.mozilla.org/show_bug.cgi?id=1309284">Mozilla Bug 1309284</a>
<script class="testbody" type="text/javascript">
"use strict";
is(navigator.authentication, undefined, "navigator.authentication does not exist any longer");
isnot(navigator.credentials, undefined, "Credential Management API endpoint must exist");
isnot(navigator.credentials.create, undefined, "CredentialManagement create API endpoint must exist");
isnot(navigator.credentials.get, undefined, "CredentialManagement get API endpoint must exist");
let gAssertionChallenge = new Uint8Array(16);
window.crypto.getRandomValues(gAssertionChallenge);
let invalidCred = {type: "Magic", id: base64ToBytes("AAA=")};
let unknownCred = {type: "public-key", id: base64ToBytes("AAA=")};
Bug 1460767 - Return device ineligible when appropriate for U2F r=ttaubert Summary: FIDO U2F's specification says that when the wrong security key responds to a signature, or when an already-registered key exists, that the UA should return error code 4, DEVICE_INELIGIBLE. We used to do that, but adjusted some things for WebAuthn and now we don't. This changes the soft token to return that at the appropriate times, and updates the expectations of U2F.cpp that it should use InvalidStateError as the signal to reutrn DEVICE_INELIGIBLE. Also, note that WebAuthn's specification says that if any authenticator returns "InvalidStateError" that it should be propagated, as it indicates that the authenticator obtained user consent and failed to complete its job [1]. This change to the Soft Token affects the WebAuthn tests, but in a good way. Reading the WebAuthn spec, we should not be returning NotAllowedError when there is consent from the user via the token (which the softtoken always deliveres). As such, this adjusts the affected WebAuthn tests, and adds a couple useful checks to test_webauthn_get_assertion.html for future purposes. [1] https://w3c.github.io/webauthn/#createCredential section 5.1.3 "Create a new credential", Step 20, Note 2: "If any authenticator returns an error status equivalent to "InvalidStateError"..." Test Plan: https://treeherder.mozilla.org/#/jobs?repo=try&revision=f2fc930f7fc8eea69b1ebc96748fe95e150a92a4 Reviewers: ttaubert Bug #: 1460767 Differential Revision: https://phabricator.services.mozilla.com/D1269 --HG-- extra : transplant_source : M%5B%93%81%29%7E%B2%E8%24%05%A6%96%8BUN%C9%FB%3E%B3h
2018-05-11 02:36:18 +03:00
let validCred = null;
function requestGetAssertion(params) {
return navigator.credentials.get(params);
}
Bug 1460767 - Return device ineligible when appropriate for U2F r=ttaubert Summary: FIDO U2F's specification says that when the wrong security key responds to a signature, or when an already-registered key exists, that the UA should return error code 4, DEVICE_INELIGIBLE. We used to do that, but adjusted some things for WebAuthn and now we don't. This changes the soft token to return that at the appropriate times, and updates the expectations of U2F.cpp that it should use InvalidStateError as the signal to reutrn DEVICE_INELIGIBLE. Also, note that WebAuthn's specification says that if any authenticator returns "InvalidStateError" that it should be propagated, as it indicates that the authenticator obtained user consent and failed to complete its job [1]. This change to the Soft Token affects the WebAuthn tests, but in a good way. Reading the WebAuthn spec, we should not be returning NotAllowedError when there is consent from the user via the token (which the softtoken always deliveres). As such, this adjusts the affected WebAuthn tests, and adds a couple useful checks to test_webauthn_get_assertion.html for future purposes. [1] https://w3c.github.io/webauthn/#createCredential section 5.1.3 "Create a new credential", Step 20, Note 2: "If any authenticator returns an error status equivalent to "InvalidStateError"..." Test Plan: https://treeherder.mozilla.org/#/jobs?repo=try&revision=f2fc930f7fc8eea69b1ebc96748fe95e150a92a4 Reviewers: ttaubert Bug #: 1460767 Differential Revision: https://phabricator.services.mozilla.com/D1269 --HG-- extra : transplant_source : M%5B%93%81%29%7E%B2%E8%24%05%A6%96%8BUN%C9%FB%3E%B3h
2018-05-11 02:36:18 +03:00
function arrivingHereIsGood(aResult) {
ok(true, "Good result! Received a: " + aResult);
}
function arrivingHereIsBad(aResult) {
ok(false, "Bad result! Received a: " + aResult);
}
function expectNotAllowedError(aResult) {
Bug 1460767 - Return device ineligible when appropriate for U2F r=ttaubert Summary: FIDO U2F's specification says that when the wrong security key responds to a signature, or when an already-registered key exists, that the UA should return error code 4, DEVICE_INELIGIBLE. We used to do that, but adjusted some things for WebAuthn and now we don't. This changes the soft token to return that at the appropriate times, and updates the expectations of U2F.cpp that it should use InvalidStateError as the signal to reutrn DEVICE_INELIGIBLE. Also, note that WebAuthn's specification says that if any authenticator returns "InvalidStateError" that it should be propagated, as it indicates that the authenticator obtained user consent and failed to complete its job [1]. This change to the Soft Token affects the WebAuthn tests, but in a good way. Reading the WebAuthn spec, we should not be returning NotAllowedError when there is consent from the user via the token (which the softtoken always deliveres). As such, this adjusts the affected WebAuthn tests, and adds a couple useful checks to test_webauthn_get_assertion.html for future purposes. [1] https://w3c.github.io/webauthn/#createCredential section 5.1.3 "Create a new credential", Step 20, Note 2: "If any authenticator returns an error status equivalent to "InvalidStateError"..." Test Plan: https://treeherder.mozilla.org/#/jobs?repo=try&revision=f2fc930f7fc8eea69b1ebc96748fe95e150a92a4 Reviewers: ttaubert Bug #: 1460767 Differential Revision: https://phabricator.services.mozilla.com/D1269 --HG-- extra : transplant_source : M%5B%93%81%29%7E%B2%E8%24%05%A6%96%8BUN%C9%FB%3E%B3h
2018-05-11 02:36:18 +03:00
ok(aResult.toString().startsWith("NotAllowedError"), "Expecting a NotAllowedError, got " + aResult);
}
function expectInvalidStateError(aResult) {
ok(aResult.toString().startsWith("InvalidStateError"), "Expecting a InvalidStateError, got " + aResult);
}
function expectTypeError(aResult) {
Bug 1460767 - Return device ineligible when appropriate for U2F r=ttaubert Summary: FIDO U2F's specification says that when the wrong security key responds to a signature, or when an already-registered key exists, that the UA should return error code 4, DEVICE_INELIGIBLE. We used to do that, but adjusted some things for WebAuthn and now we don't. This changes the soft token to return that at the appropriate times, and updates the expectations of U2F.cpp that it should use InvalidStateError as the signal to reutrn DEVICE_INELIGIBLE. Also, note that WebAuthn's specification says that if any authenticator returns "InvalidStateError" that it should be propagated, as it indicates that the authenticator obtained user consent and failed to complete its job [1]. This change to the Soft Token affects the WebAuthn tests, but in a good way. Reading the WebAuthn spec, we should not be returning NotAllowedError when there is consent from the user via the token (which the softtoken always deliveres). As such, this adjusts the affected WebAuthn tests, and adds a couple useful checks to test_webauthn_get_assertion.html for future purposes. [1] https://w3c.github.io/webauthn/#createCredential section 5.1.3 "Create a new credential", Step 20, Note 2: "If any authenticator returns an error status equivalent to "InvalidStateError"..." Test Plan: https://treeherder.mozilla.org/#/jobs?repo=try&revision=f2fc930f7fc8eea69b1ebc96748fe95e150a92a4 Reviewers: ttaubert Bug #: 1460767 Differential Revision: https://phabricator.services.mozilla.com/D1269 --HG-- extra : transplant_source : M%5B%93%81%29%7E%B2%E8%24%05%A6%96%8BUN%C9%FB%3E%B3h
2018-05-11 02:36:18 +03:00
ok(aResult.toString().startsWith("TypeError"), "Expecting a TypeError, got " + aResult);
}
function expectAbortError(aResult) {
is(aResult.code, DOMException.ABORT_ERR, "Expecting an AbortError");
}
add_task(() => {
return SpecialPowers.pushPrefEnv({"set": [
["security.webauth.webauthn", true],
["security.webauth.webauthn_enable_softtoken", true],
["security.webauth.webauthn_enable_usbtoken", false],
["security.webauth.webauthn_enable_android_fido2", false],
]});
});
Bug 1460767 - Return device ineligible when appropriate for U2F r=ttaubert Summary: FIDO U2F's specification says that when the wrong security key responds to a signature, or when an already-registered key exists, that the UA should return error code 4, DEVICE_INELIGIBLE. We used to do that, but adjusted some things for WebAuthn and now we don't. This changes the soft token to return that at the appropriate times, and updates the expectations of U2F.cpp that it should use InvalidStateError as the signal to reutrn DEVICE_INELIGIBLE. Also, note that WebAuthn's specification says that if any authenticator returns "InvalidStateError" that it should be propagated, as it indicates that the authenticator obtained user consent and failed to complete its job [1]. This change to the Soft Token affects the WebAuthn tests, but in a good way. Reading the WebAuthn spec, we should not be returning NotAllowedError when there is consent from the user via the token (which the softtoken always deliveres). As such, this adjusts the affected WebAuthn tests, and adds a couple useful checks to test_webauthn_get_assertion.html for future purposes. [1] https://w3c.github.io/webauthn/#createCredential section 5.1.3 "Create a new credential", Step 20, Note 2: "If any authenticator returns an error status equivalent to "InvalidStateError"..." Test Plan: https://treeherder.mozilla.org/#/jobs?repo=try&revision=f2fc930f7fc8eea69b1ebc96748fe95e150a92a4 Reviewers: ttaubert Bug #: 1460767 Differential Revision: https://phabricator.services.mozilla.com/D1269 --HG-- extra : transplant_source : M%5B%93%81%29%7E%B2%E8%24%05%A6%96%8BUN%C9%FB%3E%B3h
2018-05-11 02:36:18 +03:00
// Set up a valid credential
add_task(async () => {
let publicKey = {
rp: {id: document.domain, name: "none", icon: "none"},
user: {id: new Uint8Array(), name: "none", icon: "none", displayName: "none"},
challenge: crypto.getRandomValues(new Uint8Array(16)),
pubKeyCredParams: [{type: "public-key", alg: cose_alg_ECDSA_w_SHA256}],
};
return navigator.credentials.create({publicKey})
.then(res => validCred = {type: "public-key", id: res.rawId} );
});
// Test basic good call, but without giving a credential so expect failures
// this is OK by the standard, but not supported by U2F-backed authenticators
// like the soft token in use here.
add_task(async () => {
let publicKey = {
challenge: gAssertionChallenge
};
await requestGetAssertion({publicKey})
.then(arrivingHereIsBad)
Bug 1460767 - Return device ineligible when appropriate for U2F r=ttaubert Summary: FIDO U2F's specification says that when the wrong security key responds to a signature, or when an already-registered key exists, that the UA should return error code 4, DEVICE_INELIGIBLE. We used to do that, but adjusted some things for WebAuthn and now we don't. This changes the soft token to return that at the appropriate times, and updates the expectations of U2F.cpp that it should use InvalidStateError as the signal to reutrn DEVICE_INELIGIBLE. Also, note that WebAuthn's specification says that if any authenticator returns "InvalidStateError" that it should be propagated, as it indicates that the authenticator obtained user consent and failed to complete its job [1]. This change to the Soft Token affects the WebAuthn tests, but in a good way. Reading the WebAuthn spec, we should not be returning NotAllowedError when there is consent from the user via the token (which the softtoken always deliveres). As such, this adjusts the affected WebAuthn tests, and adds a couple useful checks to test_webauthn_get_assertion.html for future purposes. [1] https://w3c.github.io/webauthn/#createCredential section 5.1.3 "Create a new credential", Step 20, Note 2: "If any authenticator returns an error status equivalent to "InvalidStateError"..." Test Plan: https://treeherder.mozilla.org/#/jobs?repo=try&revision=f2fc930f7fc8eea69b1ebc96748fe95e150a92a4 Reviewers: ttaubert Bug #: 1460767 Differential Revision: https://phabricator.services.mozilla.com/D1269 --HG-- extra : transplant_source : M%5B%93%81%29%7E%B2%E8%24%05%A6%96%8BUN%C9%FB%3E%B3h
2018-05-11 02:36:18 +03:00
.catch(expectInvalidStateError);
});
Bug 1460767 - Return device ineligible when appropriate for U2F r=ttaubert Summary: FIDO U2F's specification says that when the wrong security key responds to a signature, or when an already-registered key exists, that the UA should return error code 4, DEVICE_INELIGIBLE. We used to do that, but adjusted some things for WebAuthn and now we don't. This changes the soft token to return that at the appropriate times, and updates the expectations of U2F.cpp that it should use InvalidStateError as the signal to reutrn DEVICE_INELIGIBLE. Also, note that WebAuthn's specification says that if any authenticator returns "InvalidStateError" that it should be propagated, as it indicates that the authenticator obtained user consent and failed to complete its job [1]. This change to the Soft Token affects the WebAuthn tests, but in a good way. Reading the WebAuthn spec, we should not be returning NotAllowedError when there is consent from the user via the token (which the softtoken always deliveres). As such, this adjusts the affected WebAuthn tests, and adds a couple useful checks to test_webauthn_get_assertion.html for future purposes. [1] https://w3c.github.io/webauthn/#createCredential section 5.1.3 "Create a new credential", Step 20, Note 2: "If any authenticator returns an error status equivalent to "InvalidStateError"..." Test Plan: https://treeherder.mozilla.org/#/jobs?repo=try&revision=f2fc930f7fc8eea69b1ebc96748fe95e150a92a4 Reviewers: ttaubert Bug #: 1460767 Differential Revision: https://phabricator.services.mozilla.com/D1269 --HG-- extra : transplant_source : M%5B%93%81%29%7E%B2%E8%24%05%A6%96%8BUN%C9%FB%3E%B3h
2018-05-11 02:36:18 +03:00
// Test with a valid credential
add_task(async () => {
let publicKey = {
challenge: gAssertionChallenge,
allowCredentials: [validCred]
};
await requestGetAssertion({publicKey})
.then(arrivingHereIsGood)
.catch(arrivingHereIsBad);
});
// Test with an unexpected option. That won't stop anything, and we'll
// fail with InvalidState just as if we had no valid credentials -- which
// we don't.
add_task(async () => {
let publicKey = {
challenge: gAssertionChallenge,
unknownValue: "hi"
};
await requestGetAssertion({publicKey})
.then(arrivingHereIsBad)
Bug 1460767 - Return device ineligible when appropriate for U2F r=ttaubert Summary: FIDO U2F's specification says that when the wrong security key responds to a signature, or when an already-registered key exists, that the UA should return error code 4, DEVICE_INELIGIBLE. We used to do that, but adjusted some things for WebAuthn and now we don't. This changes the soft token to return that at the appropriate times, and updates the expectations of U2F.cpp that it should use InvalidStateError as the signal to reutrn DEVICE_INELIGIBLE. Also, note that WebAuthn's specification says that if any authenticator returns "InvalidStateError" that it should be propagated, as it indicates that the authenticator obtained user consent and failed to complete its job [1]. This change to the Soft Token affects the WebAuthn tests, but in a good way. Reading the WebAuthn spec, we should not be returning NotAllowedError when there is consent from the user via the token (which the softtoken always deliveres). As such, this adjusts the affected WebAuthn tests, and adds a couple useful checks to test_webauthn_get_assertion.html for future purposes. [1] https://w3c.github.io/webauthn/#createCredential section 5.1.3 "Create a new credential", Step 20, Note 2: "If any authenticator returns an error status equivalent to "InvalidStateError"..." Test Plan: https://treeherder.mozilla.org/#/jobs?repo=try&revision=f2fc930f7fc8eea69b1ebc96748fe95e150a92a4 Reviewers: ttaubert Bug #: 1460767 Differential Revision: https://phabricator.services.mozilla.com/D1269 --HG-- extra : transplant_source : M%5B%93%81%29%7E%B2%E8%24%05%A6%96%8BUN%C9%FB%3E%B3h
2018-05-11 02:36:18 +03:00
.catch(expectInvalidStateError);
});
// Test with an unexpected option but a valid credential
add_task(async () => {
let publicKey = {
challenge: gAssertionChallenge,
unknownValue: "hi",
allowCredentials: [validCred]
};
await requestGetAssertion({publicKey})
.then(arrivingHereIsGood)
.catch(arrivingHereIsBad);
});
// Test with an unexpected transport on a valid credential
add_task(async () => {
let cred = validCred;
cred.transports = ["unknown", "usb"];
let publicKey = {
challenge: gAssertionChallenge,
unknownValue: "hi",
allowCredentials: [cred]
};
await requestGetAssertion({publicKey})
.then(arrivingHereIsGood)
.catch(arrivingHereIsBad);
});
// Test with an invalid credential
add_task(async () => {
let publicKey = {
challenge: gAssertionChallenge,
allowCredentials: [invalidCred]
};
await requestGetAssertion({publicKey})
.then(arrivingHereIsBad)
.catch(expectTypeError);
});
// Test with an unknown credential
add_task(async () => {
let publicKey = {
challenge: gAssertionChallenge,
allowCredentials: [unknownCred]
};
await requestGetAssertion({publicKey})
.then(arrivingHereIsBad)
Bug 1460767 - Return device ineligible when appropriate for U2F r=ttaubert Summary: FIDO U2F's specification says that when the wrong security key responds to a signature, or when an already-registered key exists, that the UA should return error code 4, DEVICE_INELIGIBLE. We used to do that, but adjusted some things for WebAuthn and now we don't. This changes the soft token to return that at the appropriate times, and updates the expectations of U2F.cpp that it should use InvalidStateError as the signal to reutrn DEVICE_INELIGIBLE. Also, note that WebAuthn's specification says that if any authenticator returns "InvalidStateError" that it should be propagated, as it indicates that the authenticator obtained user consent and failed to complete its job [1]. This change to the Soft Token affects the WebAuthn tests, but in a good way. Reading the WebAuthn spec, we should not be returning NotAllowedError when there is consent from the user via the token (which the softtoken always deliveres). As such, this adjusts the affected WebAuthn tests, and adds a couple useful checks to test_webauthn_get_assertion.html for future purposes. [1] https://w3c.github.io/webauthn/#createCredential section 5.1.3 "Create a new credential", Step 20, Note 2: "If any authenticator returns an error status equivalent to "InvalidStateError"..." Test Plan: https://treeherder.mozilla.org/#/jobs?repo=try&revision=f2fc930f7fc8eea69b1ebc96748fe95e150a92a4 Reviewers: ttaubert Bug #: 1460767 Differential Revision: https://phabricator.services.mozilla.com/D1269 --HG-- extra : transplant_source : M%5B%93%81%29%7E%B2%E8%24%05%A6%96%8BUN%C9%FB%3E%B3h
2018-05-11 02:36:18 +03:00
.catch(expectInvalidStateError);
});
// Test with an unexpected option and an invalid credential
add_task(async () => {
let publicKey = {
challenge: gAssertionChallenge,
unknownValue: "hi",
allowCredentials: [invalidCred]
};
await requestGetAssertion({publicKey})
.then(arrivingHereIsBad)
.catch(expectTypeError);
});
// Test with an empty credential list
Bug 1460767 - Return device ineligible when appropriate for U2F r=ttaubert Summary: FIDO U2F's specification says that when the wrong security key responds to a signature, or when an already-registered key exists, that the UA should return error code 4, DEVICE_INELIGIBLE. We used to do that, but adjusted some things for WebAuthn and now we don't. This changes the soft token to return that at the appropriate times, and updates the expectations of U2F.cpp that it should use InvalidStateError as the signal to reutrn DEVICE_INELIGIBLE. Also, note that WebAuthn's specification says that if any authenticator returns "InvalidStateError" that it should be propagated, as it indicates that the authenticator obtained user consent and failed to complete its job [1]. This change to the Soft Token affects the WebAuthn tests, but in a good way. Reading the WebAuthn spec, we should not be returning NotAllowedError when there is consent from the user via the token (which the softtoken always deliveres). As such, this adjusts the affected WebAuthn tests, and adds a couple useful checks to test_webauthn_get_assertion.html for future purposes. [1] https://w3c.github.io/webauthn/#createCredential section 5.1.3 "Create a new credential", Step 20, Note 2: "If any authenticator returns an error status equivalent to "InvalidStateError"..." Test Plan: https://treeherder.mozilla.org/#/jobs?repo=try&revision=f2fc930f7fc8eea69b1ebc96748fe95e150a92a4 Reviewers: ttaubert Bug #: 1460767 Differential Revision: https://phabricator.services.mozilla.com/D1269 --HG-- extra : transplant_source : M%5B%93%81%29%7E%B2%E8%24%05%A6%96%8BUN%C9%FB%3E%B3h
2018-05-11 02:36:18 +03:00
// This will return InvalidStateError since the softotken consents, but
// there are no valid credentials.
add_task(async () => {
let publicKey = {
challenge: gAssertionChallenge,
allowCredentials: []
};
await requestGetAssertion({publicKey})
.then(arrivingHereIsBad)
Bug 1460767 - Return device ineligible when appropriate for U2F r=ttaubert Summary: FIDO U2F's specification says that when the wrong security key responds to a signature, or when an already-registered key exists, that the UA should return error code 4, DEVICE_INELIGIBLE. We used to do that, but adjusted some things for WebAuthn and now we don't. This changes the soft token to return that at the appropriate times, and updates the expectations of U2F.cpp that it should use InvalidStateError as the signal to reutrn DEVICE_INELIGIBLE. Also, note that WebAuthn's specification says that if any authenticator returns "InvalidStateError" that it should be propagated, as it indicates that the authenticator obtained user consent and failed to complete its job [1]. This change to the Soft Token affects the WebAuthn tests, but in a good way. Reading the WebAuthn spec, we should not be returning NotAllowedError when there is consent from the user via the token (which the softtoken always deliveres). As such, this adjusts the affected WebAuthn tests, and adds a couple useful checks to test_webauthn_get_assertion.html for future purposes. [1] https://w3c.github.io/webauthn/#createCredential section 5.1.3 "Create a new credential", Step 20, Note 2: "If any authenticator returns an error status equivalent to "InvalidStateError"..." Test Plan: https://treeherder.mozilla.org/#/jobs?repo=try&revision=f2fc930f7fc8eea69b1ebc96748fe95e150a92a4 Reviewers: ttaubert Bug #: 1460767 Differential Revision: https://phabricator.services.mozilla.com/D1269 --HG-- extra : transplant_source : M%5B%93%81%29%7E%B2%E8%24%05%A6%96%8BUN%C9%FB%3E%B3h
2018-05-11 02:36:18 +03:00
.catch(expectInvalidStateError);
});
add_task(() => {
// Enable USB tokens.
return SpecialPowers.pushPrefEnv({"set": [
["security.webauth.webauthn", true],
["security.webauth.webauthn_enable_softtoken", false],
["security.webauth.webauthn_enable_usbtoken", true]
]});
});
// Test with an empty credential list
add_task(async () => {
let publicKey = {
challenge: gAssertionChallenge,
allowCredentials: []
};
let ctrl = new AbortController();
let request = requestGetAssertion({publicKey, signal: ctrl.signal})
.then(arrivingHereIsBad)
.catch(expectAbortError);
// Wait a tick for the statemachine to start.
await Promise.resolve();
// The request should time out. We'll abort it here and will fail or
// succeed upon resolution, when the error code is checked.
ctrl.abort();
await request;
});
</script>
</body>
</html>